-
Notifications
You must be signed in to change notification settings - Fork 0
Frameworks
The NIST Cybersecurity Framework version 2.0 is a set of guidelines published by the National Institute of Standards and Technology (NIST), a US government agency. It was updated in February 2024 and is used by organisations of all sizes and industries around the world.
The framework does not tell you exactly which software to use or which buttons to click. Instead, it organises security activities into six broad functions that describe what a complete security programme should be able to do. Think of it as a checklist for whether your organisation is handling cybersecurity in a structured and comprehensive way.
This framework is a good starting point if your client has no existing compliance requirement but wants to demonstrate that their security posture is organised and improving over time.
This function is about who is responsible for security decisions, whether the right licences and access controls are in place, and whether there is a written policy that everyone follows. Before you can secure anything, you need to know who owns the security programme and what rules it operates under.
In this tool, Govern tasks cover things like assigning Microsoft Defender for Endpoint licences, setting up roles so that only the right people can see or change security settings, and creating device groups that organise computers by their risk level or business function.
This function is about knowing what you are protecting. You cannot secure devices you do not know exist. Identify tasks focus on getting every device enrolled in MDE so it appears in the device inventory, and on understanding the software and vulnerabilities present across those devices.
In this tool, Identify tasks cover onboarding Windows computers, servers, Linux machines, and Apple Mac devices into MDE, enabling vulnerability scanning, and tagging devices with labels that indicate their importance to the business.
This function is about putting controls in place to stop attacks before they succeed. It covers preventive measures — things that block or restrict harmful actions rather than just detecting them after the fact.
In this tool, Protect tasks cover configuring antivirus settings, enabling attack surface reduction rules (which are specific blocks on common attack techniques), turning on network filtering, enforcing encryption on device storage, and requiring multi-factor authentication before users can access corporate systems.
This function is about identifying when something is going wrong. Even with strong preventive controls, some attacks will get through, and the organisation needs to know about them quickly.
In this tool, Detect tasks cover verifying that MDE sensors are active and sending data, building custom detection rules in the security portal, connecting MDE to Microsoft Sentinel (a centralised monitoring platform), and setting up alerts for suspicious activity.
This function is about what happens when an incident is detected. Having a detection is only useful if someone acts on it in an organised way.
In this tool, Respond tasks cover configuring automated investigation and response (where MDE investigates and fixes threats without waiting for a human to intervene), setting up the Live Response feature for direct access to devices during an investigation, documenting an escalation procedure, and testing response processes using simulated attack scenarios.
This function is about returning to normal after an incident and learning from what happened. It also covers ongoing improvement of the security programme.
In this tool, Recover tasks cover reviewing the remediation history in the MDE portal, running quarterly health checks on the deployment, conducting post-incident reviews, and using the Secure Score to track improvement over time.
57 tasks across the six functions.
| Function | Tasks |
|---|---|
| Govern | 8 |
| Identify | 10 |
| Protect | 12 |
| Detect | 10 |
| Respond | 8 |
| Recover | 7 |
No single regulator mandates NIST CSF specifically, but it is widely accepted as a strong baseline across all industries. Many US-based enterprises, healthcare organisations, and financial services companies reference it in contracts and risk assessments. It is also used as a starting point before pursuing more specific certifications.
Start with Govern and Identify before moving to the others. The Govern tasks ensure the right licences and access controls are in place. The Identify tasks ensure all devices are enrolled and visible. Trying to configure protective controls before devices are enrolled will result in those controls having gaps.
Work through Protect and Detect in parallel once onboarding is complete. Many of the Detect tasks depend on the same sensors and policies you configure in Protect.
Respond and Recover tasks involve documentation and process definition as much as technical configuration. Schedule time for these separately — they require input from managers and process owners, not just the technical team.
Cyber Essentials is a UK government-backed cybersecurity certification scheme. It was created by the National Cyber Security Centre (NCSC), which is part of GCHQ, and is administered by IASME on behalf of the government. The scheme defines five technical controls that every organisation should have in place as a minimum foundation for protecting against the most common cyber threats.
Achieving Cyber Essentials certification means an organisation has self-assessed its technical controls and had that self-assessment verified by an approved certifying body. The process is relatively straightforward compared to larger frameworks and is often a starting point for organisations that are new to formal cybersecurity requirements.
Cyber Essentials is mandatory for some UK government contracts, particularly those involving handling personal data or providing certain types of IT services to the public sector.
A firewall is a set of rules that controls which network traffic is allowed in and out of a computer or network. The Cyber Essentials firewall requirement focuses on making sure that computers connected to the internet do not accept incoming connections unless they are explicitly intended and approved.
In this tool, Firewall tasks cover enabling the Windows Defender Firewall on all devices through a managed policy, turning on Network Protection (which blocks connections to known malicious websites and IP addresses at the operating system level), and configuring Web Content Filtering to block categories of harmful websites.
Every device and piece of software comes with default settings, and many of those defaults are not secure. Secure configuration means reviewing those defaults and changing anything that is unnecessary or risky.
In this tool, Secure Configuration tasks cover applying Microsoft's published security baseline settings to all devices, disabling services that are not needed (such as the Remote Registry service on desktop computers), enabling Tamper Protection (which prevents security software from being disabled by an attacker), and turning on Controlled Folder Access (which prevents unknown programmes from modifying files in protected locations like the Documents folder).
User access control means ensuring that each person has only the level of access they need to do their job, and that strong authentication is required before granting that access.
In this tool, User Access Control tasks cover requiring multi-factor authentication (MFA) for all users — meaning they need their password and a second factor like a phone notification to log in — enforcing separate administrator accounts so that day-to-day work is not done with elevated privileges, and configuring role-based access in the MDE portal so that different analysts can only see and act on what is appropriate for their role.
Malware protection means having up-to-date software in place that detects and blocks malicious programmes.
In this tool, Malware Protection tasks cover configuring Microsoft Defender Antivirus with cloud-delivered protection (where the antivirus checks files against a constantly updated cloud database rather than relying only on definitions downloaded days ago), enabling behavioural monitoring (which detects suspicious activity patterns rather than just known bad files), and ensuring that every device in scope has an active MDE sensor reporting back to the portal.
Software contains vulnerabilities — security weaknesses that attackers can exploit. Patches are updates that fix those vulnerabilities. The Cyber Essentials requirement is that critical and high-severity patches must be applied within 14 days of their release.
In this tool, Patch Management tasks cover enabling the Threat and Vulnerability Management (TVM) feature in MDE, which automatically discovers software vulnerabilities across all enrolled devices, configuring Windows Update for Business to deploy security updates promptly, and monitoring for end-of-support software that no longer receives security patches.
29 tasks across the five controls.
| Control | Tasks |
|---|---|
| Firewalls | 6 |
| Secure Configuration | 8 |
| User Access Control | 6 |
| Malware Protection | 6 |
| Patch Management | 5 |
Cyber Essentials is required for organisations that want to bid for UK government contracts that involve handling personal information or providing certain technical services. It is also increasingly requested by enterprise clients as a condition of doing business, particularly in the supply chain.
Cyber Essentials is a UK-specific certification but is recognised by many international organisations as evidence of a strong baseline security posture.
Cyber Essentials is a self-assessment. You complete a questionnaire, an approved certifying body reviews your answers, and if they are satisfied, you receive the certificate.
Cyber Essentials Plus involves an independent assessor coming to your organisation (or connecting remotely) to technically verify that the controls are actually in place. They will run tests, check configurations, and request evidence. This is a more rigorous and valuable certification.
If your client needs Cyber Essentials Plus, use both the Cyber Essentials and Cyber Essentials Plus framework tabs in this tool. The Cyber Essentials tab covers the underlying configuration, and the Cyber Essentials Plus tab covers the additional evidence and testing tasks required for the assessor.
The Secure Configuration tasks involve applying policies through Microsoft Intune, which is Microsoft's device management platform. If Intune is not yet set up or if devices are not enrolled in Intune, those tasks cannot be completed until that is resolved — note them as Blocked with an explanation in the notes field.
The 14-day patch requirement in Patch Management is strict. Start the TVM tasks early so you have time to remediate any vulnerabilities found before an assessment date.
Many of the Cyber Essentials requirements can be satisfied by deploying a single Intune Security Baseline policy. Complete the Secure Configuration tasks first as they lay the foundation for several other controls.
Cyber Essentials Plus is the higher tier of the UK government's Cyber Essentials certification scheme. It covers the same five technical controls as Cyber Essentials but adds independent technical verification by an approved assessor. Where Cyber Essentials is a self-assessment, Cyber Essentials Plus requires someone external to come in and actually test that the controls work.
This means that Cyber Essentials Plus is worth considerably more as evidence of security — it has been independently verified rather than self-declared.
You cannot attempt Cyber Essentials Plus without first having Cyber Essentials in place (or completing both at the same time). Use the Cyber Essentials tab in this tool to track the underlying configuration, and use this tab to track the additional tasks required specifically for the Plus assessment.
An approved Cyber Essentials Plus assessor will either visit on-site or connect remotely. They will spend time testing a representative sample of your devices — typically a selection of laptops, desktops, and servers. They will test:
- Whether antivirus detects and blocks malicious files
- Whether the firewall blocks unexpected inbound traffic
- Whether web content filtering blocks malicious URLs
- Whether software patches are up to date on all tested devices
- Whether multi-factor authentication is genuinely enforced
- Whether accounts are separated between standard users and administrators
If a device fails any test, or if the assessor finds a discrepancy between what was declared in the Cyber Essentials self-assessment and what is actually configured, the certification will not be awarded until the issue is remediated.
Before the assessment, you need to run authenticated vulnerability scans against all in-scope devices and confirm that no critical or high-severity vulnerabilities remain unpatched. An authenticated scan means the scanning tool logs into the devices it is checking, which gives much more accurate and detailed results than an unauthenticated scan.
The tasks in this category cover setting up the TVM scanning feature in MDE, exporting the scan results as evidence, verifying that no critical or high CVEs (Common Vulnerabilities and Exposures — the standard way of labelling known security flaws) remain on in-scope devices, and producing a signed asset inventory that the assessor can use to verify scope.
The assessor will test whether antivirus is genuinely active and effective. The standard test uses a file called EICAR, which is a harmless test file specifically designed to trigger antivirus software without causing any actual harm. If antivirus is correctly configured, it should detect and quarantine the EICAR file immediately.
The tasks in this category cover running the EICAR test, running simulated attack scenarios using Microsoft's Attack Simulator tool, testing PUA (Potentially Unwanted Application) protection, and compiling all test results into a single evidence document for the assessor.
The assessor will verify that the firewall and web content filtering controls are actually blocking what they should. This involves attempting to access known-blocked websites and IP addresses from within the organisation's network.
The tasks in this category cover testing Web Content Filtering by attempting to access blocked URL categories, verifying that Network Protection blocks connections to threat-intelligence-listed addresses, exporting firewall rule sets as evidence, and confirming with the assessor that no unexpected ports are open on internet-facing systems.
The assessor will verify that multi-factor authentication is genuinely enforced and that standard user accounts do not have administrator rights. They may ask you to demonstrate a login attempt on an unregistered device and show that access is blocked.
The tasks in this category cover demonstrating MFA enforcement live, exporting the local administrator account report to show that no standard users have admin rights, testing that the MDE role-based access control prevents analysts from viewing devices outside their assigned scope, and exporting the Privileged Identity Management audit log as evidence that admin access is time-limited and approval-gated.
The assessor will verify that all software on in-scope devices is within 14 days of the latest available security patch. This applies to the operating system and to all installed applications including browsers, office software, PDF readers, and development tools.
The tasks in this category cover exporting the Windows Update compliance report showing patch dates, exporting the TVM software vulnerability list filtered to high and critical severity, confirming that no end-of-support software is present on in-scope devices, and producing third-party application version evidence for key software packages.
This category covers the preparation work needed before the assessment day itself. Assessors expect a well-organised evidence pack and clear answers to their questions. Poor preparation is one of the most common reasons assessments are delayed.
The tasks in this category cover compiling the full evidence pack into a dated folder structure, running an internal pre-assessment walkthrough two weeks before the assessment date, setting up remote access for the assessor if they are connecting remotely, obtaining sign-off on the scope document, documenting any formal risk acceptances for controls that cannot be fully met by assessment date, and setting up a remediation tracker for any findings the assessor identifies after the assessment.
35 tasks across six categories.
| Category | Tasks |
|---|---|
| Vulnerability Scanning | 6 |
| Malware Protection Testing | 5 |
| Network Boundary Testing | 6 |
| Access Control Verification | 6 |
| Patch Compliance Evidence | 6 |
| Assessor Readiness | 6 |
Cyber Essentials Plus is required for some UK government contracts that involve more sensitive data or higher-risk services. It is also increasingly requested by large enterprise clients as a supply chain requirement.
Organisations that have achieved Cyber Essentials and want to demonstrate a higher level of assurance will typically pursue Cyber Essentials Plus as the next step.
Book the assessment date before starting the CE+ tasks and work backwards from it. The Assessor Readiness tasks specify doing an internal walkthrough at least two weeks before the assessment date. If you book the date first, you have a clear deadline.
Use the notes field on every task to record dates, file names, and locations of evidence documents. On assessment day, you will need to find specific reports quickly — thorough notes make this much easier.
If any task cannot be completed before the assessment date, document it formally using the risk acceptance task in the Assessor Readiness category. Do not leave it blank or mark it as Blocked without an explanation. Assessors respond much better to a documented exception with a remediation plan than to an unexplained gap.
SOC 2 stands for System and Organization Controls 2. It is a framework published by the AICPA (American Institute of Certified Public Accountants). Despite the accounting body origins, SOC 2 is primarily a technology and cybersecurity framework used by software companies, cloud service providers, and managed service providers to demonstrate that they handle customer data responsibly and securely.
A SOC 2 audit is performed by an independent CPA firm. The auditor reviews your controls over a period of time — typically six to twelve months for a Type II audit — and issues a report that your clients and partners can review as evidence of your security practices.
SOC 2 is not a pass/fail certification like Cyber Essentials. Instead, it produces a detailed report that describes your controls and whether they operated effectively during the audit period.
A SOC 2 Type I audit assesses whether controls are designed correctly at a single point in time. It answers the question: are the right controls in place today?
A SOC 2 Type II audit assesses whether controls operated effectively over a period of time, typically six to twelve months. It answers the question: have the right controls been consistently maintained?
Type II is significantly more valuable because it proves consistency, not just a snapshot. Most clients and enterprise customers will ask for a Type II report. If you are starting from scratch, you will typically begin with a Type I and then progress to Type II the following year.
SOC 2 is organised around Trust Service Criteria (TSC), which are groups of controls covering different aspects of security. The nine criteria covered in this tool are:
CC1 — Control Environment This covers whether the organisation has clear accountability for security, documented policies, and named individuals responsible for security decisions. Auditors want to see that security is taken seriously at a leadership level, not just by the technical team.
CC2 — Communication and Information This covers whether the right people are informed about security events and whether there are clear processes for communicating incidents internally and externally. This includes alert notification setups and documentation of incident communication procedures.
CC3 — Risk Assessment This covers whether the organisation regularly identifies and evaluates security risks. In the context of MDE, this means using the TVM feature to capture a baseline of vulnerabilities, defining what level of risk is acceptable, and reviewing that baseline regularly.
CC4 — Monitoring Activities This covers whether controls are being actively monitored to ensure they remain effective. A control that was set up correctly but has since been accidentally disabled does not satisfy this requirement. Continuous monitoring through MDE and Microsoft Sentinel is the primary way this criterion is met.
CC5 — Control Activities This covers the specific technical controls in place and whether they are documented, consistently applied, and have exceptions formally recorded. This is where ASR rules, device compliance policies, and change management processes are relevant.
CC6 — Logical and Physical Access This covers who can access what systems and under what conditions. Multi-factor authentication, role-based access in the MDE portal, Privileged Identity Management for admin accounts, and the quarterly access review process all fall under this criterion.
CC7 — System Operations This covers how security incidents are handled, including detection, response, and recovery. Automated investigation and remediation, incident response SLAs, and the Live Response capability in MDE are key controls here.
CC8 — Change Management This covers how changes to security configurations are controlled. Changes should be tested before deployment, approved by an authorised person, and documented. Storing your MDE configuration in version control and requiring approvals before policy changes are both relevant here.
CC9 — Risk Mitigation This covers third-party risk and other risks that arise from relationships outside the organisation. For an MSSP using Microsoft's cloud services, this means documenting Microsoft as a vendor, reviewing their compliance certifications, and confirming data residency is appropriate for your jurisdiction.
31 tasks across nine Trust Service Criteria.
| Criteria | Tasks |
|---|---|
| CC1 Control Environment | 3 |
| CC2 Communication and Information | 3 |
| CC3 Risk Assessment | 3 |
| CC4 Monitoring Activities | 3 |
| CC5 Control Activities | 3 |
| CC6 Logical and Physical Access | 5 |
| CC7 System Operations | 5 |
| CC8 Change Management | 3 |
| CC9 Risk Mitigation | 3 |
SOC 2 is most commonly required by US-based technology companies, SaaS providers, cloud service providers, and managed service providers. Clients — particularly enterprise clients and those in financial services, healthcare, and legal sectors — frequently require their vendors to have a current SOC 2 Type II report before they will share data or grant system access.
The most important thing to understand about SOC 2 is that it requires evidence of consistent operation over time, not just a snapshot of current configuration.
Use the notes field on every task to record the date you completed the configuration, the ticket number associated with the change, and any approval records. This creates a paper trail that an auditor can follow.
Export the JSON configuration monthly and store it in a secure location. This gives you a version history that demonstrates your controls have been maintained consistently.
If a control is blocked or cannot be implemented, document the reason and any compensating controls (alternative measures that address the same risk in a different way) as clearly as possible.
The CC6 and CC7 tasks are the most technically involved and should be started early. CC6 covers access controls and requires Privileged Identity Management to be configured, which itself requires time to set up and test. CC7 covers incident response, which requires both technical configuration and documentation of written procedures.
The documentation tasks (CC1, CC2, CC8) are often underestimated. Writing a governance policy, incident communication procedure, and change management process takes time and requires input from non-technical people. Involve management and legal early.
The monitoring tasks (CC4) require that you demonstrate ongoing activity, not just that controls are in place. Schedule recurring reviews — monthly Secure Score reviews, weekly device health checks — and keep brief records of the outcomes. These records are what auditors look for.
NIST Special Publication 800-53 is a catalogue of security and privacy controls published by the National Institute of Standards and Technology. The current version is Revision 5, published in 2020. It is one of the most comprehensive security frameworks in existence and is the foundation for US federal cybersecurity requirements.
Where NIST CSF 2.0 describes what an organisation should be able to do at a high level, NIST 800-53 goes much deeper and specifies exactly what controls should exist and how they should operate. It is organised into 20 control families, each covering a different area of security. This tool covers the eight control families most directly relevant to Microsoft Defender for Endpoint.
NIST 800-53 is mandatory for US federal agencies and any organisation that handles federal information systems or data. It is also the technical baseline for FedRAMP, which is the authorisation process that cloud service providers must complete to sell services to the US federal government.
Outside the federal space, many defence contractors, healthcare organisations, financial institutions, and large enterprises use 800-53 as a reference for their own security programmes, even if they are not required to formally comply. It is often seen as the gold standard for comprehensive security control documentation.
AC — Access Control These controls govern who can access systems and data, under what conditions, and with what level of privilege. The MDE-relevant tasks cover setting up role-based access in the MDE portal, conducting quarterly reviews of who has access, enforcing Conditional Access policies that require specific conditions before granting access, and managing access for remote sessions and mobile devices.
AU — Audit and Accountability These controls govern the creation, protection, and review of audit logs. The requirement is not just to generate logs but to protect them from modification, retain them for an appropriate period (minimum twelve months in most cases), and review them regularly. MDE audit logs flow into Microsoft Sentinel where they can be queried and reviewed.
CM — Configuration Management These controls govern how systems are configured and how changes to those configurations are controlled. This covers maintaining a documented baseline configuration, applying security hardening settings, controlling which software is permitted to run, and monitoring for unauthorised changes.
IA — Identification and Authentication These controls govern how users and devices prove who they are before being granted access. For MDE deployments, this covers requiring phishing-resistant multi-factor authentication, using Privileged Identity Management to control when admin accounts can be activated, storing service account credentials securely in Azure Key Vault, and using certificate-based authentication for device enrolment.
IR — Incident Response These controls govern the organisation's capability to detect, respond to, and recover from security incidents. This covers having a written incident response plan, configuring the automated investigation and response capabilities in MDE, setting up dashboards in Sentinel to track response times, defining escalation procedures, and testing the plan regularly through exercises.
RA — Risk Assessment These controls govern the process of identifying, analysing, and responding to security risks. For MDE, this means using the Defender Secure Score and TVM Exposure Score as primary risk metrics, running continuous vulnerability scanning, and documenting formal responses to each identified risk.
SC — System and Communications Protection These controls govern how information is protected when it is transmitted between systems and how systems are protected from network-based attacks. Relevant tasks cover enabling Network Protection at the operating system level, configuring DNS filtering, enforcing full-disk encryption using BitLocker, and blocking process injection attacks using ASR rules.
SI — System and Information Integrity These controls govern detecting and correcting flaws in information systems, protecting against malicious code, and monitoring systems for security-relevant events. Tasks cover configuring antivirus with cloud-delivered protection, establishing patch SLAs, enabling EDR in block mode, connecting MDE to Sentinel for continuous monitoring, and protecting the security software itself from tampering.
36 tasks across eight control families.
| Family | Tasks |
|---|---|
| Access Control | 5 |
| Audit and Accountability | 5 |
| Configuration Management | 5 |
| Identification and Authentication | 4 |
| Incident Response | 5 |
| Risk Assessment | 3 |
| System and Communications Protection | 4 |
| System and Information Integrity | 5 |
NIST 800-53 defines three baseline levels: Low, Moderate, and High. The baseline you use depends on the sensitivity of the information your system handles and the potential impact if that information were compromised.
Most MDE deployments handling operational security data sit at the Moderate baseline. Federal systems handling sensitive or classified information typically use the High baseline, which requires additional controls not covered in this tool.
If you are working on a formal federal compliance programme, the NIST RMF framework tab covers the process of formally selecting and documenting your control baseline.
The AU (Audit and Accountability) tasks require Microsoft Sentinel to be connected to MDE. If Sentinel is not set up, mark those tasks as Blocked with a note explaining the dependency. Setting up Sentinel is a project in itself and should be planned separately.
The IR (Incident Response) tasks involve a mix of technical configuration and written documentation. The written pieces — the incident response plan, the escalation matrix, the playbooks — require input from people outside the technical team. Start these conversations early.
The RA (Risk Assessment) tasks are quick to complete but require someone with authority to formally accept risks on behalf of the organisation. Identify that person before starting these tasks.
PCI DSS stands for Payment Card Industry Data Security Standard. It is a set of security requirements published and maintained by the PCI Security Standards Council, which is a body founded by the major card brands including Visa, Mastercard, American Express, and Discover.
Any organisation that processes, stores, or transmits payment card data — whether that is taking credit card payments, storing card numbers in a database, or handling payment authorisation messages — is required to comply with PCI DSS. Version 4.0, released in March 2022, is the current version covered in this tool.
The most important concept in PCI DSS is the cardholder data environment, commonly abbreviated as CDE. The CDE is the set of systems, networks, and people that directly touch or protect payment card data.
In this tool, all PCI DSS tasks are scoped to a CDE device group in MDE. This means you should create a separate device group in the MDE portal specifically for the computers and servers that process payment data, and apply a stricter set of policies to that group. Devices outside the CDE have different (generally less strict) requirements.
If you are not sure which devices are in the CDE, ask the client's IT team or project owner before proceeding. Getting the scope wrong is one of the most common PCI DSS compliance issues.
REQ1 — Network Security Controls These requirements ensure that the systems in the CDE are protected by properly configured firewalls and that only authorised network traffic can reach them. The Windows Defender Firewall, Network Protection, and Web Content Filtering in MDE all contribute to satisfying these requirements when configured and applied to the CDE device group.
REQ2 — Secure Configurations These requirements ensure that all system components in the CDE are configured securely — default settings have been reviewed, unnecessary services have been disabled, and a documented baseline exists. Applying a Microsoft Security Baseline policy through Intune and maintaining a device inventory are key tasks here.
REQ5 — Malware Protection These requirements ensure that malicious software cannot execute on systems in the CDE. All devices must have active, up-to-date malware protection that cannot be disabled. Tamper Protection in MDE directly addresses the requirement that protection software cannot be disabled by users or attackers.
REQ6 — Vulnerability Management These requirements ensure that known vulnerabilities in software running on CDE systems are identified and patched within defined timeframes. PCI DSS requires critical and high-severity vulnerabilities to be patched within 30 days. Authenticated scanning through TVM, combined with Windows Update for Business, is the primary way this is managed through MDE.
REQ7 and REQ8 — Access Control and Authentication These requirements, combined in this tool for practical purposes, cover who can access CDE systems and how their identity is verified. Multi-factor authentication is required for all access to the CDE. Accounts must be reviewed regularly and inactive accounts must be disabled within defined timeframes.
REQ10 — Audit Logging and Monitoring These requirements ensure that all access to system components and cardholder data is logged, that logs are retained for at least twelve months, and that logs are reviewed daily. Log immutability (preventing logs from being deleted or modified) is a specific requirement in version 4.0.
REQ11 — Security Testing These requirements ensure that vulnerabilities are discovered through active testing, not just passive monitoring. Quarterly vulnerability scans are required, and an annual penetration test is expected. The MDE Attack Simulator can support the penetration testing requirement and provides evidence of detection coverage.
REQ12 — Incident Response These requirements ensure that the organisation is prepared to respond to a payment card data breach. A written incident response plan specifically covering card data breaches is required, including the notification procedures for card brands and acquiring banks. Timelines for notification are strict — some card brands require notification within 72 hours of discovering a suspected breach.
40 tasks across eight requirement areas.
| Area | Tasks |
|---|---|
| Network Security Controls | 6 |
| Secure Configurations | 5 |
| Malware Protection | 5 |
| Vulnerability Management | 5 |
| Access Control and Authentication | 6 |
| Audit Logging and Monitoring | 5 |
| Security Testing | 4 |
| Incident Response | 4 |
Any organisation that processes, stores, or transmits payment card data must comply with PCI DSS. The level of compliance required depends on the volume of transactions the organisation processes each year. High-volume merchants and payment processors face stricter audit requirements than low-volume merchants, but the technical controls required are the same for all.
Service providers — including MSSPs — that manage systems in the CDE of another organisation are also subject to PCI DSS requirements for those systems.
Define the CDE scope clearly and get it agreed in writing before starting any tasks. Create the CDE device group in the MDE portal first, then work through each requirement applying policies specifically to that group.
The Audit Logging tasks require Sentinel to be set up and connected to MDE. This is a dependency that should be planned early in the project.
The Incident Response tasks require specific card brand notification procedures. These vary by card brand and are documented in each brand's operating rules. Involve the client's legal and finance teams in drafting the incident response plan.
Keep detailed notes on all PCI tasks using the notes field. PCI QSA (Qualified Security Assessor) auditors will ask for evidence of each control, and the notes field is a good place to record where that evidence is stored.
NIST Special Publication 800-207, Zero Trust Architecture, was published in August 2020. It describes a security model called Zero Trust, which is a fundamental shift in how organisations think about protecting their systems and data.
Traditional security models assumed that everything inside the corporate network could be trusted and everything outside could not. Once someone or something was inside the network, they had broad access. Zero Trust rejects this assumption entirely.
The Zero Trust principle is simple: never trust, always verify. Every request for access — regardless of where it comes from, whether inside or outside the organisation's network — must be authenticated, authorised, and continuously evaluated. No user, device, or application is trusted by default.
Microsoft Defender for Endpoint is one of the primary tools for implementing Zero Trust at the device level. MDE continuously monitors the security health of every enrolled device and produces a risk score. That risk score can be fed into Microsoft Entra ID's Conditional Access system, which then uses it as a condition for granting or blocking access to corporate applications.
This means that if a device becomes compromised — for example, if malware is detected — its MDE risk score increases, which automatically causes Conditional Access to block access from that device until the issue is resolved. This is Zero Trust in practice: the device is continuously evaluated and access is revoked the moment trust is lost.
Identity (ZT-ID) In Zero Trust, identity is the primary control plane. Users must prove who they are with strong authentication every time they access a resource, and that authentication must be resistant to phishing. The tasks in this pillar cover requiring phishing-resistant multi-factor authentication (using a security key or Microsoft Authenticator app rather than a text message code), using Privileged Identity Management to ensure that administrator accounts are only activated when needed, configuring identity-based risk policies that step up authentication requirements when unusual behaviour is detected, and connecting MDE's device risk signal to identity access decisions.
Devices (ZT-DEV) In Zero Trust, every device must be enrolled, managed, and continuously evaluated before it is allowed to access corporate resources. An unmanaged device — one that is not enrolled in MDE — should not be able to access corporate applications. The tasks in this pillar cover achieving complete MDE device coverage, configuring device compliance policies that require healthy MDE sensor status and acceptable risk scores, and automating the response when a device becomes non-compliant.
Network (ZT-NET) In Zero Trust, network location is not sufficient grounds for trust. Traffic flowing between internal systems is treated with the same suspicion as external traffic. The tasks in this pillar cover enabling Network Protection to block traffic to malicious destinations, organising devices into groups that enforce strict policies between them, configuring web content filtering per device group, and using attack surface reduction rules to block the lateral movement techniques attackers use to move from one compromised device to others.
Applications (ZT-APP) In Zero Trust, applications should not be accessible simply because a user is connected to the corporate network. Access to applications must require verified identity and a compliant device. The tasks in this pillar cover requiring device compliance for application access, discovering and managing shadow IT (unauthorised cloud applications being used without IT approval), and restricting which software is permitted to execute on high-risk devices.
Data (ZT-DATA) In Zero Trust, data should be protected based on its sensitivity regardless of where it is stored or how it is accessed. The tasks in this pillar cover enforcing full-disk encryption so that data is protected if a device is lost or stolen, blocking data from being copied to unapproved USB drives or cloud storage, protecting critical folders from unauthorised modification, and enforcing data loss prevention policies at the device level.
Visibility and Analytics (ZT-VIS) Zero Trust requires continuous monitoring and analysis across all pillars. Without visibility, you cannot make informed trust decisions. The tasks in this pillar cover connecting MDE and Sentinel to create a unified view of device, identity, network, application, and data signals, building dashboards that track Zero Trust posture metrics, integrating threat intelligence feeds, and building automated response playbooks that take action when trust signals deteriorate.
31 tasks across six pillars.
| Pillar | Tasks |
|---|---|
| Identity | 6 |
| Devices | 6 |
| Network | 6 |
| Applications | 4 |
| Data | 4 |
| Visibility and Analytics | 5 |
Zero Trust is not yet a mandatory certification in the way that PCI DSS or Cyber Essentials are, but it is increasingly required by government clients and large enterprises. The US federal government has mandated a Zero Trust strategy for all agencies. The UK National Cyber Security Centre has published Zero Trust design principles. Many enterprise clients are beginning to require evidence of Zero Trust progress from their technology vendors and service providers.
Even without a formal requirement, the Zero Trust model is widely considered the most effective approach to modern security — particularly in environments where users work from multiple locations and devices.
Start with the Identity and Devices pillars. These two pillars are foundational — if identity and device health are not feeding into access decisions, the other pillars have limited value.
The Applications pillar includes a task to discover shadow IT using Microsoft Defender for Cloud Apps. This often surfaces tools that the IT team was not aware of and is worth completing early because the findings can affect other tasks.
The Visibility pillar requires Sentinel to be configured and connected. This is a significant project dependency. If Sentinel is not yet in place, mark those tasks as Blocked and plan the Sentinel deployment separately.
NIST Special Publication 800-37 Revision 2, the Risk Management Framework (RMF), is a structured seven-step process for managing security risk in information systems. Published in December 2018, it is used primarily by US federal agencies and organisations that work with the federal government, though it is applicable to any organisation that wants a formal, documented approach to security risk management.
Where other frameworks in this tool focus on what technical controls to implement, the RMF focuses on the process of formally deciding, documenting, testing, and authorising those controls. It connects technical security work to the governance and risk management decisions made by leadership.
At the end of the RMF process, a senior official called the Authorizing Official (AO) makes a formal, documented decision about whether the risk of operating a system is acceptable. This decision is called an Authority to Operate (ATO). An ATO is a significant milestone and is required for federal systems before they can go into production.
Step 1 — Prepare Before anything else, you need to establish the foundation for the risk management programme. This means defining who is responsible for what, what risk tolerance the organisation has, what systems are in scope, and what the overall monitoring strategy will look like.
In this tool, the Prepare tasks cover documenting the risk management strategy, formally assigning the Authorizing Official, Information System Security Officer, and Information System Security Manager roles, defining the system boundary (which devices, users, and services are included), identifying which security controls are provided by Microsoft and can be inherited, and documenting how the deployment will be continuously monitored.
Step 2 — Categorize You need to classify the system based on the sensitivity of the information it processes and the potential impact if that information were compromised or the system were unavailable.
The classification uses a US standard called FIPS 199, which assigns Low, Moderate, or High impact levels for Confidentiality, Integrity, and Availability. The highest of the three becomes the system's overall classification, which then determines which set of controls must be implemented.
In this tool, the Categorize tasks cover identifying all the types of information the MDE deployment handles (such as security event data, vulnerability data, and identity data), assigning FIPS 199 impact levels to each type, documenting how data flows through the system, and registering the system in the organisation's risk management programme.
Step 3 — Select Based on the system's classification from Step 2, you select the appropriate security control baseline from NIST 800-53. You then review and tailor that baseline — adding controls that address specific risks, removing controls that do not apply to the technology used, and documenting the reasons for every tailoring decision.
In this tool, the Select tasks cover choosing the right baseline (Low, Moderate, or High), tailoring it for a cloud-hosted MDE deployment, populating the System Security Plan control table, and mapping the continuous monitoring controls to the specific MDE and Sentinel capabilities that will satisfy them.
Step 4 — Implement This is the step where you actually configure the controls. The implement tasks in this tool align directly with the NIST 800-53 framework tab — completing those tasks and documenting each implementation constitutes the implementation step of the RMF.
The implementation must be documented in the System Security Plan in enough detail that an independent assessor can understand what was done, why it was done, and how to verify it.
Step 5 — Assess An independent assessor — someone not directly responsible for implementing the controls — examines the implementation to determine whether each control is correctly implemented, operating as intended, and producing the desired security outcome.
The assessor reviews documentation, interviews the security team, and tests controls directly. Tests for MDE controls include verifying that antivirus detects a test file, confirming that multi-factor authentication blocks an unauthenticated login attempt, and checking that role-based access prevents unauthorised viewing of devices.
The outcome is a Security Assessment Report (SAR) that lists each control as Satisfied, Other Than Satisfied, or Not Applicable. Controls that are Other Than Satisfied become Plan of Action and Milestones (POA&M) items — documented gaps with remediation plans and target dates.
Step 6 — Authorize The Authorizing Official reviews the complete authorisation package — the System Security Plan, the Security Assessment Report, and the POA&M — and makes a risk-based decision about whether to issue an ATO.
The ATO is a formal memorandum signed by the AO that states the system is authorised to operate, for how long (typically three years), and under what conditions (any open POA&M items that must be resolved).
Step 7 — Monitor Once an ATO is issued, the system must be continuously monitored to ensure controls remain effective and the risk posture does not deteriorate. This is not a one-time review — it is an ongoing programme.
Monitoring activities include reviewing MDE Secure Score and TVM Exposure Score monthly, reporting security status to the AO regularly, managing changes through a formal change control process, and maintaining the POA&M as a living document that tracks open items to closure.
31 tasks across seven steps.
| Step | Tasks |
|---|---|
| Prepare | 5 |
| Categorize | 4 |
| Select | 4 |
| Implement | 5 |
| Assess | 4 |
| Authorize | 4 |
| Monitor | 5 |
NIST RMF is mandatory for US federal agencies and systems that process federal information. It is the underlying process for FedRAMP authorisation, which is required for cloud service providers selling to the federal government.
Defence contractors and organisations in the defence industrial base may also be required to follow RMF processes. Some state and local government programmes adopt RMF as well.
The RMF is a process, not just a list of technical controls. Work through the steps in sequence — attempting to write the System Security Plan before defining the system boundary, or conducting an assessment before implementing controls, will create confusion and rework.
The documentation tasks are substantial. Allow significant time for them and involve non-technical staff — the CISO, legal team, and programme management office typically need to contribute to the System Security Plan and authorisation package.
The Implement tasks in this framework are closely related to the NIST 800-53 tasks. If you have already completed the NIST 800-53 framework tab, the implementation documentation work is essentially recording what you did in that tab in the System Security Plan format.
NIST AI 100-1, the Artificial Intelligence Risk Management Framework, was published by NIST in January 2023. It provides guidance for organisations that develop, deploy, or use artificial intelligence systems to identify and manage the risks those systems introduce.
This framework is included in this tool because Microsoft Defender for Endpoint uses artificial intelligence and machine learning in several of its core capabilities. These AI-powered features make MDE more effective, but they also introduce risks that are different from traditional security controls — risks that traditional frameworks do not fully address.
The AI RMF does not require you to be an AI expert. It provides a structured way to ask the right questions about AI-powered tools and put appropriate oversight in place.
Traditional security controls do what they are configured to do. If you configure a firewall rule to block a specific IP address, it blocks that IP address. The outcome is predictable.
AI-powered security controls are different. They learn from data and make probabilistic judgments. This creates two categories of risk that do not exist with traditional controls:
False positives — the AI incorrectly identifies something legitimate as a threat and takes action against it. In MDE, this might mean a legitimate business application is flagged as malware and quarantined, or a developer's test server is isolated from the network because its behaviour pattern resembled an attack technique. These actions disrupt business operations.
False negatives — the AI fails to identify a real threat. An attacker's technique does not match the patterns the AI has learned to recognise, so it passes undetected.
Both of these risks need to be managed, and managing them requires different thinking than managing traditional security controls.
Govern (AI-GV) This function covers establishing the policies, roles, and oversight structures for AI risk. Before deploying AI-powered capabilities like Automated Investigation and Remediation (AIR), the organisation should define who is accountable for the outcomes of those automated actions, what level of automation is acceptable for different types of systems, and how errors will be escalated and corrected.
In this tool, Govern tasks cover writing an AI risk governance policy that specifically addresses MDE automated features, designating an AI Risk Owner (accountable for outcomes) and an AI Oversight Lead (responsible for monitoring AI behaviour day-to-day), documenting which device groups are allowed to use full automation versus those that require human approval before automated actions execute, reviewing Microsoft's published responsible AI documentation, and establishing governance for Microsoft Security Copilot if it is licensed.
Map (AI-MAP) This function covers identifying and categorising the AI risks specific to your deployment. You cannot manage risks you have not identified. The Map function asks you to think systematically about where AI is being used, what can go wrong, and what the business impact would be.
In this tool, Map tasks cover producing an inventory of every AI-powered feature in the MDE deployment, mapping the potential business impact of incorrect automated actions (for example, what happens if a production server is incorrectly isolated), analysing the false positive rate of different alert types to identify which ones carry the most risk, documenting the organisation's dependency on Microsoft's AI models and understanding how those models are updated, and examining whether the detection models might behave differently for different device types or software configurations.
Measure (AI-MEA) This function covers quantifying AI performance and risk using metrics. You need data to know whether the AI is performing well and whether the risks identified in the Map function are materialising.
In this tool, Measure tasks cover tracking the false positive and false negative rates for AI-generated alerts, measuring the accuracy of automated remediation actions (how often did AIR do something that turned out to be wrong), monitoring for sudden changes in alert volumes that might indicate model drift (where a model's behaviour changes unexpectedly), establishing a quality rating process for Security Copilot outputs if it is deployed, and building a dashboard that shows AI performance KPIs over time.
Manage (AI-MAN) This function covers treating AI risks through practical controls and feedback loops. Identifying and measuring risks is only useful if you take action to address them.
In this tool, Manage tasks cover enforcing human approval for all automated remediation actions on critical systems, defining a formal process for analysts to contest or override an AI-generated decision, running a monthly detection tuning cycle where false positive patterns are reviewed and suppression rules are updated, logging AI-introduced disruptions as AI Incidents and tracking them separately from security incidents, and documenting specific procedures for handling common AI error scenarios such as an incorrectly isolated device or a legitimate file incorrectly quarantined.
21 tasks across four functions.
| Function | Tasks |
|---|---|
| Govern | 6 |
| Map | 5 |
| Measure | 5 |
| Manage | 5 |
The AI RMF is not yet mandatory in the way that PCI DSS or NIST 800-53 are. However, AI governance is a rapidly evolving area of regulation. The EU AI Act, US executive orders on AI, and emerging guidance from NCSC and other bodies are all moving towards formal requirements for AI governance in security contexts.
More immediately, clients and auditors who are aware of AI risks are beginning to ask how AI-powered security tools are governed. Having a documented AI risk management approach — even a basic one — is increasingly a differentiator.
Start with the Govern function. Without a governance policy and defined roles, the other functions lack accountability.
The Measure function requires data that accumulates over time. False positive rates cannot be calculated on day one — you need a period of operational data. Start the measurement tasks early so that data is available when you need it.
The Manage function includes a monthly detection tuning cycle. This is an ongoing operational activity, not a one-time configuration. Build it into your team's regular schedule as a standing activity.
If Microsoft Security Copilot is not licensed, the Copilot-related tasks in Govern and Measure can be marked as Not Applicable with a brief note explaining that Copilot is not deployed.