CIS Safeguard 4.10 device lockout requirements and evidence

What Safeguard 4.10 requires for portable device lockout

If you are a compliance lead or engineer who must show that laptops, tablets and phones lock after repeated failed local logins, start with the wording of the Safeguard itself. Safeguard 4.10 asks that portable end-user devices, where supported, lock after a set number of failed local authentication attempts, with no more than 20 failed attempts allowed on laptops and no more than 10 on tablets and smartphones. The phrase "where supported" matters: if a device platform cannot enforce a lockout threshold, you need to document that limitation and show what compensating control covers it, rather than silently treating the device as compliant. CIS cites Microsoft Intune Device Lock and the Apple Configuration Profile maxFailedAttempts setting as example implementations, so a managed fleet on either platform has a concrete place to look for the setting.

The risk behind the Safeguard is straightforward. A laptop or phone that is lost or stolen can be subjected to repeated guesses at its local PIN or password, and an unlimited number of attempts makes that guessing practical. A lockout threshold converts an open-ended attack into a bounded one. In the CIS Controls, Safeguard 4.10 sits in the Devices asset class and the Protect security function, and it is assigned to Implementation Groups 2 and 3 but not IG1. Organizations that only meet IG1 will therefore not find it in their baseline, although a regulator or customer may still ask for it. Confirm the Implementation Group your scope requires before you plan the work.

The difficulty is usually not the setting itself but knowing which devices actually carry it. Unmanaged devices, mixed fleets of Windows, macOS, iOS and Android hardware, and profiles that were pushed once and never checked all produce gaps that a policy document will not reveal. Decide who owns the enforced value for each platform, which devices fall outside management and how exceptions are approved and reviewed. Then verify the setting on endpoints rather than trusting the configuration record. Measuring Safeguard 4.10 also depends on an accurate device inventory (Safeguard 1.1) and a documented secure configuration process (Safeguard 4.1), so those should be in place first.

Which portable devices and teams fall under Safeguard 4.10

Safeguard 4.10 applies to portable end-user devices where the lockout setting is supported, and only from Implementation Group 2 onward. The scoping decisions below determine which devices carry the requirement and which teams must produce the evidence that a reviewer will test.

Enterprise-owned laptops and tablets

Organization-owned laptops and tablets are the core population for this Safeguard. Confirm which models in the fleet expose a local failed-attempt lockout setting, because the threshold of no more than 20 attempts for laptops and no more than 10 for tablets and smartphones applies per device class. Record any model that cannot be configured, since the 'where supported' condition needs a documented justification rather than silent exclusion.

Smartphones and tablets in scope

Smartphones and tablets carry the stricter ceiling of no more than 10 failed local attempts, so mixed fleets need separate policy targets. Confirm whether phones are fully managed, partly managed or unmanaged, because only devices that the organization can configure can be measured against the threshold. Illustrative example: a phone enrolled only for email may lack the policy entirely and must be tracked as an exception.

Personal devices enrolled for work

Bring-your-own-device enrollment changes who controls the lockout setting. Decide whether the enterprise can enforce the threshold on the whole device or only inside a managed work container, and document what that boundary means for the claim you make. Ask legal and HR to confirm the enrollment terms, because a personal device the organization cannot lock is a scoping gap that auditors will expect to see addressed.

Prerequisite inventory and process

The CAS names Safeguard 1.1, the enterprise asset inventory, and Safeguard 4.1, the secure configuration process, as prerequisites for measuring Safeguard 4.10. Without a current inventory, the assessor cannot establish the population of portable devices, and without a documented configuration process, the lockout threshold has no approved baseline to test against. Confirm both documents exist and cover portable devices before testing begins.

Endpoint management and identity teams

Endpoint management teams apply the lockout policy and produce the device-level evidence, while identity teams confirm that local authentication methods and failed-attempt rules align with directory policy. Assign a named owner for each platform, since a policy configured in one console but not reconciled with the other is a common source of mismatched results. Confirm who can change the setting and how changes are recorded.

Security function and audit owner

The security function defines the threshold, reviews exceptions and tests the measure, while the audit owner, whoever answers for the control in internal or external reviews, accepts the evidence and the exception register. Separating these roles lets the audit owner challenge the measurement independently. Ask for a written RACI that names each role for Safeguard 4.10 before the first assessment.

How an assessor tests Safeguard 4.10

