Safeguard 1.2: Address Unauthorized Assets

To meet the safeguard 1.2: address unauthorized assets requirement, you must detect assets that appear in your environment without approval, then either remove them, formally authorize them, or isolate them under defined exception rules. Operationalize this with an owned workflow: continuous discovery, triage/decisioning, ticketed remediation, and retained evidence that shows each unauthorized asset reached validated closure. ¹

Key takeaways:

• Define “unauthorized” in writing, then enforce it with discovery-to-remediation workflows. ¹
• Treat every unknown asset as an incident-like event: identify, contain risk, decide disposition, validate closure. ²
• Audits focus on proof of operation: logs of detections, tickets, approvals, and removal/authorization evidence. ¹

Unauthorized assets are one of the fastest paths to preventable security failures because they sit outside normal ownership, patching, monitoring, and access control. Safeguard 1.2 is CIS’s requirement-level push to close that gap: you are expected to find assets that should not be there and take action, not just maintain an inventory. ¹

For a Compliance Officer, CCO, or GRC lead, the practical problem is rarely “do we have a tool.” It’s whether the organization can prove a repeatable operating process: who investigates a newly discovered device, VM, SaaS integration, or cloud resource; how quickly the team decides whether it is legitimate; what “authorization” means; and where evidence lives when an auditor asks you to show the last several unauthorized assets and what happened to them. ²

This page gives you an operator’s runbook for implementing the safeguard 1.2: address unauthorized assets requirement with clear control ownership, decision criteria, step-by-step execution, and an evidence bundle you can hand to internal audit, customers, or assessors.

Requirement: Safeguard 1.2 — Address Unauthorized Assets (CIS Controls v8)

Safeguard 1.2 expects action on assets that appear in your environment without approval. Your program must (1) detect unauthorized assets and (2) disposition them through removal, authorization, or containment under an approved exception path. ¹

Plain-English interpretation

An “asset” is anything that can store, process, or transmit your data, or influence your security posture. An asset becomes “unauthorized” when it is present in your environment but does not meet your organization’s approval and ownership rules.

In plain terms, you need a closed-loop workflow:

1. discover assets continuously,
2. flag “unknown/unauthorized,”
3. assign an owner to investigate,
4. decide: remove, authorize, or isolate,
5. confirm the action worked,
6. keep evidence that ties discovery to closure. ²

Who it applies to (entity + operational context)

This requirement applies broadly to enterprises, service organizations, and technology organizations adopting CIS Controls v8. ¹

Operationally, it applies anywhere assets can “show up” without governance:

• Corporate networks (wired, Wi‑Fi, VPN)
• End-user endpoints (managed and unmanaged)
• Data center and virtual infrastructure
• Cloud infrastructure (accounts, subscriptions, projects, VPCs/VNETs, compute, storage)
• SaaS and third-party integrations (OAuth apps, API tokens, connected apps)
• Remote offices, labs, and M&A environments
• Developer-created resources (test systems, shadow environments)

If you have third parties with network access (MSPs, contractors, joint development partners), your “unauthorized asset” definition must cover assets they introduce too, even if they are not “your” hardware. Treat this as part of third-party access governance in practice. ¹

Regulatory text

Excerpt (provided): “CIS Controls v8 safeguard 1.2 implementation expectation (Address Unauthorized Assets).” ¹

What the operator must do:

• Establish a process to identify assets that are not approved to be in your environment. ¹
• Take documented action for each unauthorized asset: remove it, bring it under management through formal authorization, or restrict it through an exception mechanism with compensating controls. ²
• Maintain proof that the process runs as designed (ownership, cadence/trigger events, and evidence of completed dispositions). ¹

What you actually need to do (step-by-step)

Step 1: Write a strict, testable definition of “unauthorized asset”

Create a one-page standard that answers:

• What counts as an asset in scope (devices, VMs, cloud resources, SaaS connections).
• What “authorized” means (registered in inventory/CMDB, has a business owner, meets baseline security controls, approved network segment/account).
• What “unauthorized” means (unknown to inventory, no owner, outside approved accounts/subnets, violates build standards, connected without approval). ¹

