What CIS Safeguard 4.11 remote wipe requires in practice
Safeguard 4.11 asks the enterprise to be able to erase its data remotely from the portable end-user devices it owns when that is warranted, such as after a laptop or phone is lost or stolen, or when a user stops supporting the enterprise. The practical test is simple to state: for a given lost or departing user, can the organization wipe the enterprise data on the device it owns without relying on the user's cooperation? Under CIS Controls v8.1 the Safeguard sits in the Data asset class and the Protect security function, and it is assigned to Implementation Groups 2 and 3 but not IG1. That placement signals that remote wipe is expected once an enterprise holds sensitive information and has more operational complexity, not as a baseline for every organization. Confirm the assignment against the current Safeguard entry on the CIS Critical Security Controls v8.1 page before you cite it in a plan.
The difficulty lies less in the wipe command than in the preconditions. The organization must know which portable devices it owns, which requires an accurate asset inventory, and it must know which devices are enrolled in a management system that can act on them. Personal devices that receive corporate mail create the hardest case, because the organization may own the data but not the device, so a wipe policy has to be limited to a container or work profile. Sync gaps add a second problem: a device that has been offline, lost its enrollment, or never checked in will not respond to a wipe, and the organization may not learn of that until someone needs it. A departing employee's device may also hold data that has already synced to other locations that need their own deletion steps.
For a first review, ask three questions of every portable device class: is it enrolled, does the management platform show its last check-in, and does a tested procedure exist from the request to the confirmed wipe. Document who may authorize a wipe, how the decision is recorded, and how the user is told. Your assessor will expect evidence that the capability has been exercised, not only configured, so plan a test on a spare device. Dependencies on Safeguards 1.1 and 4.1 are covered in the sibling sections, but the working gap is usually the enrollment record and the check-in data, which decide whether a wipe can happen at all.
Which devices, data and teams fall under the remote wipe scope
Remote wipe under Safeguard 4.11 is only as good as the scope behind it. The decisions below determine which devices must be wipeable, which data counts as enterprise data and which teams must act when a device is lost or a person leaves. Safeguard 1.1 (the asset inventory) and Safeguard 4.1 (the secure configuration process) supply the device list and the baseline that any measurement depends on.
Company-owned versus personal devices
Safeguard 4.11 concerns enterprise-owned portable devices. Personal devices enrolled under a bring-your-own-device program are a different question, because wiping them can remove the employee's own data. Decide early whether BYOD devices are in scope, whether they can be limited to a managed enterprise container, and what wipe action applies to each category. Record the ownership of every device in the asset inventory so the measurement can separate the two groups.
Laptops versus phones and tablets
Laptops, phones and tablets differ in how they are managed, how they connect and how a wipe is executed. Mobile devices often sit under a mobile device management agent that can send a wipe command, while laptops may depend on an endpoint agent that is only reachable when the device is online and signed in. Confirm which device types can receive a wipe command, how each behaves when offline, and whether the same measure can cover all of them.
Enterprise data stores in scope
A wipe only helps if enterprise data is actually held on the device in a place the wipe reaches. Map the local sync folders, cached mail, collaboration clients, downloaded files and managed application containers that hold enterprise data. Data kept only in a browser session or only in a cloud service may never reach the device, so the data inventory from Control 3 should show where copies really sit.
Contractor and third-party held devices
Contractors, temporary staff and service providers sometimes use enterprise-owned devices or hold enterprise data on their own equipment. Decide whether these devices fall under the same remote wipe measure, and whether the contract gives the enterprise the right to wipe them. Confirm how a device leaves a contractor's control, because a device that is never returned cannot be verified as wiped.
HR offboarding and identity teams
When an employee leaves, HR notifies the identity team and IT decides which devices to wipe and when. The timing matters: a wipe should follow the revocation of access so that the device cannot be used to reach enterprise services in the gap. Agree which system triggers the wipe, who approves it and how the result is recorded, and document the handoff so an assessor can trace a departure to a wipe event.
IT and security operations ownership
Remote wipe involves the team that runs the device management platform, the team that handles lost or stolen device reports and the security team that reviews the results. Assign one owner for the measure, define who can trigger a wipe in an emergency, and confirm that the help desk has a written procedure. Unclear ownership is a common reason wipe evidence is missing when an assessor asks for it.
How an assessor tests remote wipe against the CAS measures
The assessor starts with the written procedure. The CIS Controls Assessment Specification for Safeguard 4.11 defines what to measure but not how to measure it, so there is no CIS-issued wipe procedure to hold your document against. The assessor will instead ask for your own procedure and check that it is specific, approved and actually used. They look for the triggers that start a wipe, the roles allowed to authorize one and the link to the secure configuration process and asset inventory that the specification lists as prerequisites.
- Written wipe procedure: triggers such as loss, theft and departure, the approver for each, and the time window for acting on a report.
- Device scope: which portable end-user devices are covered and how enterprise-owned devices are separated from personal ones.
- Link to Safeguard 4.1: the secure configuration process should state how remote wipe is enabled on managed devices.
- Offboarding workflow: the HR or identity step that raises a wipe request when a user leaves.
- Review record: a version history showing the procedure was reviewed and that the named roles still exist.
Confirm that every trigger in the procedure has a matching step in your ticketing or identity system before the assessor asks for it.
Next, the assessor compares the population of portable devices with the devices that appear in your management platform. Safeguard 1.1, the enterprise asset inventory, is a prerequisite for this measurement, so the assessor expects a complete list of portable end-user devices the enterprise owns. They then select a sample from that list and check each sampled device for evidence that remote wipe is available and that the device is reporting to the management console. The sample is the assessor's choice, so every device in the population should be in a condition that would pass.
- Inventory population: the list of owned laptops, tablets and phones, pulled from the asset inventory at a stated date.
- Sample selection: the assessor picks devices across device types and user groups rather than accepting a hand-picked subset.
- Capability check: console or agent evidence that remote wipe is enabled and that the device has checked in recently.
- Missing devices: owned devices absent from the inventory or from the management console, which the assessor treats as gaps.
- Disabled capability: devices where wipe has been turned off, including devices excluded through exception lists without approval.
Reconcile the asset inventory with the management console before the assessment so the two populations match.
A capability that exists on paper is weaker evidence than a record showing the enterprise has exercised it. The assessor looks for logs that show wipe commands were issued, that the device acknowledged them and that the outcome was verified. Test wipes on test devices are the cleanest evidence because they can be scheduled and controlled. Operational wipes after a real loss or departure also count if the record links the wipe to its trigger and approval. The records should show that the process works from request to completion.
- Test wipe log: the date, device identifier, operator, command issued and result for each test.
- Completion confirmation: a status from the device or console showing the wipe finished, with its timestamp.
- Operational examples: wipes tied to a real departure or loss, with the trigger ticket and approval attached.
- Representative coverage: tests spread across the device models and operating systems in the fleet, not a single model.
- Retention: logs kept for the period your own retention rule sets, and exportable in a form the assessor can read.
Run at least one documented test wipe on each major device type before the assessor requests the records.
Most findings against this Safeguard are evidence gaps rather than missing tools. Because the specification combines its three measures into one compliance metric, a gap in any single measure can affect the overall result. The findings below come up often enough that they are worth checking against your own environment before the assessment begins. Each one can be closed with documentation, a test or a reconciliation, which keeps remediation time short if the gap is found early.
- Wipe never tested: wipe is enabled, but no test or operational wipe appears in any record.
- Devices outside the inventory: portable devices that reach corporate resources but do not appear in the asset list.
- Stale procedure: the document names roles or systems that have changed, or describes steps nobody follows.
- Offboarding disconnect: HR records a departure, but no wipe request or ticket exists for the user's devices.
- Unexplained exceptions: devices excluded from wipe without a recorded approval or review date.
Run a self-check against each of the three measures before the assessor arrives and keep the result with your assessment file.
How to implement remote wipe, step by step, with the output of each
This sequence moves from knowing which portable devices exist to proving, on a dated record, that the enterprise can wipe them when it needs to. Each step produces a document or record that an assessor can trace back to Safeguard 4.11.
Confirm the asset inventory for portable devices
Start from the enterprise asset inventory that Safeguard 1.1 requires, and filter it to enterprise-owned laptops, tablets and smartphones that users carry outside the office. The CIS assessment specification treats this inventory as a prerequisite because the wipe measure needs a defined population to check against. Personal devices that are not enterprise-owned fall outside this Safeguard, so record them separately. The step is done when the portable device list has an owner, a device type and an operating system for every line, and the inventory owner has signed it off.
Select the management channel for each device type
Choose how wipe commands reach each device class. Mobile device management usually covers smartphones and tablets, while endpoint management or an agent-based tool usually covers laptops. Confirm with the vendor or platform documentation which wipe actions each channel supports on each operating system, because capability differs between platforms and versions. Open-source options exist for the agent side, and the platform you choose should be validated against your device mix before you commit. The output is a short channel decision record listing each device class, its management tool and the wipe action it supports.
Define wipe triggers for loss, theft and offboarding
Write the procedure that says when a wipe is authorized and who may request it. Cover three triggers: a reported loss, a reported theft, and a user leaving the enterprise or no longer supporting it. For each trigger, name the requester, the approver, the time expectation your policy sets, and the record kept afterward. Link the offboarding trigger to the HR and access removal workflow so that a leaver's devices are not overlooked. The step closes when the trigger procedure is approved by the security owner and the HR or service desk leads who will run it, and the signed version is stored with the policy set.
Configure the wipe action and scope it to enterprise data
Configure the management channel so that authorized operators can issue a remote wipe to a single device, and confirm the scope of the action. Some platforms offer a full device erase, while others offer a selective removal of managed apps and enterprise profiles that leaves personal data in place. Choose the scope that matches your trigger procedure and your Safeguard 4.12 workspace design, and document the reason. Restrict who holds the wipe permission and log each command. The output is a configuration export or screenshot set, plus a permission list showing which roles can issue wipes.
Enroll devices and confirm each one reports to the console
Enroll each device in the portable device list into the chosen management channel, then check that it reports its status to the console. A device that is not enrolled or that has stopped checking in cannot be wiped remotely, so this step converts the inventory into a wipe-capable population. Compare the console list against the inventory and investigate every gap, whether it is a missing device, a stale check-in or an unsupported operating system. The output is an enrolled device list with check-in dates, plus a gap register that records each exception and its resolution.
Test the wipe on a pilot device and record the result
Select a pilot device that holds no production data, issue a wipe through the normal procedure, and confirm the result on the device and in the console. Record the date, the operator, the device identifier, the command issued, the time the device acknowledged it, and whether the data was removed as the scope intended. Repeat the test for each device class in your population. If a test fails or only partly succeeds, correct the configuration and retest before you rely on it. The output is a dated wipe test record for each device class, which becomes the core evidence for this Safeguard.
Set a recurring verification and report on compliance
Schedule a recurring check that confirms enrolled devices still report, that the wipe permissions still match the approved roles, and that leavers' devices were handled under the offboarding trigger. Run the check at an interval your governance process sets, and track the share of in-scope devices that are wipe-capable. This matches the single compliance metric the assessment specification combines from its measures. The output is a verification report for each cycle, with exceptions assigned to owners. Confirm with your assessor which cycle and evidence they expect before you rely on it.
Evidence that proves a device can be wiped remotely
An assessor will not accept a claim that devices can be wiped. They will look for a current list of enrolled devices, a documented offboarding path that triggers the wipe, configuration exports showing the wipe capability is switched on, dated test records and tickets from real events. The cards below cover each artifact and the routine that keeps them current between assessments.
Device inventory tied to enrollment
Export the list of portable end-user devices enrolled for management, with device identifiers, owner, assigned user, enrollment date and last check-in. This is the population the wipe capability must cover. Safeguard 4.11 depends on the asset inventory under Safeguard 1.1, so check that every enrolled laptop, tablet and phone also appears in the inventory and that devices that have not checked in recently are flagged. An unenrolled device cannot be wiped, so unmanaged devices with enterprise data are a gap to record.
Wipe procedure and offboarding linkage
Keep a written procedure that says who can trigger a remote wipe, what counts as a trigger (loss, theft or departure), how quickly the request must be actioned and how the event is recorded. Link it to the joiner, mover and leaver process so that account disablement and device wipe happen in the same workflow. An assessor will compare the procedure with the offboarding checklist and look for a step that covers devices, not only accounts.
MDM or endpoint configuration exports
Export the policy settings from the mobile device management or endpoint management platform that show remote wipe is enabled for each device group, including the command permissions granted to administrators. Also export the Safeguard 4.1 secure configuration baseline that these settings come from. Confirm with the platform vendor which command names and settings represent remote wipe in your version, and retain dated exports so the configuration can be shown as it stood on a given date.
Dated wipe test results
Run controlled wipe tests on a sample of enrolled devices, including at least one device from each platform in use, and record the device identifier, date, command issued, time to confirmation and the result. Keep a test device in a dedicated test group so production data is not at risk. A test log that names devices and dates is far stronger evidence than a statement that the feature exists. Confirm whether the platform reports a completed wipe or only a sent command.
Tickets showing executed wipes
Retain tickets for real loss, theft or departure events that show the wipe request, the approver, the time the command was sent, the device identifier and the confirmation returned by the platform. Where a device could not be wiped, keep the record with the reason and the follow-up action, such as disabling access or reporting the loss. Assessors use these records to confirm the process works under real conditions, so incomplete or missing tickets weaken the rest of the evidence.
Recurring reports between audits
Schedule a compliance report from the management platform that lists devices failing the wipe-capability check, devices without a recent check-in and devices past their last test date. Set a recurring test calendar, for example quarterly test records, and assign an owner for each report. Open-source tools such as Fleet can run yes or no policies against devices and show which devices pass or fail, which can support this report alongside MDM data. Confirm that the chosen tool can reach the devices you need before relying on it.
What meeting Safeguard 4.11 costs in money and effort
This table breaks down the cost components of meeting Safeguard 4.11, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a quote request and to separate spending you can reduce from spending that is fixed by your device estate. No prices or durations are stated because none were supplied; the rows show what to ask for.
| Cost component | Who is paid or who carries it | One-time or recurring | Main cost drivers and how to reduce them |
|---|---|---|---|
| Management platform licenses | Software vendor or subscription provider for remote wipe on managed devices | Recurring, usually per device or per user; confirm the pricing unit in writing | Device count and number of platforms. Consolidating onto one mobile or endpoint management tool, or using a self-hosted open-source option such as Fleet for query-based checks, can reduce license spend. Confirm which wipe actions each option supports. |
| Engineering time to enroll and configure | Internal platform team or an implementation partner under a fixed-scope agreement | One-time for initial enrollment, then recurring for new devices and policy changes | Number of device types, operating systems and legacy devices. Standardize enrollment profiles and build them once per platform. |
| Wipe test effort | Internal IT or security staff, with an implementation partner if scoped | Recurring, at the frequency your evidence plan sets | Number of device groups tested and whether tests include lost-device and departing-user scenarios. Test a representative sample of each device group and record results each time. |
| Evidence upkeep | Internal compliance or security staff who keep records current | Recurring | Frequency of device changes, staff turnover and how automated your evidence is. Export device compliance and wipe logs on a schedule so records do not need manual rebuilding. |
| Auditor sampling and review | Independent auditor or assessor, under its own engagement terms | Recurring at each assessment cycle | Number of devices and wipe events in the sample and the completeness of your records. Clean, queryable records typically narrow the sample work; ask the auditor to confirm its method first. |
| Legacy and unsupported devices | Internal IT for replacement, or a budget line for hardware refresh | One-time per device, plus any ongoing exception handling | Devices that cannot enroll or support remote wipe. Each one either needs replacement, an approved exception with compensating controls, or retirement from enterprise use. |
| Self-hosted hosting and operations | Internal infrastructure team for servers in your own cloud or data center | Recurring for hosting, monitoring, patching and backups | Infrastructure size, high availability needs and staff time for upgrades. This replaces some license spend with operating effort, so compare both in the quote. |
Who owns remote wipe: your team, a partner and the auditor
Your organization owns Safeguard 4.11. The control is a statement about your enterprise: you decide which portable end-user devices are enterprise-owned, which data is in scope for erasure, when a wipe is warranted and who authorizes it. The CIS Controls Assessment Specification measures whether the capability exists and works, but it does not transfer accountability for the decisions behind it. Those decisions belong in written procedures that your staff can execute and explain.
- Scope and device ownership: Maintain the list of enterprise-owned portable devices, drawing on the asset inventory that Safeguards 1.1 and 4.1 produce.
- Wipe criteria and authority: Define when a remote wipe is warranted, such as loss, theft or a user leaving the enterprise, and name who can approve it.
- Offboarding procedure: Tie remote wipe into the joiner, mover and leaver process so that departures trigger a wipe request with a timestamp and owner.
- Exception handling: Record and approve any device that cannot be wiped remotely, along with the compensating measure and review date.
- Ownership of results: Review failing devices, decide on remediation and report the outcome to the people accountable for the risk.
Check that each of these items is written, assigned to a named role and reviewed on a schedule your staff actually follows.
An implementation partner such as DeployOpen can prepare the technical side of remote wipe in your environment. That work is configuration, testing and evidence packaging, performed inside your infrastructure under a written scope. The partner does not become the owner of the control, does not decide which devices or users are covered, and does not issue any assessment result. Your staff remain the operators of record for the systems the partner configures.
- Platform rollout: Deploy or configure the device management or fleet tooling your organization selects, in your own cloud accounts or data centers.
- Test scripting: Write repeatable checks that show which devices are enrolled, reachable and compliant, for example osquery-based policies in a tool such as Fleet, which states which devices pass or fail each policy.
- Test records: Run wipe exercises in a controlled test group and capture timestamps, outcomes and any failures.
- Evidence packaging: Organize configuration exports, policy results, procedure documents and test logs into a folder your assessor can navigate.
- Knowledge transfer: Document the setup so that your team can run the checks after the engagement ends.
Ask any partner to put these deliverables and their acceptance criteria in a written, fixed scope before work begins, and confirm that the partner will not sign off on the control on your behalf.
An independent auditor, assessor or certification body is the only party that tests the control for an assurance purpose and issues a report or certificate. Its independence is the reason its conclusion has value. If the party that built the evidence also tests it, or writes the conclusion, the assessor cannot give an independent opinion. For that reason, implementation work and assessment work should be kept in separate engagements with separate people.
- Independent testing: The assessor selects its own samples, observes or re-performs tests and decides whether the evidence supports the control.
- Reporting: Only the assessor issues the findings, report or attestation, and it states the period and scope it covered.
- Consultant limits: An implementation partner may explain the requirement, help prepare evidence and answer questions, but it should not draft the assessor's conclusions or select which evidence the assessor sees.
- Accreditation questions: Where a CIS Controls assessment is involved, confirm whether the assessing firm holds the accreditation that CIS describes for its services, since accreditation is a separate question from implementation skill.
- Engagement terms: Agree on the assessor's access to systems, logs and staff before the test starts.
Before you engage an assessor, confirm in writing which parties will sign the report and whether any work your partner performed will be relied on or re-tested.
Where organizations fall short on remote wipe and how to close it
Most organizations own a remote wipe tool but cannot show that it works for every device, every leaver and every loss. The gaps below sit between the tool, the inventory, the offboarding process and the evidence, so closing them is mostly a matter of connecting those pieces and proving it with records.
Wipe capability never tested
A wipe command that has never been run against a test device is an untested assumption. Safeguard 4.11 asks whether the enterprise can erase its data from portable end-user devices it owns, so the question to answer is whether a wipe actually completes on each device model and operating system in use. Close the gap by running a wipe on a designated test device for each platform, recording the time to completion and confirming the data is gone. Repeat the test after major operating system or management tool upgrades.
Offboarding not linked to wipe
When a user leaves, the device often goes back to a shelf or a drawer while the account is disabled and the wipe is forgotten. The Safeguard is measured on whether leavers' devices can be erased when the user stops supporting the enterprise, so the wipe should be a step in the leaver workflow rather than a separate request. Close the gap by adding a device wipe or retrieval task to the same ticket that disables accounts, with a named owner and a completion record.
Personal devices without a scope decision
Staff often read enterprise mail on personal phones, and no one has decided whether those devices fall under the wipe requirement. The Safeguard speaks to enterprise-owned devices, so a personal device with corporate mail sits in an unclear position that an assessor will ask about. Close the gap by writing a decision that states which devices are in scope, whether personal devices are enrolled or limited to a managed mail container, and what selective wipe removes. Confirm the choice with counsel and with the HR policy.
Inventory missing devices
A wipe policy can only reach devices the enterprise knows about. Safeguard 1.1, the enterprise asset inventory, is the prerequisite that produces the list of portable devices the wipe must cover, and laptops or phones bought outside procurement often do not appear in it. Close the gap by reconciling the device management console against procurement records and directory accounts, then flagging any device that reports mail or network access without an enrollment record.
Evidence exported once and never refreshed
A one-time export of wipe-capable devices may describe the environment as it stood months ago. Assessors look for evidence that reflects the current state, and the measure depends on the proportion of in-scope devices that are compliant at a given point. Close the gap by scheduling a recurring query or report, keeping dated copies and recording who reviewed the exceptions. Open-source endpoint query tools can run such checks on a schedule, but confirm each query returns the wipe-related fields you need for your platforms.
No record of a real wipe
Plenty of organizations can show a policy and a successful test but no record of a wipe triggered after a real loss or departure. That gap matters because the Safeguard concerns whether the enterprise can act when a device is lost or stolen, and a record of actual use shows the process works under pressure. Close the gap by logging every wipe request with the device identifier, reason, approver, timestamp and confirmation status, and by reviewing that log at least once a quarter.
Questions buyers ask about remote wipe and effort
Does Safeguard 4.11 apply to organizations that only meet IG1?
No. CIS Controls v8.1 assigns Safeguard 4.11 to Implementation Groups 2 and 3, so an organization working only to the IG1 baseline does not need to measure it. That does not mean portable devices can be ignored. IG1 still expects you to know which devices connect to your environment and to manage them. Organizations that hold sensitive data or have a mobile workforce often adopt remote wipe early, even before their implementation group requires it. If you are moving from IG1 to IG2, confirm the full Safeguard list in the CIS Controls materials and check it against your own risk assessment before you set a schedule.
How much effort does implementing remote wipe take?
The effort depends mainly on how many portable devices are in scope, how they are enrolled, and whether a management tool already exists. Most of the work falls into a few groups: confirming which devices the enterprise owns, confirming the tool that sends the wipe command, defining the conditions that justify a wipe (loss, theft, or a user leaving), testing the wipe on representative devices, and producing evidence that the control works. Setup is largely one-time. Recurring effort includes enrolling new devices, reviewing exceptions, and keeping the tooling current. Ask any provider to split the effort into these groups so you can see which parts you carry and which parts a partner carries.
Can our internal team implement remote wipe without outside help?
Many internal teams can, provided they have an owner for device management, an owner for the wipe policy, and time to test the result. The organization owns its controls in every case. Outside help is most useful when the team lacks one of those skills, when the scope spans several device platforms, or when leaders want an independent check before an auditor arrives. An implementation partner can prepare systems, configuration and evidence, but it does not decide your wipe policy and does not issue an assessment result. Compare an internal estimate with a partner's written scope, and make sure both cover testing and evidence collection, not only deployment.
What does our team need to provide before an engagement starts?
Several inputs make the scope accurate and keep the work on schedule:
- A current asset inventory, which is the output the CIS Controls Assessment Specification ties to Safeguard 1.1 and which the measurement of 4.11 depends on.
- A written secure configuration process, the output of Safeguard 4.1, that the wipe policy can reference.
- A list of enterprise-owned portable devices by platform, with the owner for each device class.
- A decision on the trigger conditions for a wipe, such as loss, theft, or departure, and who approves each request.
- Access to the device management or endpoint tool that will issue commands, and a named internal contact for approvals and testing.
The scope, deliverables and timelines are agreed in writing before work begins, so gaps in these inputs usually show up as scope changes.
How long does it take to put remote wipe in place?
Timelines are set in the written scope, not by a standard duration. The main drivers are the number of device platforms, the number of devices, whether a management tool already exists, how ready the prerequisite inventory and configuration process are, how long your approval cycles take, and how much testing the policy requires. Most engagements are fixed-scope, so the agreed milestones and the client actions tied to each one should appear in the proposal. Ongoing support and continuous testing can follow the initial work under a retainer. Ask for a milestone plan that names which steps depend on your team, because those dependencies usually set the pace.
How does Safeguard 4.11 map to ISO 27001 A.8.1 and A.8.10?
The CIS Controls Navigator for v8.1 maps Safeguard 4.11 to ISO/IEC 27001:2022 Annex A controls 8.1 and 8.10. Control 8.1 covers user endpoint devices, and control 8.10 covers information deletion, so a remote wipe process can support both. This is CIS's mapping, not a statement from ISO, and an auditor decides whether your evidence meets each ISO control in your own context. Document how the wipe process supports each ISO control so one set of records can serve both programs. Check the current mapping in the Navigator before you rely on it in a statement of applicability.
What evidence does an auditor expect to see for remote wipe?
An auditor looks for proof that the process is defined, that it runs, and that it works when tested. Typical evidence includes:
- A written policy that states when a wipe is warranted and who approves it.
- An asset inventory listing the enterprise-owned portable devices in scope.
- Enrollment records showing those devices are under management, with wipe capability enabled.
- Logs of wipe requests and outcomes, including the trigger, approver, timestamp and result.
- Test records from a sample of devices, and a link between offboarding and wipe requests.
Tools can help produce some of this. Fleet policies answer yes or no questions about devices through osquery and show which devices pass or fail, and Wazuh Security Configuration Assessment checks endpoint configuration against YAML policies. Confirm with each vendor whether the tool issues the wipe itself, since configuration checks alone do not wipe a device.
Does DeployOpen certify or issue a report on our remote wipe control?
No. DeployOpen plans, implements, integrates, documents and prepares the systems and evidence for a remote wipe control in your own infrastructure. Only an independent auditor, assessor or certification body issues an assessment result, report or certificate. Your organization owns the control, decides the wipe policy and approves wipe requests. Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work, which is useful if device fleets change often. Before signing, ask for the written scope, the list of deliverables, and the evidence each deliverable produces.
How DeployOpen prepares remote wipe evidence for your audit
DeployOpen's part of Safeguard 4.11 starts with a written scope agreed before any work begins. The scope names the portable end-user devices in question, the platforms that will carry the wipe function, the user populations covered and the evidence the organization expects to hand to its assessor. Because the CIS Controls Assessment Specification lists Safeguards 1.1 and 4.1 as prerequisites for measuring this Safeguard, the scope also records whether a current enterprise asset inventory and a documented secure configuration process already exist. If they do not, the reader should expect that work to come first, since the wipe measure depends on knowing which devices are enterprise-owned and which configuration baseline they should meet.
Next, DeployOpen implements and hardens the self-hosted tooling inside the client's own cloud accounts, data centers or air-gapped network. For a Safeguard like this, that typically means a device management or osquery-based inventory that can report enrollment state and run wipe-related checks, plus policies that ask whether each device is enrolled, whether a wipe command has been issued and completed, and whether the device is still reporting. Fleet policies, which are yes or no osquery questions with pass or fail results per device, are one open-source way to express these checks. The organization owns the decision on what counts as a compliant device. DeployOpen configures the tooling to match that decision and documents the settings and role assignments that control who can issue a wipe.
DeployOpen then runs wipe tests on a sample of enrolled devices, covering a lost-device scenario and a departing-user scenario, and records the request, the approval, the command, the completion and the resulting device state. Those records become the evidence pack, which DeployOpen prepares but does not certify. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform the assessment and decide whether the evidence meets the requirement. Before engaging, ask any provider, including DeployOpen, to confirm in writing which parts of the work are preparation and which, if any, the assessor will accept as their own testing.