This table compares what an assessor checks for each part of Safeguard 4.10, the evidence usually requested and the findings that tend to appear. Read it alongside the CIS Controls Assessment Specification, which gives the five measures in exact wording; the rows below explain the intent in plain terms.

Assessment focus	What the assessor checks	Evidence requested	Common findings
Lockout threshold per device type	Whether the configured failed-attempt limit is no more than 20 for laptops and no more than 10 for tablets and smartphones	Policy export or configuration profile showing the threshold value for each device platform	Threshold set once for laptops but left at a vendor default or a higher value for phones
Enforcement by policy	Whether the lockout is enforced centrally rather than left to user choice or local settings	Management console policy assignment, with scope and effective date	Policy drafted but never assigned to all device groups, or overridden locally
Sample of devices from the inventory	Whether a selection of devices from the asset inventory actually receives the policy	Device list drawn from the inventory and matched against policy compliance status	Devices missing from the management platform, so they cannot receive the setting
Enrollment or policy record	Whether devices enrolled after the policy was set also receive it, and whether the record shows when it was applied	Enrollment records, policy assignment history, and compliance reports over time	Newly enrolled devices pending policy sync for long periods without follow-up
Platform support exclusions	Whether any device without a lockout setting is excluded only because the platform cannot support one	Written justification per platform, referencing the vendor documentation for that platform	Exclusions granted for convenience rather than because the platform truly lacks the option
Link to prerequisite data	Whether the device population used for testing matches the enterprise asset inventory and secure configuration process	Asset inventory extract and the documented secure configuration process referenced by Safeguards 1.1 and 4.1	Inventory and management platform counts that do not reconcile

How to implement automatic lockout on portable devices

This sequence turns Safeguard 4.10 from a written requirement into a configured, tested and monitored lockout setting across laptops, tablets and smartphones. Each step produces a record an assessor can read, from the standard through to the exceptions.

Confirm the portable device inventory
Start from the enterprise asset inventory that Safeguard 1.1 calls for and filter it to portable end-user devices: laptops, tablets and smartphones. Split the list by operating system and by management status, because the lockout setting you can apply depends on the platform and on whether the device is enrolled in a management tool. Your output is a filtered inventory with a count per platform and a flag for each device that is not enrolled. Confirm with your asset owner that the list is current before you move on.
Document the lockout standard in the secure configuration process
Write the lockout requirement into the secure configuration process that Safeguard 4.1 requires. State the maximum number of failed local sign-in attempts for each device class: no more than 20 for laptops and no more than 10 for tablets and smartphones. Name the owner of the standard, the review cycle and the approval record. The output is an approved standard section that the rest of the steps cite, so an assessor can trace each setting back to a documented decision.
Set the threshold per platform in the management tool
Translate the standard into configuration for each platform. For Windows and other Intune-managed devices, use the Microsoft Intune Device Lock settings. For Apple devices, set the maxFailedAttempts key in a configuration profile. Confirm the exact setting names and supported values in the vendor documentation for your versions, since they change between releases. Apply the threshold to each device class separately so the laptop and mobile limits match the standard. The output is an exported policy or profile for each platform that shows the threshold value.
Test the lockout on a pilot group
Choose a small pilot group that covers each platform and model in use. On each test device, deliberately enter wrong credentials until the threshold is reached, and record whether the device locks at the configured count and how recovery works for the user. Also confirm that the lockout does not trigger on correct credentials and that the help desk can unlock the device through the approved path. Record the device model, OS version, attempts made, observed behavior and tester name. The output is a signed pilot test record that shows the control works in practice.
Roll out and record unsupported devices
Deploy the policy to the remaining enrolled devices in controlled waves, and confirm each wave has picked up the setting. Some portable devices may not support a failed-attempt lockout or may not accept the management policy at all. For each of those, do not leave the gap undocumented. Open an exception entry that names the device, the platform limitation, the compensating measure (for example, a session lock or remote wipe under Safeguard 4.11) and an owner who reviews it. The output is a deployment log and an exception register that explain every device outside the setting.
Verify compliance on a schedule
Use your endpoint management or configuration assessment tooling to check the lockout value on every enrolled device at a regular interval set in your standard. Open source options include Wazuh Security Configuration Assessment, which uses YAML policies that check configuration settings and recommend remediation, and Fleet, whose policies ask devices yes or no questions as osquery queries and show which devices pass or fail. Confirm that the tool can read the specific setting on each platform before you rely on its results. The output is a compliance report per platform, reviewed against the exception register, with failures assigned for remediation.