Operator tip: Make the definition measurable. If an asset cannot be matched to an owner and a record of approval, it is unauthorized by default pending triage.

Step 2: Establish discovery sources and a single intake queue

You need at least one reliable way to detect new or unknown assets, then funnel detections into one queue for triage. Common sources include:

• Network discovery / NAC logs
• Endpoint management enrollment events
• Cloud asset inventory and configuration monitoring
• Directory/IdP device registrations
• EDR “new host” detections
• SaaS admin consoles for connected apps ²

Operational requirement: detections must create trackable work (ticket/case) with timestamps and assignment.

Step 3: Triage and classify each finding

For each detected asset, triage should answer:

• Is it real and in-scope (not a scanner artifact)?
• What is it (type, OS/platform, location/account, network segment)?
• Who owns it (business unit and technical owner)?
• What data or privileges does it have?

Create standard dispositions:

• Remove: decommission/shut down, disconnect from network, revoke credentials, delete cloud resource.
• Authorize: add to inventory, assign owner, enroll in endpoint management/EDR, apply baseline hardening, tag correctly, document approval.
• Exception/Isolate: temporary allowance with documented risk acceptance, time-bounded, and compensating controls (segmentation, restricted access, monitoring). ¹

Step 4: Make authorization a controlled approval, not a casual label

Authorization should require evidence that the asset is now governable. Minimum authorization gates you can enforce:

• Named owner accountable for patching and access
• Asset record created (inventory/CMDB or cloud tagging standard)
• Security tooling coverage confirmed (as applicable)
• Network placement approved (segment/subnet/security group)
• If third-party owned: third-party sponsor and access terms documented ¹

Step 5: Execute remediation with validated closure

Closure needs verification, not “ticket closed.” Examples:

• Removal: proof the device is blocked/quarantined, VM terminated, SaaS app disconnected.
• Authorization: proof the asset is enrolled/managed, appears in inventory with owner and tags, baseline applied.
• Exception: approved exception record with end date, compensating controls configured, review trigger set. ²

Step 6: Run control health checks

Schedule recurring checks that answer:

• Are discovery feeds working (no silent failures)?
• Are tickets being created and assigned?
• Are dispositions completed and validated?
• Are exceptions reviewed and expired items closed? ¹

A lightweight way to do this: a monthly control health review meeting with Security Operations, IT, and Cloud Ops, backed by a short metrics snapshot (counts and aging are fine as internal management metrics, but avoid publishing unsourced benchmarks).

Required evidence and artifacts to retain

Keep an “evidence bundle” that can be produced quickly:

Control design artifacts

• Control card / runbook for safeguard 1.2 (objective, owner, trigger events, steps, exception rules). ¹
• Definition of “authorized vs unauthorized” and scope statement. ¹
• RACI matrix (who triages, who approves authorization, who can isolate/remove).

Operational evidence ¹

• Discovery logs or system reports showing new/unknown assets detected.
• Ticket/case records for a sample of unauthorized assets (include timestamps, assignment, investigation notes, disposition decision).
• Closure validation evidence (screenshots/exports showing termination, quarantine, enrollment, tagging, or revoked access).
• Exception approvals and compensating control proof, plus review outcomes. ²

Retention location

• A defined repository path (GRC tool, ticketing system, evidence drive) with access controls and an index that maps evidence to the control. ¹

Common exam/audit questions and hangups

Auditors and customer assessors tend to ask for proof of repeatability and completeness:

• “How do you define an unauthorized asset?” Expect to show a written definition and decision criteria. ¹
• “Show me the last set of unauthorized assets detected and what happened to them.” Expect to produce tickets plus closure evidence. ²
• “What happens if an asset cannot be attributed to an owner?” Expect a default containment/removal rule with escalation. ¹
• “How do you know discovery is working?” Expect control health checks and monitoring of discovery sources. ¹
• “How do exceptions work, and who approves them?” Expect documented approvals and time-bounded reviews. ²

Frequent implementation mistakes (and how to avoid them)

