Safeguard 10.5 anti-exploitation features: what the requirement asks for
If you run an IG2 or IG3 enterprise and an assessment or customer questionnaire asks whether exploit mitigations are switched on, Safeguard 10.5 is the requirement behind that question. It asks you to enable anti-exploitation features on enterprise assets and software where possible. Unlike the other Control 10 safeguards, which concern finding and stopping malware, 10.5 targets the way attackers abuse memory corruption and other software flaws to run code they should not be able to run. CIS names Microsoft Data Execution Prevention (DEP), Windows Defender Exploit Guard (WDEG), and Apple System Integrity Protection (SIP) and Gatekeeper as example features. CIS assigns the safeguard to the Devices asset class and the Protect security function, and places it in Implementation Group 2, so IG1 organizations are not required to meet it. The CIS Navigator maps 10.5 to NIST SP 800-53 Rev. 5 control SI-16, ISO/IEC 27001:2022 Annex A control 8.7, and AICPA SOC 2 criterion CC6.8. Confirm those mappings against the current Navigator before you cite them in a response, because mappings are revised between versions.
The requirement is harder to meet than it sounds for three reasons. First, fleets are mixed. Windows servers, Windows workstations, macOS laptops and Linux hosts each expose different anti-exploitation settings, and some of those settings are defaults that a hardening baseline may have changed. Second, legacy applications often break when DEP or exploit protection is enforced, so teams create exceptions. Exceptions are reasonable, but each one needs an owner, a documented reason and a review date, or the safeguard quietly stops applying to the assets that carry the most risk. Third, enabling a feature is not the same as proving coverage. The CIS Assessment Specification scores 10.5 with a Coverage metric, the share of assets properly configured to enable anti-exploitation features, and it depends on a complete asset inventory (Safeguard 1.1) and a secure configuration process (Safeguard 4.1). If you cannot list your assets or show how configuration is approved, you cannot produce a credible coverage figure. Start by confirming which assets and operating systems are in scope, then decide how exceptions are approved before you collect any evidence.
Which assets, teams and scoping choices decide the 10.5 workload
Safeguard 10.5 is measured as a coverage share, so the size of the work depends on which assets and software sit in scope and how well the enterprise knows them. The cards below cover the scoping decisions, the two prerequisites the assessment specification names, and the exceptions that need an owner.
Workstations, servers and mobile devices
Scope starts with the enterprise asset inventory. Workstations, servers, and mobile or other endpoints each have different exploit mitigation options, so list them by class before counting coverage. Every asset in the denominator must be classified, because a device left out of the inventory simply escapes measurement. Ask whether virtual machines, cloud instances and contractor-managed laptops are included, and record the decision in writing.
Operating system and application features
The safeguard names Microsoft Data Execution Prevention, Windows Defender Exploit Guard, and Apple System Integrity Protection and Gatekeeper as examples. Decide which operating system features and which applications, such as browsers and Office-type suites, fall under the setting. Each product exposes its own configuration, so the scope list should name the setting for each platform rather than a general claim that protection is on.
IG1-only organizations
Safeguard 10.5 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises. An organization that has adopted only IG1 Safeguards does not need to measure it yet, though enabling these features on managed devices is a low-cost step that many teams take early. Confirm your Implementation Group before you commit assessment effort to this Safeguard.
Asset inventory as a prerequisite
The assessment specification lists Safeguard 1.1, the detailed enterprise asset inventory, as a prerequisite. Coverage is a share of assets, so an unknown device cannot be counted as either configured or missing. Unmanaged endpoints, shadow devices and retired hosts distort the result in both directions. Reconcile discovery output against the inventory before measuring.
Secure configuration process as a prerequisite
Safeguard 4.1 requires a documented secure configuration process, and the specification names it as a prerequisite for 10.5. The process decides who sets the anti-exploitation options, how the setting is deployed through policy, and how deviations are recorded and approved. Without it, a team may turn a feature on in one environment while another stays at its default, and the assessor has no baseline to test against.
Legacy software exceptions
Some legacy applications break when exploit mitigations are enforced. Any exception should carry a named, approved owner, a documented reason, a compensating control and a review date. Ask the owner to confirm the risk acceptance in writing, and track exempt assets as a separate group so the coverage figure stays honest. Undocumented exceptions are the most common gap an assessor finds in this area.
How an assessor tests anti-exploitation features under CIS 10.5
This table walks through the parts of the CIS Controls Assessment Specification that apply to Safeguard 10.5, from the Coverage metric and its prerequisites to the sample, the evidence per platform and the findings assessors see most. The CIS specification states what to measure, so the test method, sample and evidence standard come from the assessor and your own records. Use the rows as a checklist of what to have ready before fieldwork starts.
| Test element | What the assessor looks for | Common finding |
|---|---|---|
| Coverage metric | Share of in-scope assets properly configured to enable anti-exploitation features | Coverage calculated on a partial or outdated asset list |
| Prerequisite 1.1 | A detailed enterprise asset inventory that defines the population the Coverage metric divides by | Assets missing from the inventory, so they never enter the calculation |
| Prerequisite 4.1 | A documented secure configuration process that sets the anti-exploitation baseline and who approves it | Baseline written but not tied to the platforms actually deployed |
| Population and sample | Devices in IG2 and IG3 scope, drawn across operating systems, locations and asset owners | Sample limited to servers, leaving endpoints and laptops untested |
| Windows evidence | Configuration output showing Data Execution Prevention and Windows Defender Exploit Guard settings on each sampled device | Settings present in policy but not applied on the endpoint |
| Apple evidence | Output showing System Integrity Protection and Gatekeeper status on sampled macOS devices | Gatekeeper disabled for a user or a local exception |
| Local overrides | Confirmation that user or local settings cannot turn off the enforced features | Users or local administrators disabling features without central record |
| Exceptions | A documented, approved exception for each asset without the feature, with a reason and review date | Exceptions granted informally or never reviewed |
Implementing anti-exploitation features step by step
This sequence takes Safeguard 10.5 from an unknown starting point to a documented, measured and exception-managed state, where the share of assets with anti-exploitation features enabled can be reported as Coverage. Each step produces a record that an assessor can trace.
Confirm the asset inventory from Safeguard 1.1
Start from the detailed enterprise asset inventory required by Safeguard 1.1, since the CIS Controls Assessment Specification lists it as a prerequisite for measuring Safeguard 10.5. Group assets by operating system, version and role, and separate Windows, macOS and Linux endpoints, servers and any software that runs outside the operating system. The control owner signs off the inventory. The output is an inventory extract that the Coverage calculation can use as its denominator.
Define the approved exploit mitigation baseline
Write a baseline for each platform in the inventory. For Windows, specify the Data Execution Prevention policy and the Windows Defender Exploit Guard settings your organization has tested. For macOS, specify System Integrity Protection and Gatekeeper, and confirm the settings with your own security and platform teams. Record which applications need compatibility exceptions. The output is a versioned baseline document approved by the control owner.
Apply the baseline through the secure configuration process
Put the baseline into the secure configuration process defined under Safeguard 4.1 so changes are documented, reviewed and repeatable. Implement the settings through your existing configuration management, group policy, mobile device management or image pipeline, whichever already governs the asset class. Do not make manual changes on individual machines that the pipeline cannot reproduce. The output is a configuration record linking each baseline item to the tool and version that enforces it.
Verify enablement on a pilot group
Select a pilot group that covers each platform and major application type. Confirm on each pilot asset that the settings are active, then check that business applications still start and run as expected. Scan the pilot assets with a configuration assessment or query tool to confirm the settings' state independently of the deployment tool. The output is a pilot test report listing failures, compatibility issues and the fixes applied to the baseline.
Roll out and measure Coverage
Deploy the baseline to the remaining in-scope assets in controlled waves. After each wave, measure Coverage as the share of assets that are properly configured to enable anti-exploitation features, using the inventory from the first step as the denominator. Repeat the measurement on a schedule you define and keep the results. Ask your tooling vendor or implementation partner to confirm which fields the report can export. The output is a Coverage report with the date, the asset count and the failing assets listed by name.
Handle exceptions with owners and review dates
Assets that cannot run a setting, such as legacy systems or vendor appliances, need a documented exception. Each exception should name the asset, the setting that is not enabled, the business reason, a compensating measure and an accountable owner. Set a review date for each exception and track it in your risk register. Remove exceptions when the asset is retired or upgraded. The output is an exception register that matches the Coverage report, so every failing asset is either fixed or explained.
Evidence that proves anti-exploitation features are enabled
An assessor testing Safeguard 10.5 wants to see a defined baseline, proof that each asset matches it, and a documented record of every deviation. The cards below cover the artifacts that connect those three things, and the same set can be reused for the SI-16, ISO/IEC 27001:2022 Annex A 8.7 and SOC 2 CC6.8 mappings once you confirm them against the current Navigator.
Approved exploit mitigation baseline
This is the document that defines the target state: which settings must be on for each platform, including Microsoft Data Execution Prevention, Windows Defender Exploit Guard, Apple System Integrity Protection and Gatekeeper. It should name an owner, an approval date and the version of the baseline in force. Without it, an assessor has nothing to measure Coverage against. Check that each setting is written as a testable state, not as a general intention.
Per-platform configuration records
Keep captured records showing the actual state of DEP, Exploit Guard, SIP and Gatekeeper on each device or platform group. Capture them from the endpoint, not from the build template, because a correct image can drift after deployment. Record the platform, the setting name, the value and the capture time. Scheduled osquery or Wazuh configuration assessment runs can produce these records, with results exported to dated files for the audit folder.
Coverage calculation with asset population
Safeguard 10.5 is scored by Coverage: the share of assets properly configured to enable anti-exploitation features. Store the calculation with the numerator, the denominator, the asset population used and the date it was run. The denominator must come from the Safeguard 1.1 asset inventory, so an unmanaged device that is missing from the list also lowers the score. Confirm with your assessor how they want assets excluded.
Exception register with approvals
Some assets cannot run a feature, such as legacy systems or appliances with vendor-restricted settings. Each one needs a register entry naming the asset, the setting not enabled, the compensating control, the risk owner who accepted it and an expiry or review date. Assessors commonly test whether exceptions are approved and reviewed, so an entry with no approver is a finding waiting to happen.
Change records for baseline updates
When the baseline changes, for example when a new Exploit Guard rule is added or a Gatekeeper setting is tightened, keep a change record linking the old and new baseline versions, the approval, the rollout date and the assets affected. This shows the Safeguard 4.1 secure configuration process is operating. Check that every change record points back to the exact baseline version it updates.
What enabling anti-exploitation features costs
This table breaks down the cost components of enabling anti-exploitation features under Safeguard 10.5, showing who is paid, whether each item is one-time or recurring, and what pushes it up or down. Use it to structure a quote request, because no figures are supplied for these components and the actual amounts depend on your fleet and scope. The main takeaway is that the operating system features themselves are often already owned, so most of the spend goes to baseline design, legacy testing and evidence upkeep.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Anti-exploitation platform features (DEP, Windows Defender Exploit Guard, Apple SIP and Gatekeeper) | Often included with the operating system, so usually no separate feature license; confirm edition entitlements with the vendor | Recurring only if licensed tiers are required | Up: needing a management tier or a product edition not already owned. Down: features already enabled on current OS versions |
| Endpoint management or configuration tooling licenses | Software vendor or open-source project; commercial licenses paid to the vendor | Recurring (subscription or support) | Up: per-device commercial pricing and premium support tiers. Down: self-hosted open-source reporting such as Wazuh, Fleet or osquery, which removes license spend but not operating effort |
| Baseline design and secure configuration process (Safeguards 1.1 and 4.1 prerequisites) | Internal engineering or implementation partner, billed by fixed scope or time | One-time, with periodic review | Up: no existing asset inventory or configuration process. Down: a documented hardening standard and standard images already in place |
| Rollout engineering and change management | Internal platform or endpoint team, or an implementation partner under a written scope | One-time per platform and OS version | Up: many OS versions, multiple device owners and manual deployment. Down: one managed deployment path and automated policy push |
| Compatibility testing for legacy software | Internal application owners and testers, sometimes a partner | One-time per wave, plus retesting after major updates | Up: legacy applications that depend on disabled or relaxed mitigations. Down: vendor-supported applications with documented compatibility |
| Exception handling and approvals | Security and application owners, with documented risk acceptance | Recurring, as exceptions are reviewed | Up: the number of exceptions and their age. Down: few exceptions with fixed review dates and compensating controls recorded |
| Evidence collection and upkeep | Internal compliance or security staff; partner if preparing evidence packages | Recurring, at each assessment cycle | Up: manual screenshots and spreadsheets. Down: automated Coverage reports from configuration assessment tooling |
| Assessor sampling and audit support | Independent auditor or assessor, paid under their own engagement terms | Recurring, per assessment | Up: large device populations sampled across many configurations. Down: clean, reproducible evidence per asset class |
Which open-source tools can produce 10.5 evidence
Safeguard 10.5 is scored on the share of assets properly configured for anti-exploitation features, so the evidence is a per-device configuration record. The four tools below can read, query or collect that state across a fleet, but none of them turns the features on by itself. Each card explains what the tool contributes, where it stops, and what to confirm before relying on it.
Wazuh configuration assessment
Wazuh Security Configuration Assessment scans monitored endpoints against YAML policies, largely based on CIS benchmarks, and checks files, directories, registry keys and running processes. For 10.5, write or extend a policy that tests the registry or process state for DEP, Exploit Guard or SIP where your platform exposes it, then use the pass or fail results as Coverage evidence. Confirm each check against your own OS build, since a policy that reads a setting is not the same as proof the protection is enforced. Wazuh is licensed under GPL-2.0-only.
Fleet policies as evidence
Fleet policies are yes or no questions asked of devices as osquery queries, and the policies page shows which devices in each fleet pass or fail. A policy such as whether a given anti-exploitation setting is enabled gives you a per-device pass rate that maps directly to the Coverage metric. Write each policy so a failing result names a clear remediation, and retain the results over time to show the share of assets passing. Fleet is licensed under MIT. Confirm which settings your queries can read on each platform before counting a device as compliant.
osquery for host state
osquery exposes running processes, loaded kernel modules, open network connections and file hashes as SQL tables, and its osqueryd daemon schedules those queries across a whole fleet. Use it to show what is actually running on each host, for example whether a protected process is active and whether unexpected code is loaded. This is inspection evidence rather than a configuration setting, so pair it with a policy that records the setting itself. osquery is dual-licensed under Apache-2.0 OR GPL-2.0-only, so confirm which license terms your distribution relies on.
Velociraptor hunts and offline collection
Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts that gather one or more artifacts across a group of systems. Hunts are useful when you need a point-in-time sweep of anti-exploitation settings across hosts that were not in your last inventory, and offline machines collect when they reconnect, which helps close gaps in coverage counts. Keep a dated record of each hunt and its notebook as supporting evidence. Velociraptor does not manage the configuration itself. It is licensed under AGPL-3.0-only, which carries network-use obligations to check with counsel if you modify it and offer it to users.
Who does what: your team, an implementation partner and the auditor
Your organization remains accountable for Safeguard 10.5. Only your people can decide which operating system and software anti-exploitation features apply to each asset class, where exceptions are acceptable, and what counts as a properly configured asset for the Coverage metric. The CIS Controls Assessment Specification measures the share of assets configured to enable these features, so the denominator (which assets are in scope) depends on the asset inventory and secure configuration process, which are prerequisites from Safeguards 1.1 and 4.1.
- Baseline ownership: Approve the list of anti-exploitation settings, such as Microsoft DEP, Windows Defender Exploit Guard, and Apple System Integrity Protection and Gatekeeper, for each platform you run.
- Exception decisions: Record which assets cannot enable a feature, why, and who accepted the risk, with a review date.
- Coverage definition: Agree in writing what "properly configured" means and which assets fall outside the measured population.
- Sign-off: Approve the baseline, exceptions and the periodic Coverage result before they are used as evidence.
- Internal assurance: Review the evidence yourself before the auditor sees it.
Check that someone on your side can name each exception owner and that the Coverage numerator and denominator are documented in your own policy.
An implementation partner such as DeployOpen prepares the systems and evidence that let your team measure Safeguard 10.5. Work typically runs under a written, fixed scope inside your cloud accounts, data centers or air-gapped networks, so configuration data and endpoint telemetry stay under your control. The partner does not set your risk appetite, approve exceptions or decide whether the control is effective.
- Configuration work: Draft the hardening settings for each platform and test them on representative assets before rollout.
- Tooling deployment: Install and configure monitoring tools such as Wazuh, Fleet with osquery, or Velociraptor where you choose them.
- Measurement: Build the queries or checks that produce the Coverage figure from your asset records.
- Evidence packaging: Organize configuration exports, scan results and change records into a form your auditor can sample.
- Documentation and handover: Deliver runbooks so your staff can operate the checks after the engagement ends.
Before signing, ask the partner which deliverables are fixed, which items require your decisions, and who keeps the evidence after handover.
The independent auditor or assessor tests whether Safeguard 10.5 is implemented and operating as described. Depending on the engagement, that may be an internal audit function, an external CIS Controls assessor, or a certification body for a framework that maps to this safeguard. Only that independent party issues a report, attestation or certificate. DeployOpen prepares systems, controls and evidence for assessment, but does not issue audit reports, attestations or certifications.
- Test design: The auditor decides sample sizes and which assets to inspect, often using the Assessment Specification as a reference.
- Independent testing: The auditor re-performs checks rather than relying only on a dashboard you built.
- Reporting: Only the auditor issues findings, opinions or any certificate, in its own name.
- Scope confirmation: The auditor confirms the asset population and the exceptions your team approved.
- Independence: Auditors should not design the controls they test for the same engagement.
Confirm the auditor's accreditation or professional standing for the work and agree the sampling approach before evidence collection begins.
Where 10.5 programs usually fall short and how to close each gap
Safeguard 10.5 programs tend to fail in predictable places: the asset population is incomplete, the setting is uneven, exceptions drift, and the reported number cannot be reproduced. Each card names one gap and the check that closes it, using the prerequisites and Coverage metric in the assessment specification.
Unmeasured assets from a weak inventory
Coverage is a share, so the denominator decides the result. The assessment specification lists Safeguard 1.1, the detailed enterprise asset inventory, as a prerequisite for measuring 10.5. If laptops, virtual machines, servers or contractor devices are missing from the inventory, they never enter the calculation and the score looks better than the estate is. Reconcile the 10.5 population against the 1.1 inventory before reporting any percentage, and record which asset classes are in scope.
Protections enabled on some platforms only
Safeguard 10.5 names Microsoft DEP, Windows Defender Exploit Guard, and Apple System Integrity Protection and Gatekeeper as examples, so a fleet with mixed operating systems needs a platform-by-platform baseline. A Windows population may be configured while macOS or Linux hosts, or older builds, sit outside the policy. Define one expected setting per platform and version, then check each platform separately so a strong result on one does not hide a gap on another.
Local overrides that switch protections off
A protection can be enabled centrally and disabled on a single machine by a local setting, a troubleshooting change, or a compatibility workaround that was never reverted. Because the central policy still reads as compliant, the drift stays silent. Configuration checks should compare the effective state on each endpoint, not only the policy that was pushed. Wazuh's Security Configuration Assessment can check registry keys and running processes against YAML policies, which helps surface local changes. Test the effective setting on the endpoint rather than trusting the policy document.
Exceptions with no owner or review date
Some legacy applications break when exploit mitigations are enforced, so teams create exceptions to keep operations running. Without a named owner, a documented reason and a review date, these exceptions become permanent exposure that nobody tracks. Each exception should record the affected asset, the protection it disables, the compensating control and the person accountable for retiring it. Require an owner and an expiry for every exception and report open exceptions alongside the Coverage figure so the gap stays visible to leadership.
Coverage reported without population or date
A figure such as a single coverage percentage has little value to an assessor unless it states what was counted and when. The 10.5 metric is the share of assets properly configured, so the report needs the asset count, the date of collection and the source of the data. Without these, the number cannot be re-performed or compared across quarters. Publish the numerator, denominator and collection date together and keep the calculation query with the report so the figure can be reproduced.
Relying on one screenshot as evidence
A screenshot of a policy page shows a setting on one machine at one moment. It does not show that the setting held across the fleet during the assessment period. Repeatable evidence means a query or scheduled check that runs across all in-scope hosts and keeps dated results. Fleet policies, written as osquery queries, show which devices pass or fail each policy, and osqueryd can schedule those checks across hosts. Replace point-in-time screenshots with scheduled queries and retained results that an assessor can rerun.
Questions buyers ask before enabling anti-exploitation features
Does Safeguard 10.5 apply to IG1 organizations?
No. Safeguard 10.5 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises but not to IG1. IG1 is the essential cyber hygiene baseline that every enterprise should meet, and it does not include this safeguard. An IG1 organization can still enable exploit protections such as Microsoft Data Execution Prevention or Apple Gatekeeper as good practice, but an assessor will not score it against 10.5 unless the organization has moved up to IG2 or IG3. Confirm your Implementation Group against the CIS Controls v8.1 Implementation Groups page before you scope the work.
How much effort does enabling anti-exploitation features take?
The effort depends mostly on the number and variety of enterprise assets, not on the settings themselves. Turning on a feature such as Data Execution Prevention is usually a configuration change, but each operating system version, server role and line-of-business application may behave differently under the same setting. The main drivers are how many device types you run, how many applications need compatibility testing, whether settings are enforced through a central policy or changed by hand, and how much exception handling you need for legacy software. No fixed effort figure is supplied here, so ask any provider to break the estimate down by asset class, platform and application, and to state which items are one-time and which recur.
How long does the work take, and what depends on the asset inventory?
The timeline is driven by how complete your asset inventory is. The CIS Controls Assessment Specification lists Safeguard 1.1, the detailed enterprise asset inventory, as a prerequisite for measuring 10.5, so you cannot show coverage for devices you have not recorded. Secure configuration process work under Safeguard 4.1 is the second prerequisite. If the inventory is current, the work is mainly rollout, testing and exception review. If it is not, the first phase is discovery and reconciliation. Ask for a schedule that separates inventory validation, pilot testing, phased rollout and evidence collection, and confirm the duration with your own change calendar, since no general duration is supplied.
Can our own team enable anti-exploitation features in-house?
Often yes, if your team already manages endpoint configuration and has a working change process. The settings named in CIS guidance, including Data Execution Prevention, Windows Defender Exploit Guard and Apple System Integrity Protection and Gatekeeper, are standard platform features that administrators can manage through their existing tools. In-house teams usually struggle with compatibility testing, documenting exceptions and producing repeatable evidence. An implementation partner can prepare the configuration baseline, automate checks and document the results, but the organization keeps ownership of the control and of the decisions about exceptions. Decide before you start which of those tasks your team will keep.
What does the team need to provide for this work?
You need named owners for four things: the asset inventory, the endpoint configuration process, the change approval path and the exception register. Endpoint administrators must be able to push settings through group policy, mobile device management or your configuration tool. Application owners must test critical software against the enforced settings before rollout, and a security lead should approve any exclusions. Write these roles down in the engagement scope so that testing windows, access to test devices and sign-off points are agreed before work begins.
How do we measure Coverage for Safeguard 10.5?
The CIS Controls Assessment Specification scores 10.5 with a Coverage metric: the share of assets that are properly configured to enable anti-exploitation features. To calculate it, divide the number of in-scope assets with the required settings enabled by the total number of in-scope assets from your inventory. Define in advance what counts as properly configured for each platform, and record exceptions separately so they are visible rather than hidden in the percentage. Use your endpoint management or osquery-based checks to produce the numerator, and keep the dated export as evidence. Confirm the exact measurement method with your assessor, because the specification defines what to measure but not how to collect it.
How does an independent assessor check Safeguard 10.5?
An assessor reviews whether the configuration exists, whether it is applied across the inventory and whether the organization can show it over time. Expect them to ask for the inventory, the configuration baseline, the enforcement method, a sample of endpoint results and the exception register with approvals. They may test a sample of devices directly. Only the assessor issues the findings or any report. Your implementation partner can prepare the evidence and walk through it, but cannot attest to the result. Confirm with your assessor which sample sizes and evidence formats they accept before you collect anything.
How DeployOpen scopes and prepares 10.5 evidence
DeployOpen works on Safeguard 10.5 by agreeing in writing which enterprise assets and software are in scope, then preparing the configurations and evidence the assessment specification measures. The organization keeps ownership of its controls, and DeployOpen does not issue audit reports or certifications.
How we scope
- Agree in writing which Windows, macOS and Linux enterprise assets fall under the Safeguard 10.5 Coverage measure.
- Confirm the asset inventory and secure configuration process that the 1.1 and 4.1 prerequisites depend on.
- Record which anti-exploitation features apply to each asset class, such as DEP, Exploit Guard or SIP and Gatekeeper.
How we build
- Configure the anti-exploitation settings on in-scope endpoints with the organization's chosen tooling and change control.
- Deploy Wazuh Security Configuration Assessment policies and osquery or Fleet queries that check the enabled state on each device.
- Test that the checks report passing and failing devices accurately before the scope is treated as complete.
How we hand over
- Deliver a coverage report showing the share of in-scope assets with anti-exploitation features enabled, with exceptions listed.
- Document the configuration baseline, the exception approval path and the remediation steps for failing devices.
- Hand over evidence packs for your auditor or assessor, who alone decides whether the evidence is sufficient.
How we support
- Ongoing support, upgrades and monitoring of the checks are available as a retainer after handover.
- Re-run coverage checks after operating system upgrades or new device builds, as agreed in the scope.
- Confirm with your vendors and environment which features each platform version supports before final scoping.