Evidence that passes a Safeguard 4.10 review

An assessor testing Safeguard 4.10 needs to see the standard, the settings actually deployed, proof of which devices carry them, and tests showing the lockout fires. The cards below connect the policy to the device records and the exceptions, so each claim can be traced to a current artifact.

Documented lockout standard

A written standard that sets the lockout thresholds: no more than 20 failed local logins for laptops and no more than 10 for tablets and smartphones, applied where the platform supports it. It should name the device classes in scope, the owner of the setting, and the process for changing a threshold. Check that the document references the same values your management tool enforces, and that the version history shows when each threshold last changed. Keep it current by attaching a change ticket to every revision.

Exported policy or profile settings

Exports from the management tool showing the lockout values in force, such as an Intune Device Lock configuration or an Apple Configuration Profile carrying the maxFailedAttempts key. Confirm the exported object is the one assigned to each device group, not a draft or an unassigned copy. Store exports with the date and the assignment target. Schedule recurring exports and file each one with the change ticket that altered the setting, so the export history matches the change history.

Compliance report by device group

A report listing which portable devices in each group pass the lockout policy and which fail. It shows whether the setting is applied, not merely assigned, and it gives the assessor a coverage figure to test. Ask your management or fleet tooling whether it reports policy state per device, and whether failing devices can be exported. Retain dated copies, and record the query or filter used to produce each one so the assessor can reproduce it.

Enrollment record linked to inventory

Records that tie each portable device to its entry in the enterprise asset inventory, the prerequisite for measuring Safeguard 4.10 under the CIS Controls Assessment Specification alongside Safeguards 1.1 and 4.1. Without this link, a compliance report cannot prove that every portable device was counted. Reconcile the enrollment list against the inventory on a schedule you define, and record discrepancies as open items with owners.

Pilot and lockout test records

Test records that show a device locks after the configured number of failed local attempts, captured on a representative model of each class. Record the device model, OS version, policy version, the number of attempts made, and the observed result. Repeat the test after any policy or OS change that could affect the setting. Keep these results separate from production reports, because they demonstrate that the control works, not only that it is assigned.

Exception register for unsupported devices

A register of portable devices that cannot enforce the lockout setting, with the reason, the compensating measure, an owner and a review date. The Safeguard applies only where supported, so an assessor expects to see exceptions handled openly rather than silently excluded from the metrics. Confirm each entry against the device's actual capability, and retire entries when the device is replaced or upgraded. Attach the approval record for each exception.

What meeting Safeguard 4.10 costs in money and effort

This table lists the cost components of meeting Safeguard 4.10, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a quote request, since no price or duration for this Safeguard has been published in the sources used here.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Endpoint management licenses	Software vendor, if the organization does not already own a suitable suite	Recurring, usually per device or per user	Up: new device types or separate tools per platform. Down: reuse of an existing suite that already enforces lockout settings
Engineering time to set thresholds	Internal platform team or an implementation partner under a written scope	One-time, then reviewed on change	Up: several operating systems, unmanaged devices, and no standard profile. Down: one tested baseline per device class
Testing the lockout behavior	Internal QA or the implementation partner	One-time per platform, repeated after major OS updates	Up: many OS versions and vendor-specific behavior. Down: a short test script that runs on every new build
Open-source checking layer	No license fee for Wazuh (GPL-2.0-only) or Fleet (MIT); hosting and staff time are still paid	Recurring for hosting and operation	Up: large fleets needing more infrastructure. Down: reuse of existing servers and a single check per policy
Evidence upkeep	Internal compliance or security staff	Recurring, at each review cycle	Up: manual screenshots and unmanaged devices. Down: exported reports from the checking tool stored in one location
Exception handling	Internal security owner who approves and tracks exceptions	Recurring, as exceptions arise	Up: legacy devices that cannot enforce the threshold. Down: a written exception process with a stated expiry
External review of configuration	Independent consultant or assessor, under a written scope	Usually one-time, repeated when scope changes	Up: multiple tenants, mixed device fleets, or audit deadlines. Down: an internal review against the Safeguard before the external one
Auditor sampling effort	Independent auditor, who is paid by the organization	Recurring, at each assessment cycle	Up: large device populations and weak records. Down: a complete asset inventory under Safeguard 1.1 and a documented process under Safeguard 4.1