1. Inventory-only compliance. Teams maintain a list but do not prove disposition of unauthorized assets. Fix: require a ticket and closure evidence for each unauthorized detection. ¹

2. No owner, no accountability. Findings bounce between IT and Security. Fix: name a control owner and define triage SLAs internally (as policy guidance) with escalation paths. ¹

3. “Authorize” becomes a loophole. Assets get approved without being managed. Fix: make authorization contingent on enrollment/tagging/tooling coverage and owner assignment. ²

4. Exceptions never expire. Risk acceptance becomes permanent shadow IT. Fix: require an end date and periodic review trigger for each exception, and track to closure. ¹

5. Discovery blind spots. Cloud accounts, SaaS connectors, and lab networks are excluded. Fix: document scope explicitly and add discovery sources iteratively; track gaps as remediation items. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement. Practical risk still maps cleanly to real incident patterns: unauthorized assets often lack monitoring, patching, and access governance, which increases the chance of unnoticed compromise and data exposure. Use that framing in risk registers and audit narratives, and tie remediation to owned closure. ¹

Practical 30/60/90-day execution plan

First 30 days (stand up the control)

• Assign control ownership and approve the “unauthorized asset” definition and scope statement. ¹
• Document the control card/runbook, including disposition paths and exception rules. ¹
• Connect discovery sources to a single intake queue (ticketing or SOAR) and confirm tickets are created consistently. ²
• Run an initial sweep, triage the highest-risk unknowns first (internet-exposed, privileged, production). Document outcomes.

By 60 days (make it repeatable)

• Implement authorization gates (owner + inventory record + baseline controls) and enforce them for new approvals. ¹
• Define the minimum evidence bundle and standardize ticket templates so responders capture what auditors ask for. ¹
• Start recurring control health checks and track remediation items to validated closure with due dates. ¹
• Build an exception register for assets that cannot be removed quickly, with compensating controls and review triggers. ²

By 90 days (operate and prove)

• Expand discovery coverage to known blind spots (cloud, SaaS connectors, remote networks) and document any residual gaps with owners and timelines. ¹
• Produce a quarterly-ready evidence package: sample tickets across asset types, exception reviews, and a control health check record.
• Add a management reporting view (counts, aging, top sources) for operational steering and audit readiness. ²

Where Daydream fits (practical, not theoretical)

If you struggle with consistency and evidence retrieval, Daydream can help you convert safeguard 1.2 into a requirement control card, define the minimum evidence bundle, and run recurring control health checks with tracked remediation to validated closure. That is the operational backbone auditors look for. ¹

Frequently Asked Questions

What counts as an “unauthorized asset” in practice?

Treat any asset detected in your environment that cannot be mapped to an approved owner and an approved record (inventory/tag/registration) as unauthorized pending triage. Write this definition down so triage outcomes stay consistent. ¹

Can we satisfy safeguard 1.2 if we only do quarterly asset reviews?

A periodic review helps, but safeguard 1.2 expects you to address unauthorized assets, which requires a discovery-to-disposition workflow that runs reliably. If you cannot show timely tickets and closures, auditors may treat the control as not operating. ²

How do we handle unauthorized assets introduced by third parties?

Put them into the same intake and disposition workflow, then decide whether to remove, authorize under a third-party sponsor, or isolate with compensating controls. Document the sponsor and access terms so ownership is clear. ¹

What evidence is usually most convincing to auditors?

A short sample set of unauthorized asset cases with end-to-end traceability: detection record, ticket, investigation notes, approval (if authorized), and closure validation proof. Pair that with the control runbook and exception register. ¹

What if an asset is “unauthorized” but business-critical and can’t be removed quickly?

Use a time-bounded exception with compensating controls (segmentation, restricted access, monitoring) and track it like any other risk acceptance. The key is documented approval and a review trigger tied to closure. ²

How do we prevent “authorization” from becoming a rubber stamp?

Require objective gates for authorization, such as owner assignment, inventory record creation, and baseline security control coverage where applicable. Make the approver accountable for confirming those gates are met. ¹

Footnotes

1. CIS Controls v8

2. CIS Controls Navigator v8