What Safeguard 1.2 asks for and why an unmanaged device is a risk
You already have an enterprise asset inventory under Safeguard 1.1, but an inventory only proves what you know about. Safeguard 1.2 asks for proof that devices you do not recognize are dealt with. It requires a process, run at least weekly, for handling assets that are not authorized. For each unapproved device found on the network, the process must end in one of three responses: remove the asset from the network, stop it from connecting remotely, or quarantine it. Safeguard 1.2 is the response half of asset control, so it only works when the discovery and inventory work feeding it is already producing a trustworthy list of what is unauthorized. In CIS Controls v8.1, the Safeguard sits in the Devices asset class and the Respond security function, and it applies to all three Implementation Groups, which makes it part of IG1 essential cyber hygiene.
The CIS Controls Assessment Specification lists Safeguard 1.1 as a prerequisite because the assessor needs the inventory to decide what counts as unauthorized in the first place. The usual failure points are predictable. No single person owns the decision to remove or quarantine a device, so flagged assets sit in a report. Handling takes longer than seven days, which the specification treats as a failing time frame. Scan results are never reconciled against the inventory, so unknown devices are not counted or traced to a closed ticket. Confirm in your own environment who decides, what the deadline is in your written process, and whether each weekly run produces a record that an assessor can follow from detection to outcome.
CIS publishes these mappings in the CIS Controls Navigator for v8.1: NIST CSF 2.0 PR.PS-03, NIST SP 800-53 Rev. 5 CM-8(3), SOC 2 CC7.1 and PCI DSS v4.0 requirement 11.2.1. Treat them as CIS's view, not as an equivalence you can claim in an audit. Before you rely on any of them, check the exact control text in the source standard and confirm the mapping in the CIS Controls Navigator against the version your assessor uses.
Which devices, networks and teams fall under Safeguard 1.2
Safeguard 1.2 only works on the assets and segments your scope says it covers. The decisions below determine which unauthorized devices the weekly process must catch, who may act on them and where the evidence has to come from.
Which asset types count
Start from the asset inventory required by Safeguard 1.1 and decide, in writing, which classes are enterprise assets: laptops, servers, network gear, phones, IoT sensors, and cloud workloads that store or process data. Every class left out becomes a gap an assessor can find by scanning the network. Confirm that cloud instances and containers are in scope, because they often appear and disappear faster than a weekly review cycle.
Which network segments are reachable
List every segment a device could join: corporate LAN, Wi-Fi, guest networks, data center VLANs, OT or lab networks, and remote VPN ranges. The unauthorized-asset process must be able to see and act on each one. A segment that the discovery tool cannot reach will show zero unauthorized assets, which looks like success but measures nothing. Document the segments and the tool that covers each.
Who may remove or quarantine
Removing a device from a production network can stop a clinical system, a trading desk or a plant line. Name the role that owns the decision to remove, the role that may quarantine without approval, and the role that handles disputes. Write the thresholds in the process so that the on-call engineer and the asset owner are not deciding case by case. Assessors look for a defined owner and a documented decision path.
Contractor and third-party devices
Contractor laptops, vendor diagnostic tools and auditor machines often appear on the network without an entry in the inventory. Decide whether they are authorized through a guest process, a time-limited registration or a denied list. Each route needs a named approver and an expiry date. Without one, a visiting device is either blocked by accident or left connected indefinitely, and both outcomes fail the process.
Bring-your-own devices
Personal phones and laptops that reach corporate mail or file services are unauthorized until someone registers them. Decide whether BYOD devices are enrolled in mobile device management, given limited access, or excluded from the network entirely. Your choice changes what the weekly process flags and which remediation steps apply. Confirm that the approach matches your acceptable use policy, since the policy sets what employees may expect.
How an assessor tests unauthorized asset handling
This table walks through how a CIS Controls Assessment Specification assessor tests Safeguard 1.2, from the documented weekly process to the rescan that counts unauthorized assets still reachable. Read it as a checklist of what to prepare before an assessment, and note the seven-day time frame, which the CAS treats as the failing condition.
| Test step | What the assessor asks for | Evidence requested | Common finding |
|---|---|---|---|
| Confirm the documented process | A written process for handling unauthorized assets, run at least weekly | Approved procedure, owner, and scheduled run record | Process exists only in someone's head or lacks a stated owner |
| Check the time frame | The enterprise's stated time frame for dealing with unauthorized assets | Time frame in the procedure and examples of closed cases | Time frame is longer than seven days, which the CAS scores as failing |
| Check the Safeguard 1.1 inventory | The authorized asset inventory used as the comparison baseline | Current inventory export with owner and last-seen fields | Inventory is stale, so legitimate devices are flagged or unknown devices are missed |
| Rescan the network | Independent discovery across in-scope network segments | Scan scope, timestamp, and raw results | Scan scope omits segments, guest networks, or remote access ranges |
| Count reachable unauthorized assets | Number of unauthorized assets still reachable after handling | Reconciliation of rescan results against the inventory | Devices removed on paper remain reachable on the network |
| Review handling actions | Evidence that each flagged asset was removed, blocked from remote connection, or quarantined | Tickets, firewall or NAC change records, and removal confirmations | Actions recorded but not verified by a follow-up scan |
| Tooling choice | Evidence that the process works, whatever tools produce it | Tool configuration and outputs the enterprise can explain | Assessor does not prescribe tooling because CAS covers what to measure, not how |
How to build the weekly unauthorized asset process
This sequence turns the approved inventory into a weekly comparison that finds unauthorized devices, applies a documented decision for each one, and proves with a rescan that the device is gone or contained.
Confirm the approved inventory as the reference
Start from the enterprise asset inventory built under Safeguard 1.1, since the CIS assessment specification treats that inventory as a prerequisite for measuring this Safeguard. Confirm that the inventory has an owner, a stated update method and a last-reviewed date, and that every authorized device has a record with an identifier such as hostname, MAC address or serial number. The output is a signed-off reference list and a short note on known gaps, which the weekly comparison will rely on.
Define the weekly comparison and its owner
Write a procedure that compares the latest network discovery results against the approved inventory at least once a week, as Safeguard 1.2 requires. Name one accountable owner for the run and a backup, and state where the discovery output is pulled from, such as an active scanner, DHCP logs or a passive tool. The output is a written procedure and a schedule that show who runs the comparison, when, and what the result looks like.
Set decision rules for each unauthorized asset
Document when the team removes a device from the network, blocks its remote connection, or quarantines it, and who may approve each action. Base the rules on asset type, data sensitivity and whether the owner can be identified, and allow the team to pick a different option only with recorded reasons. The output is an approved decision table that the on-duty person can apply without escalating every case. Confirm the rules with your legal and HR teams before enforcing them against personal or contractor devices.
Run the response and record each action
For every device that fails the comparison, open a ticket that records the discovery date, the identifier, the location if known, the decision chosen and the person who acted. Apply the action through the tools the enterprise already uses, such as switch port disablement, wireless access controls, endpoint management or firewall rules. The output is a closed ticket for each device that shows the action taken and the time it was completed.
Rescan to confirm the device is gone
After each action, run a fresh discovery scan and check that the device no longer responds on the network or can no longer connect remotely. The CIS assessment specification rescans the network and counts unauthorized assets that remain reachable, so this step is where your own results should match what an assessor will see. The output is a rescan result attached to the ticket, and any device still reachable goes back into the process as an open item.
Review exceptions and approve the cycle
Each week, review the tickets that stayed open, the devices granted exceptions and any device that reappeared after removal. Check that every exception has an owner, a reason and an expiry decision, and that repeated arrivals of the same device lead to a root-cause fix such as a change to onboarding. The output is a signed-off weekly summary, kept as evidence, that shows the comparison ran, what was found, and how each case closed.
Which evidence shows unauthorized assets were handled
Safeguard 1.2 is proven by a chain of records rather than a single document: the procedure that defines the response, the comparisons that surface unauthorized devices, the decisions made about each one, and a rescan that confirms the device is gone. Keep these artifacts linked by date and asset identifier so an assessor can follow one device from detection to resolution.
Written weekly response procedure
The documented process names an owner, the weekly run cadence and the time frame for acting on each unauthorized asset. The CIS assessment specification treats a time frame longer than seven days as a failure, so the procedure should state a window of seven days or less. Keep the version history and approval date current, and confirm that the named owner still holds the role. An assessor will ask for the current version and the last run record.
Dated inventory comparison reports
Each run compares discovery output against the approved asset inventory from Safeguard 1.1 and lists every device that does not match. Store each report with its run date, scan scope and the inventory version used. Missing dates or an unclear scope are the most common reasons an assessor cannot rely on the record. An assessor will typically sample several weeks and check that each unmatched device appears in the report.
Response tickets with decisions
Each unauthorized asset gets a ticket that records the chosen option: removal from the network, blocked remote connection or quarantine. The ticket should show who approved the decision and when the action was completed. Link the ticket to the comparison report entry so the path from detection to action is visible. An assessor will sample tickets and check that the stated option matches what was done on the network.
Quarantine and block records
When an asset is quarantined or blocked, the firewall or network controller logs the rule, source address and time of enforcement. Export these records with the ticket reference so the enforcement can be traced. Firewall rules such as OPNsense aliases and logged rule matches can provide this trail. Confirm that logging stays enabled and that the retention period covers the audit window. An assessor will check that the logged block matches the ticket.
Post-action rescan results
After each action, a rescan confirms whether the device is still reachable. The CIS specification counts unauthorized assets that remain reachable, so a clean rescan is the strongest proof that the response worked. Record the rescan date, scope and result beside the original ticket. Repeat rescans for any device that reappears. An assessor will look for rescans that follow each closed ticket, not only a summary count.
Exception logs with approvals
Some devices may be kept off the approved inventory for a documented reason, such as a short-term vendor test or a lab system. Each exception needs a written justification, a named approver, an expiry date and a review date. Exceptions without expiry dates quietly become permanent gaps. An assessor will ask for the exception register and check that expired items were resolved or renewed with fresh approval.
What meeting Safeguard 1.2 costs in money and effort
This table lists each cost component of running Safeguard 1.2, who is paid for it, whether it is one-time or recurring, what drives it up and how to keep it down. Read it as a checklist for a written quote, since the largest recurring cost is usually the weekly triage work rather than software.
| Cost component | One-time or recurring | What drives it up | How to keep it down |
|---|---|---|---|
| Tooling or licenses | Recurring for commercial tools, one-time setup for open source | Number of endpoints, number of sites, need for network enforcement across segments and cloud accounts | Self-hosted open-source inventory and firewall tools remove license spend, but operating and patching effort remains. Confirm each tool's support terms in writing. |
| Engineering time to build comparisons and enforcement rules | One-time, with periodic revision | Number of inventory sources, inconsistent asset identifiers, many network segments with different enforcement points | Define one authoritative inventory key, such as hostname plus MAC address, before building comparison logic. Reuse the same rules across sites. |
| Weekly operating effort for triage and exceptions | Recurring, at least weekly | High device churn, guest and contractor networks, unclear ownership of devices, many exception requests | Set a written exception process with named approvers and expiry dates. Route unknown devices to a single queue with clear removal, blocking or quarantine rules. |
| Evidence upkeep | Recurring | Manual screenshots and spreadsheets, multiple systems of record, no retained run history | Export comparison results and action logs automatically to the same location each week. Keep the approved inventory version history. |
| External review of the process or an independent assessment | Periodic, usually per assessment cycle | Scope size, number of business units, gaps found in earlier reviews | Ask the reviewer to test a sample of flagged assets end to end before the formal review. Fix recurring gaps before the assessment window. |
| Auditor sampling time | Per assessment cycle | Number of samples the assessor selects, missing records for flagged assets, unclear closure evidence | Keep a closed-loop record for each flagged asset showing detection, action and confirmation that it is gone. Make these records easy to filter by date. |
| Quote and scope definition | One-time, before work starts | Vague scope, undefined asset classes, unclear boundary between the organization and any partner | Ask the quote to list in-scope networks, the tools to be configured, who runs each weekly step, and which evidence is delivered and in what format. |
Open-source tools that produce the Safeguard 1.2 evidence
Safeguard 1.2 needs two things on record: proof that unauthorized assets were found, and a record that each one was removed, blocked or quarantined. The three tools below cover the parts of that chain most often built on open-source platforms: the approved inventory, the endpoint view of what is connected, and the network enforcement point. Each produces different evidence, so confirm how each one behaves in your own environment before relying on it.
GLPI Assets module
GLPI is licensed under GPL-3.0-or-later. Its Assets module records computers, monitors, software, network equipment, printers, phones and racks, entered by hand or pushed by the GLPI Agent through native inventory built into GLPI since version 10. This is the approved list for Safeguard 1.2: a device found on the network with no matching record is the unauthorized asset your weekly process must handle. Record each decision (removed, blocked or quarantined) against that asset. Confirm which device types, such as printers or switches without an agent, are maintained manually and who verifies those entries.
Wazuh Syscollector inventory
Wazuh is licensed under GPL-2.0-only. Its Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users, groups and Windows updates from each endpoint. The data is stored in the Wazuh indexer and shown in dashboard inventory views and reports. For Safeguard 1.2, it gives the endpoint's own account of what it is, which helps you decide whether a flagged device is a managed host with a stale record or a device that never belonged in the estate. Syscollector reports only from endpoints running a Wazuh agent, so confirm how unmanaged devices will appear to the weekly process.
OPNsense packet filter rules
OPNsense is licensed under BSD-2-Clause and runs a stateful packet filter. Rules pass, block or reject traffic by source, destination, port and protocol, and aliases group addresses so one rule can cover a list of flagged devices. Each rule-match log entry, viewable in the live log, shows that traffic from a flagged device was stopped, which is the enforcement evidence for the blocking and quarantine options. Confirm whether your blocks follow the device or its IP address. An address-based rule stops matching once the device changes address, so recheck it at each weekly run.
Who owns the decision, who prepares the evidence and who tests it
Your organization owns the control. The approved inventory, the weekly decision on each unauthorized asset and the removal, blocking or quarantine action all sit with your staff, because the Safeguard asks the enterprise to run the process, not a vendor. Assessors will look for named owners and a record of who decided what and when.
- Approved inventory owner: maintains the list of authorized assets that Safeguard 1.1 requires, so every weekly comparison has a trusted baseline.
- Weekly decision owner: reviews unmatched devices at least once a week and decides whether each is removed, blocked from remote connection or quarantined.
- Operations staff: carries out the network action and records the date, the device identifier and the person who approved it.
- Exception approver: signs off on any device that is kept for a business reason, with a documented justification and a review date.
- Process documentation: holds the written procedure, including the time frame you commit to, so it can be compared with the seven-day threshold in the assessment specification.
Before an assessment, confirm that each role has a named person, a backup and a recorded schedule for the weekly run.
An implementation partner such as DeployOpen can prepare the systems and documents that make the process repeatable. This work is usually outsourced because it involves configuring the inventory feed, the firewall or network access controls and the reporting, and few internal teams have spare capacity for it. The partner works inside your environment and under a written scope, and it does not decide which devices are authorized.
- Comparison design: sets up the matching between discovered addresses and the approved inventory, so unmatched assets surface in a report.
- Enforcement configuration: prepares the rules on your firewall or access platform that block or isolate a flagged asset, such as aliases and logged rule matches on OPNsense.
- Runbook: writes the step-by-step weekly procedure, escalation path and rollback steps for your operators.
- Evidence pack: collects the reports, configuration exports, tickets and dated logs that show the process ran each week.
- Process testing: can place a test device on the network and confirm the workflow detects and handles it, which is useful before the auditor arrives.
The partner prepares this evidence but does not issue any audit report, attestation or certification. Only an independent auditor or certification body does that.
The independent auditor tests the control and forms the opinion. Its work is separate from the team that built the process, so the result carries weight with customers, regulators and certification bodies. The auditor samples the records, asks for the evidence and performs its own checks, which may include rescanning the network.
- Record sampling: selects weekly review cycles and checks that each unauthorized asset has a recorded decision and action.
- Network rescan: checks whether flagged assets are still reachable, which is the basis of the coverage measure in the assessment specification.
- Prerequisite check: confirms the approved inventory from Safeguard 1.1 exists and is current, because the measurement depends on it.
- Timeline check: compares the time frame you documented with the seven-day threshold in the assessment specification.
- Reporting: issues the findings, opinion or report under its own name, according to the framework that applies.
Ask any auditor or certification body early which evidence it will sample and whether it accepts evidence prepared by a partner.
Questions teams ask about Safeguard 1.2 before hiring help
How much effort does the weekly unauthorized asset process take?
The effort depends mostly on how many assets fall outside the approved inventory each week and how quickly your team can confirm ownership. Safeguard 1.2 requires a process, run at least weekly, that deals with unauthorized assets by removing them from the network, blocking their remote connection, or quarantining them. Recurring effort comes from three places: reviewing the list of unknown devices, contacting owners to establish whether a device is authorized, and carrying out the chosen response. A stable environment with well-maintained inventory data produces a short weekly review. A large or poorly tracked estate, with many contractor or personal devices, produces far more follow-up. Ask any provider to size the weekly workload from your own discovery data before agreeing a scope.
Can our in-house team run Safeguard 1.2 without outside help?
Yes, many organizations run this process internally, provided they have an accurate asset inventory and clear authority to act on what they find. Safeguard 1.2 depends on Safeguard 1.1, the enterprise asset inventory, because the CIS assessment specification treats that inventory as a prerequisite for measuring it. Teams without a maintained inventory, or without a documented decision on who may remove or quarantine a device, usually need help building those foundations first. Outside help is most useful for setting up discovery and inventory tooling such as GLPI or Wazuh, writing the weekly procedure, and producing repeatable evidence. Whatever you choose, the organization keeps ownership of the control and of its decisions.
How long does it take to reach the first clean rescan?
There is no fixed duration, because the time depends on the factors that decide how quickly unauthorized assets can be found and resolved. The CIS assessment specification scores Safeguard 1.2 as failing when the time frame for dealing with unauthorized assets is longer than seven days, then rescans the network and counts unauthorized assets that are still reachable. The main drivers are the completeness of the inventory, the number of assets to investigate, the speed of owner responses, whether network changes need approval, and how many segments the scan must reach. Ask for a written plan that lists each dependency and who owns it, rather than a single date.
What does the work need from our organization?
The work needs three things from your side: access to inventory and network data, approval for network changes, and named owners who act on findings. Read access to your inventory, DHCP or IP address management logs, and discovery results lets the process compare what is connected with what is approved. Change approval matters because removing a device or quarantining it may affect production systems, so the response rules should be agreed in advance. Named owners for each network segment and for the process as a whole prevent flagged assets from waiting indefinitely. Confirm these items in the written scope before work starts.
Does CIS certify that we comply with Safeguard 1.2?
No. CIS publishes the CIS Critical Security Controls and states that they do not replace any regulatory, compliance or authorization scheme. CIS does not certify organizations against the Controls, and no CIS report or certificate confirms that Safeguard 1.2 is met. Where a formal opinion is needed, an independent assessor or auditor reviews your evidence and reaches its own conclusion, and a provider such as DeployOpen can prepare systems, controls and evidence for that review but does not issue any report or certification. Ask any firm offering CIS certification to show who issues the document and under which authority.
How does this process map to SOC 2 CC7.1 and PCI DSS 11.2.1 evidence?
CIS maps Safeguard 1.2 in its Navigator to SOC 2 CC7.1 and PCI DSS v4.0 requirement 11.2.1, so the same process can feed evidence for both. The weekly records of flagged devices, the decisions taken, and the rescan results are the material an assessor would typically request. For SOC 2, the question is whether the process supports how your organization monitors for and responds to changes in its environment, and your auditor decides how that applies to your system description. For PCI DSS, requirement 11.2.1 concerns identifying unauthorized wireless access points, so the scope of the process must match your cardholder data environment. Confirm both mappings with your auditor before relying on them.
How DeployOpen prepares Safeguard 1.2 evidence
DeployOpen works on Safeguard 1.2 as a fixed-scope implementation inside your own infrastructure, so the weekly unauthorized asset process runs on your systems and produces records you own. We prepare the tooling, the workflow and the documentation an assessor will ask to see, while your team remains accountable for the control itself.
How we scope
- We agree the written scope for Safeguard 1.2 before work starts, naming the networks, sites and asset classes covered.
- We confirm the current time frame your organization uses to act on unauthorized assets and check it against the seven-day assessment threshold.
- We record which response options (removal, blocking remote connection or quarantine) your organization has chosen and who approves each one.
How we build
- We connect the asset inventory from Safeguard 1.1 to discovery feeds so unauthorized devices are flagged for review on a weekly cycle.
- We configure quarantine and access blocking with the network controls already in your environment, such as firewall rules and aliases, and confirm they are logged.
- We set up reports that list flagged assets, the action taken and the date each one was confirmed gone from the network.
How we hand over
- We document the weekly handling process, roles and escalation steps in a form your team can run without us.
- We provide a rescan procedure and the records an independent assessor would request to confirm unauthorized assets are no longer reachable.
- We walk your operations staff through the dashboards, reports and runbooks so the process continues after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work is complete.
- We can review the weekly process records and rescan results on a schedule agreed in the retainer.
- Assessment decisions stay with your organization and the independent auditor or assessor, since DeployOpen prepares evidence but does not issue reports or certifications.