Using Wazuh and Fleet to prove lockout settings on endpoints

Safeguard 4.10 is only as credible as the evidence that devices actually lock. Two open-source tools can help produce that evidence on monitored endpoints, but each one reads different things on different platforms. The cards below describe what each tool checks, how a yes or no policy can target a lockout setting, and what to confirm before relying on the results.

Wazuh security configuration assessment

Wazuh's Security Configuration Assessment (SCA) module scans monitored endpoints against YAML policies. Most shipped policies are based on CIS benchmarks, and custom policies can be added. For Safeguard 4.10, the useful question is whether a shipped or custom policy checks the local lockout threshold on each device type. Confirm that the policy rule exists for your operating system and that it reads the setting your configuration actually uses, because SCA checks files, registry keys and running processes rather than the management profile that delivered the setting.

Fleet policies as yes or no checks

Fleet policies are yes or no questions asked of devices as osquery queries. Each policy returns a pass or fail result per device, and the policies page shows which devices on each fleet are passing or failing. This gives a compact view of which portable devices meet the lockout expectation at a point in time, and it gives an auditor a list of exceptions to follow up. Treat the result as a point-in-time observation that needs a dated record, not a continuous enforcement guarantee.

Writing a lockout policy question

A Fleet-style policy for Safeguard 4.10 would ask whether a device's failed-login lockout setting is in place at or below the CIS limit for its class, 20 attempts for laptops and 10 for tablets and smartphones. This is illustrative only: the exact query depends on the operating system and on where the setting is stored. Before using any such policy as evidence, test it on a device you have deliberately configured both correctly and incorrectly, and confirm it returns the expected pass and fail results.

Confirming tool coverage per platform

Neither tool may see every lockout setting on every platform. Coverage differs by operating system, by device type and by how the setting was applied, whether through an MDM profile, a local policy or a configuration script. Before you rely on either tool, confirm in writing with the vendor and in your own test environment which lockout settings each tool can read on each laptop, tablet and phone platform you run. Where a tool cannot see a setting, record the alternative evidence source, such as the MDM compliance report.

In-house or partner: who configures lockout and who tests it

Your organization owns Safeguard 4.10. That means deciding what the lockout standard says for each device class, approving the device policy that enforces it, and recording any exception where a device cannot meet the thresholds. The CIS threshold for laptops is no more than 20 failed local attempts, and for tablets and smartphones no more than 10, applied where the platform supports it. Your team is also accountable for the risk decision when a device falls short, because no implementation partner or auditor can accept that risk on your behalf.

Standard ownership: Set the lockout thresholds, state which device classes are in scope, and approve the written standard.
Device policy approval: Sign off on the Intune Device Lock or Apple configuration profile settings before they reach users.
Exception decisions: Decide which unsupported or legacy devices are accepted, compensated or retired, and who signs each decision.
Evidence custody: Keep the inventory, policy exports and exception register that auditors will ask for.

Before engaging anyone, confirm that your standard, owners and exception process are written down, because each of them is requested during testing.

Where lockout evidence usually falls short

Lockout settings are easy to configure and hard to prove. The gaps below usually appear after a rollout looks finished: some platforms are missed, personal devices drift outside policy, and the reports never connect back to the asset inventory or to documented exceptions. Each card names one gap and how to close it before an assessor finds it.

Thresholds set on some platforms only

Teams often enforce a lockout threshold on Windows laptops through domain policy and forget iOS, Android or Chromebook fleets, or they configure one mobile platform and assume the rest match. Safeguard 4.10 sets different limits for laptops (no more than 20 failed attempts) and tablets and smartphones (no more than 10), so a single global value can satisfy one class and breach the other. Build a matrix of device class, operating system and management tool, then record the setting observed on each row. Confirm the exact configuration key for each platform with its vendor documentation.

Unmanaged personal phones left out

Bring-your-own-device programs frequently hold corporate email or VPN access on phones that no management tool can configure. Those phones often sit outside the lockout report, and nobody records why. Either bring them under a management profile that enforces the limit, or document a named exception with compensating controls, such as blocking access to enterprise resources until the device meets requirements. Check whether the device population in your management console matches the access logs for mail and VPN.

Inventory and lockout report not linked

A compliant report that lists only managed devices proves little if the asset inventory contains devices that never appear in it. Safeguard 4.10 relies on Safeguard 1.1, the enterprise asset inventory, as a prerequisite, so each portable device should carry an inventory identifier that the lockout data references. Reconcile the two sources on a fixed schedule and investigate every device present in one list but missing from the other. Ask your tooling vendor which identifier its reports expose.

Settings documented but never verified

Policy documents describing a lockout threshold do not show that any device enforces it. A device can drift after an operating system upgrade, a profile can fail to apply, or a user can remove a profile. Schedule recurring checks that query each device for its effective lockout value and record pass or fail results with timestamps. Fleet policies, written as yes or no osquery questions, can report which devices pass or fail each check, which gives you a dated result rather than a statement of intent.

Exceptions without reason or owner

Exceptions tend to accumulate as informal favors: a legacy tablet kept at a higher threshold for a clinician, or a shared device left at default settings. An exception with no written reason, no named owner and no expiry date will not survive an assessment. For each exception, record the device, the setting that differs, the business justification, the accountable manager, the compensating control and a review date. Remove exceptions that no longer have a justification.

Lockout standards that differ from CIS limits

Internal standards often adopt a single number such as five or ten attempts for every device, or copy a vendor default without comparing it to the CIS limits. Map each internal standard to Safeguard 4.10 and note where it is stricter, looser or silent about portable devices. A stricter internal value can still be valid, but a looser one fails the CIS measure for at least one device class. Confirm the mapping against the CIS Controls Navigator, which links Safeguard 4.10 to NIST SP 800-53 AC-7 and ISO/IEC 27001 Annex A 8.5 for cross-reference.

How Safeguard 4.10 maps to NIST, ISO 27001 and PCI DSS

The CIS Controls Navigator for v8.1 links Safeguard 4.10 to three other frameworks: NIST SP 800-53 Rev. 5 controls AC-7 and AC-19, ISO/IEC 27001:2022 Annex A 8.5 and PCI DSS v4.0 requirement 8.3.4. Each link marks an area where a CIS Safeguard and a requirement in another framework cover similar ground. AC-7 concerns limiting unsuccessful logon attempts, AC-19 concerns access control for mobile devices, Annex A 8.5 concerns secure authentication, and requirement 8.3.4 concerns limiting invalid authentication attempts. The overlap is the lockout threshold on laptops, tablets and smartphones, which is the same setting you would configure once for all of them.

A mapping shows where two frameworks overlap. It does not mean that evidence gathered for Safeguard 4.10 satisfies NIST, ISO 27001 or PCI DSS on its own. Each framework has its own requirement wording, scope and testing approach, and the assessor for that framework decides whether your implementation meets it. A PCI DSS assessor, for example, will test the cardholder data environment and the scoping decisions behind it, which a general device lockout report does not show. Ask each assessor early which evidence they will accept and whether they want the same device population, screenshots or exported configuration profiles.

Confirm every mapping in the CIS Controls Navigator for the exact framework version you are assessed against, because the Navigator covers several versions of each standard. Also remember that CIS states its Controls do not replace any regulatory, compliance or authorization scheme. Treat the mapping as a starting point for reusing evidence, and record in your control matrix which framework requirement each lockout report supports, which device types it covers and who reviewed the mapping.

Questions buyers ask about Safeguard 4.10

How much effort does lockout enforcement take for a mixed laptop and phone fleet?

Effort depends mostly on how many device platforms and management tools the fleet uses, not on the number of lockout settings themselves. The setting is simple to state: laptops should lock after no more than 20 failed local logins, and tablets and smartphones after no more than 10. The work lies in finding out which devices are managed, which platform controls each one, and whether the lockout value actually reaches every device. Typical drivers include:

How many operating systems and mobile platforms are in use
Whether a mobile device management or endpoint management tool already enforces policy
How many devices are unmanaged or personally owned
Whether exceptions must be documented and approved

Ask any provider to show how they will measure coverage per device class before agreeing to a scope.

Does an IG1-only organization have to meet Safeguard 4.10?

No. Safeguard 4.10 is assigned to Implementation Groups 2 and 3, not to IG1, so an organization that has adopted only IG1 is not expected to meet it yet. IG1 is the essential cyber hygiene baseline for every enterprise, and IG2 adds Safeguards for organizations with more operational complexity that often hold sensitive information. If your organization is moving toward IG2 or a contract requires it, treat this Safeguard as part of that step. Confirm the Implementation Group assignment in the CIS Controls Navigator for your version before you record it as in or out of scope.

Can our own team implement automatic device lockout in-house?

Often yes, if the team already manages its devices and has someone who can write and test policy. The configuration itself is usually a device management policy, such as Microsoft Intune Device Lock or the Apple Configuration Profile setting for maximum failed attempts, which CIS cites as example implementations. The harder part is proving the setting is applied everywhere and keeping evidence current. An in-house team should check whether it has:

Ownership of a current asset inventory, which the assessment specification treats as a prerequisite
A written secure configuration process to tie the setting to
Reporting that shows pass or fail per device, not just a policy that was created

Where one or more of these is missing, a fixed-scope engagement can prepare them.

What does the work need from IT and security teams?

The work needs decisions and access from both teams. IT owns device management, so it must confirm which platforms enforce the setting and be able to change policy. Security owns the requirement, the exception process and the evidence that auditors will review. Both teams should agree on a few things early:

Which device classes count as portable end-user devices in scope
Who approves exceptions for devices that cannot enforce a lockout threshold
Where configuration and compliance reports will be stored and who reviews them
How often the setting is re-checked after OS updates or policy changes

The Safeguard's measurement depends on Safeguards 1.1 and 4.1, so the asset inventory and secure configuration process should be in view from the start.

How long does it take to enforce device lockout?

The duration depends on fleet size, the number of device platforms, how many devices are already under management and how much existing evidence can be reused. No timeline is given here because none has been established for this Safeguard. The biggest variables are the state of the asset inventory, whether an endpoint management tool is in place and how many exceptions need review. Ask for a timeline in the written scope that separates policy design, rollout, verification and evidence collection, and that states which of these depends on your own teams or on device owners.

Can a partner issue the assessment of Safeguard 4.10?

No. An implementation partner can configure devices, prepare the measurement data and assemble evidence, but it cannot issue an assessment, certification or attestation. The CIS Controls Assessment Specification defines how the Safeguard is measured, and the organization owns the result. Any formal assessment of CIS Controls implementation must come from an assessor you engage independently, and you should confirm with that assessor which evidence format and scope it expects before work starts.

What should a written quote for this work include?

A written quote should follow from a written scope, and it should name each deliverable so you can compare providers on the same basis. Ask for the following:

The device classes and platforms in scope, with laptops and phones or tablets listed separately
The lockout values to be set and how they map to the CIS thresholds
The management tools that will enforce the setting and any tools that will report on it
How coverage will be measured against the five measures in the assessment specification
The evidence package and who receives it
What is one-time work and what recurs, such as monitoring or re-checks after updates
Assumptions about the asset inventory and secure configuration process

DeployOpen agrees scope, deliverables and timelines in writing before work starts.

How DeployOpen scopes and prepares Safeguard 4.10 evidence

DeployOpen works on Safeguard 4.10 as a fixed-scope engagement inside your own infrastructure. We prepare the portable device lockout configuration, the supporting inventory and secure configuration process, and the evidence an independent assessor would review, while your organization keeps ownership of the control and the auditor issues any report.

How we scope

Agree in writing which portable device types, operating systems and management tools fall within the Safeguard 4.10 scope.
Confirm the 20 attempt laptop and 10 attempt tablet and smartphone thresholds against your own device estate and written policy.
Identify prerequisite data from Safeguards 1.1 and 4.1 that the measurement will depend on before work starts.

How we build

Configure failed-login lockout settings through your existing device management platform, such as Microsoft Intune or Apple configuration profiles, where your environment supports them.
Set up open-source policy checks, such as Wazuh configuration assessment or Fleet osquery policies, to report which devices pass or fail the lockout threshold.
Test lockout behavior on representative devices of each class before rollout, and record the results for the assessor.

How we hand over

Deliver a written configuration record, the policy definitions used, and the pass or fail reports mapped to the five Safeguard 4.10 measures.
Document exceptions, compensating decisions and remediation steps, with owners named by your organization.
Provide runbooks so your own team can rerun the checks and show current compliance to an independent assessor.

How we support

Ongoing support, periodic re-checks and upgrades are available as a retainer after the initial handover.
Review new device models and operating system releases against the lockout thresholds as your fleet changes.
Confirm with your auditor or assessor which evidence format and retention period they expect before the final package is built.