Research

Implementing All 153 CIS Controls v8.1 Safeguards: 13,020 PRD Requirements, Boundaries, and Proof (July 2026)

A field guide and machine-readable implementation register for all 153 CIS Controls v8.1 Safeguards. Each Safeguard carries 72–108 atomic requirements across twelve product and operating dimensions, plus exact populations, owners, control points, evidence, negative tests, exception expiry, platform boundaries, dependency-first rollout, and forty reproducible CAS findings.

A warm-paper investigative workbench where 153 small control cards flow from three foundation ledgers through evidence gates, clocks, negative-test tools, and an operating security shield

In this article

AssessmentInformational

PublishedJuly 27, 2026

UpdatedJuly 28, 2026

Evidence confidenceHigh

Research basisResearch cutoff 2026-07-28; the normative Navigator and all eighteen CAS pages remain the pinned 2026-07-27 source set. A 2026-07-28 live recheck found a changed Navigator page wrapper but zero changes across the 153 structured Safeguard IDs, titles, descriptions, IG assignments, and Asset Classes; all eighteen CAS pages remained byte-identical. CIS Controls v8.1 remains the current official release with eighteen Controls and 153 Safeguards: 56 first appear in IG1, 74 more in IG2, and 23 more in IG3. SOSEC reconciled the Navigator and CAS set with the June 2024 v8.1 core guide; audited dependencies, inputs, operations, measures, metrics, cadence, formulas, official-surface drift, Asset Classes, and Security Functions; wrote a four-boundary implementation contract for every Safeguard; and expanded each one into 72–108 original atomic PRD requirements across twelve dimensions, 13,020 aligned requirement pairs in total. The forty-item CAS anomaly ledger records high-confidence reproducible defects or unsafe measurement boundaries in the pinned sources and defines a bounded audit result. Companion guidance bounds cloud, mobile, IoT/ICS, and AI applicability. No live enterprise was assessed, no CIS score is issued, and organization-specific risk, regulation, architecture, safety, contracts, and authorized testing remain necessary.

SourceOfficial CIS Controls v8.1, Navigator, Implementation Group and Asset Class guidance / CIS Controls Assessment Specification and terms / official Cloud, Mobile, IoT, ICS, AI, RAM, CDM, and CSAT material / SOSEC July 27–28, 2026 153-Safeguard implementation-boundary, 13,020-requirement PRD, and CAS consistency audit

1 The implementation decision: use v8.1, build the dependency spine, and require six-field proof

The answer: use the current CIS Controls v8.1 set of 153 Safeguards, then convert every Safeguard into an implementable product and operating contract. This revision carries 13,020 bilingual atomic requirements: 72–108 for each Safeguard across outcome, population, ownership, data, integration, control flow, timing, failure, evidence, security, testing, and operations. Begin with the 56 IG1 Safeguards as the minimum target, while sequencing delivery around three authority hubs: asset inventory 1.1, software inventory 2.1, and secure configuration 4.1. Acceptance requires an in-scope population, accountable owner, enforcement or decision point, evidence source and freshness, positive and negative control, and expiring exception. CAS supplies useful Level-1 measurement ingredients; SOSEC's pinned audit found forty reproducible defects or unsafe measurement boundaries that require reconciliation before automation. Cloud, SaaS, mobile, IoT/ICS, and AI keep the same intent while relocating populations, provider evidence, control points, and consumer tests.

This conclusion changes the work plan. A small organization should still target IG1 first, yet Control order is not a construction schedule. Sixty-four CAS dependency edges point to 1.1, fifty to 2.1 and forty-three to 4.1. Those three authorities supply denominators and baseline decisions to much of the framework. Weak inventories let every later dashboard improve by excluding unknown assets, software or settings; reliable authorities make gaps visible and therefore initially make the program look worse.

The publication below is an original implementation field guide and PRD register. It references every official Safeguard by identifier and short title, preserves the four decisive boundary summaries, and places a collapsible 72–108-item requirement register under every card. Those requirements specify product states, schemas, roles, integrations, abnormal flows, SLOs, exception exits, metrics, abuse cases, failure injection, rollout, rollback, and operational closure. The official v8.1 release and current Navigator remain the normative descriptions.

1.1 The code-and-response equivalent: a 90-day implementation contract

CIS Controls is a public framework. It exposes no internal product function to patch. The closest verifiable control points are the v8.1 Safeguard identifier and description, the current Navigator record, the CAS input/operation/measure page, the environment's actual policy engine or procedure, and the generated evidence receipt. There is no patch version to install. Sustainable implementation is permanent; temporary measures reduce exposure while the authoritative population and control path are built.

Fixed reference and source identity

Normative object: CIS Controls v8.1, 18 Controls and 153 Safeguards, fixed by identifier. Record retrieval date and source hash because the live Navigator and CAS “latest” pages can change without a new local assessment.
Measurement object: CAS provides platform-neutral inputs, operations, measures and metrics for Level-1 implementation. Import it as a reviewed reference, preserve local corrections separately, and never overwrite the official source while calling the result CIS.

The six-field acceptance receipt

Population: Name the authoritative denominator, inclusion/exclusion rule, discovery sources, deduplication identity and empty-population result. Unknown and unevaluable objects remain visible.
Control and owner: Name the accountable business owner, operating team, precise policy/procedure/enforcement point, deployment version and dependency authorities.
Proof: Retain configuration or process evidence, its collection time and freshness SLO, one working positive path, one denied or failed negative path, and the observed outcome.
Exception: Bind affected objects, business reason, risk owner, compensating action, start/expiry, review trigger and a testable exit. Expiry returns the object to failure until renewed with new evidence.

The twelve-dimension PRD decomposition

Decision system: Write outcome, population, ownership, data contract, dependencies, control flow and timing as separate requirements with identifiable inputs, states, actors and outputs.
Operating system: Write exception and failure paths, evidence and metrics, security/privacy/resilience, positive and adversarial tests, rollout, rollback, renewal and closure. Each card below carries six to nine requirements in every dimension.
Machine-readable receipt: The public bilingual JSON register contains all 13,020 aligned requirement pairs, their category, source basis, Safeguard identity, dependency context, cadence terms and per-item depth count. Its SHA-256 is BC9BE410DFFE5278FE0C9D05DE397D26957FDCB3F9B189D8A183315238897FC6.

Temporary containment while foundations are incomplete

First 24 hours: Freeze new unmanaged Internet exposure and privileged provider integrations, identify critical services/data/identity authorities, assign owners, and place unknown assets or access paths into a restricted state when operationally safe.
First 30 days: Reconcile the highest-consequence asset, software, account, provider and data populations; establish secure baseline and log-source authorities; implement termination, MFA, backup isolation and external-exposure containment for the critical subset.
Limit: Containment cannot earn full Safeguard acceptance. It has a named scope, reduced business capability, monitoring and an exit date leading to the permanent control.

Release and rollback

Promotion: Promote from observation to enforcement only after required business positives and representative bypass negatives pass, population coverage is known, exceptions are approved and rollback is tested.
Failure: A source, parser, policy, provider or test failure marks affected receipts stale or unevaluable. Keep the last known result for history; do not silently present it as current compliance.

Six evidence stations on warm paper connect a population ledger, accountable owner, enforcement gate, freshness clock, negative-test probe, and expiring exception to one implementation receipt — **Figure 1.** A Safeguard becomes operational when its population, owner, control point, evidence clock, negative test, and exception exit can be read from one receipt. Product deployment is one station, not the finish line.

1.2 The first 90 days: four waves with exit tests

Days 0–15 establish command and scope. Select the target IG with CIS RAM and business risk; assign one owner per Control and one evidence owner per platform; freeze the source snapshots; define stable identifiers, populations, SLOs and the exception schema. The exit test is a critical-service map whose assets, software, accounts, data, providers, Internet paths, backups and logging sources each have an owner and an unresolved-state queue.

Days 16–30 build authority hubs. Reconcile 1.1, 2.1 and 4.1 for the critical population, then add account/authentication, data and provider inventories plus network architecture. The exit test samples records in both directions, injects an unknown object and demonstrates its disposition. A dashboard that cannot show missing and duplicate objects is not ready for downstream percentages.

Days 31–60 enforce essential paths. Implement IG1 identity lifecycle and MFA, supported/authorized software, secure management and endpoint/server policy, patching, DNS/email/anti-malware protection, automated protected backups, reporting and response ownership. Each change has a positive business control, a bypass negative and rollback. Temporary exceptions lose access or exposure as their compensating controls weaken.

Days 61–90 close the first operating loop. Centralize and test logs, vulnerability closure, recovery, provider evidence and incident communications; run an external exposure check, recovery exercise and incident tabletop. Review overdue evidence and exceptions, select risk-driven IG2 additions, and publish item-level receipts; one blended “CIS score” hides distinct failure modes.

2 What “implemented” means: source reconciliation, measurement depth, and risk tailoring

2.1 Research scope, pinned sources, and the licensing boundary

As of July 28, 2026, CIS lists v8.1 as the current Controls release. The official set contains 18 Controls and 153 Safeguards. The Implementation Groups page assigns 56 to the cumulative IG1 baseline, 130 to cumulative IG2 and all 153 to IG3; expressed as first appearance, the increments are 56, 74 and 23. v8.1 aligns security functions with NIST CSF 2.0, revises asset classes and clarifies selected descriptions.

SOSEC fixed three source layers on July 27 and repeated the live comparison on July 28. The pinned Navigator HTML snapshot has SHA-256 A9A8FAC266DFEF2DFB831512485498C99780018D9F53BCD711665540292D939E; the parsed Navigator record has SHA-256 96DC0C7CBD163B59902FC91056CD0D54601EC8378E7E327765B0112F7D3F2DE1. The live Navigator wrapper changed after CIS added new surrounding resource content, while a field-by-field comparison of all 153 IDs, titles, descriptions, IG assignments and Asset Classes found zero changes. All eighteen CAS pages remained byte-identical; their combined parsed record has SHA-256 62F534394EC54064A7CD3CED4ABD9AC34B60A5220CBD05A2910E71B5D499DC06. The June 2024 v8.1 core guide used for reconciliation has SHA-256 79072AE8BDF102AD60CFB8A1510C4A117F16124B376D8D48B56BB13ADC3D4090.

CIS Controls and CAS carry CIS terms and a CC BY-NC-ND 4.0 notice. This report uses identifiers and short official titles for nominative reference, attributes and links the official work, and supplies original implementation analysis. It does not republish the official descriptions, distribute a modified CIS edition, issue an official certification or grant commercial reuse rights for CIS material. Organizations should obtain CIS permission where their intended commercial reproduction requires it.

2.2 CAS is valuable Level-1 scaffolding; forty pinned anomalies make literal automation unsafe

The official CAS methodology makes an important distinction: it focuses on whether a Safeguard is implemented and on what to measure, while platform implementation and the quality of operation sit elsewhere. All 153 current pages contain dependencies, inputs, operations and measures; 151 contain a metric. Only 16 state assumptions, one includes a procedural review, and 137 omit both. This structure is useful for naming inputs and candidate denominators. It is too thin to establish operating effectiveness by itself.

SOSEC recorded forty high-confidence anomalies or unsafe measurement boundaries in the fixed sources. They include invalid arithmetic such as 11.1 component count divided by months since review; reversed outcomes in 2.2, 5.1 and 18.3; undefined or shifted variables in 3.3, 3.11, 4.4 and 4.5; missing metrics in 4.12 and 13.10; repeated workforce formulas in 14.2–14.9 that divide headcount by a Boolean and reward non-completion; and a 7.7 assumption that treats scan disappearance as remediation. This bounded anomaly set applies to the pinned assessment text. Automation must review and reconcile the affected variables, formulas, labels and outcomes before use.

The official surfaces also drift. CAS calls 8.4 a Network asset while the Navigator and core guide say Data. Navigator calls 9.4 Applications while the core guide and CAS say Software. CAS carries a corrupted 12.5 title and an Identfy function for 16.4. The core guide agrees with different live surfaces on different description changes, including 11.1, 12.6, 14.7 and 17.5. A controlled implementation therefore records the exact source and reconciles differences; “latest” is not an immutable evidence identifier.

Three official document layers enter a warm comparison desk where five evidence devices expose arithmetic, variable, scope, missing-metric, and reversed-outcome conflicts before a local operating-effectiveness layer — **Figure 2.** The official core guide, current Navigator and current CAS pages are useful but not identical surfaces. SOSEC reconciles their snapshot first, then adds operating-effectiveness and negative-test evidence outside CAS's Level-1 focus.

SOSEC adds four evidence layers to the normative intent: design and documented decision; complete population and denominator; live enforcement or procedure execution; negative test plus observed outcome. A fifth operational layer tracks exception expiry and renewal. CSAT can organize assessment work, and the hosted CSAT guide describes assignments and assessment history, while neither a workflow state nor a numeric score overrides missing population or a failed test.

2.3 IG is a target baseline; dependency and risk decide the build sequence

CIS says every enterprise should begin with IG1. That is a sound minimum target, not permission to ignore context and not a claim that every IG2/IG3 safeguard can wait. A software producer handling customer identity may need Control 16 threat modeling and code checks early. A hospital or industrial operator may need network segmentation, recovery isolation and incident communications before a less consequential IG1 optimization. CIS RAM v2.2 supplies an official risk method for v8.1, while the Community Defense Model 2.0 supplies threat-based prioritization context.

The CAS dependency graph has no cycle and exposes the construction spine. Safeguards 1.1, 2.1 and 4.1 receive 64, 50 and 43 incoming references. The next hubs are data inventory 3.2, network baseline 4.2, architecture diagrams 12.4, account inventory 5.1 and provider inventory 15.1. Dependency metadata remains advisory: 8.11 has no stated dependency on collected logs, and 2.6 points to network baseline 4.2. Engineering judgment repairs those missing or narrow edges.

Three foundation authorities for enterprise assets, software, and secure configuration feed identity, data, vulnerability, logging, recovery, network, people, provider, development, response, and testing systems while unknown objects remain quarantined — **Figure 3.** IG gives a useful target set; dependencies give a workable build order. Safeguards 1.1, 2.1 and 4.1 are the main authority hubs in the current CAS graph, so the program builds their receipts before scaling downstream automation.

A practical backlog therefore carries two labels: target tier and dependency wave. Wave A establishes authority and owners. Wave B implements essential enforcement on the critical population. Wave C adds telemetry, validation and recovery. Wave D adds risk-selected depth and continuous optimization. A Safeguard can enter an earlier wave because its risk is high even when its official first tier is IG2 or IG3.

2.4 Cloud, SaaS, mobile, IoT/ICS, and AI change the evidence point

The official v8.1 Cloud Companion Guide applies the Controls from the consumer perspective. IaaS, PaaS, SaaS and FaaS move implementation tasks between provider and consumer, while the consuming organization still identifies the configured account, region, service, data and control result. A provider report establishes scoped provider evidence; tenant API state and a real positive/negative path establish consumer implementation.

Mobile boundaries depend on ownership and management model: corporate-owned, COPE, BYOD, fully managed or unmanaged. The official mobile material describes MDM/EMM, app vetting and mobile threat defense as complementary tools. The v8.1 IoT Companion Guide and v8.1 ICS Workbook highlight devices that cannot accept ordinary agents or changes without safety, warranty and uptime consequence. Those limitations produce an explicit alternative control and safety-approved test, not a hidden exclusion.

AI systems add model, dataset, prompt, retrieval, memory, agent, tool and non-human identity populations. CIS published separate LLM, AI Agent and MCP companion guidance in April 2026 and a combined v8.1.2 AI Security Guidance Workbook on July 27. The workbook organizes implementation across asset visibility and governance, software and supply chain, and data protection for LLM, agent and MCP environments. Controls 1–3 inventory those objects and data; 5–6 govern human and workload authority; 8 and 13 preserve prompt/tool decisions and detections; 15–16 govern providers, components, design and tests. Deterministic authorization remains a separate decision from probabilistic model output.

One safeguard card crosses on-premises, cloud, SaaS, mobile, industrial, and AI workspaces; each workspace hands back a different tenant configuration, provider receipt, negative test, and residual-risk tag — **Figure 4.** Platform-neutral intent survives across environments, while the population, control point and attainable evidence change. Provider responsibility never removes the consumer's need to prove the configured tenant and the real path in use.

3 Foundation: assets, software, data, and secure configuration

The first four Controls create the objects and baselines that later ratios consume. Read them as one investigation: discover a thing, decide who owns and authorizes it, identify its software and data, establish its role-specific state, then prove enforcement and lifecycle. The cards preserve each Safeguard's distinct denominator and test.

3.1 Control 1: Inventory and Control of Enterprise Assets

Control 1 is the first dependency spine, because every coverage ratio needs a defensible population. The implementation is an identity-and-lifecycle reconciliation service, not a scanner export: cloud billing, MDM/EDR, virtualization, networks, procurement and disposal must disagree visibly until an owner resolves them. The five Safeguards progress from authority, to disposition, to active, DHCP and passive observation.

The decisive boundary is disappearance. A sleeping laptop, terminated cloud API response or silent OT segment cannot be credited as removed without custody or enforcement evidence. The same rule prevents unknown assets from falling out of the denominator when a discovery source fails.

Primary measurement reference: official CAS Control 1; the cards below add an independent implementation boundary to that control.

CIS Safeguard 1.1 · Establish and Maintain Detailed Enterprise Asset Inventory · IG1 onward

Population and scope: The population includes every device able to store or process enterprise data: managed and unmanaged endpoints, servers, network appliances, virtual machines, ephemeral cloud instances, containers' host/control-plane assets, mobile, IoT/OT, lab and regularly connected third-party devices. DNS names or IP observations are evidence sources, not stable asset identities.
Implementation and owner: Make one asset authority reconcile procurement, MDM/EDR, hypervisors, cloud organizations and accounts, network discovery, DHCP/IPAM, and disposal records. Give every record a durable identifier, owner, business purpose, approval state, location or tenancy, first/last seen time, and lifecycle state; define creation and retirement SLOs instead of waiting for the six-month review.
Evidence and negative test: Prove both completeness and field quality against an independently assembled aggregate population. Sample assets from cloud billing, switch tables, EDR, MDM and finance back to the register; seed one approved and one unauthorized test asset; verify creation, ownership, quarantine and retirement. Report matched, missing, duplicate, stale and ownerless counts with a declared empty-population rule.
Exception and failure boundary: A scanner's silence never proves absence: sleeping laptops, private subnets, serverless services, SaaS tenants, isolated OT and travel devices need other sources. BYOD may be out of management but remains in the connection population. An exception identifies the device, custodian, network path, compensating restriction, expiry and removal test; a spreadsheet with no reconciliation is only a list.

PRD implementation register · 84 atomic requirements · 12 dimensions · inventory · expanded complexity

O01Outcome and decision. Define the user, business, and risk outcome for Establish and Maintain Detailed Enterprise Asset Inventory; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 1.1, official Asset Class Devices, Security Function Identify, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The population includes every device able to store or process enterprise data: managed and unmanaged endpoints, servers, network appliances, virtual machines, ephemeral cloud instances, containers' host/control-plane assets, mobile, IoT/OT, lab and regularly connected third-party devices.” Convert each object in the claim into a queryable population or an approved applicability decision.

O04Outcome and decision. Maintain separate statuses for normative intent, design approval, deployment, fresh evidence, positive control, negative control, exception, and observed operating outcome.

O05Outcome and decision. Connect Establish and Maintain Detailed Enterprise Asset Inventory to its operating object—physical, virtual, cloud, mobile, IoT/OT, lab, and regularly connected third-party enterprise assets—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Establish and Maintain Detailed Enterprise Asset Inventory, express success as an observable decision over observed, approved, unapproved, ownerless, stale, duplicate, and retired object identity; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For the expanded Establish and Maintain Detailed Enterprise Asset Inventory scope, resolve conflicts among security, safety, privacy, legal, availability, customer, and operational objectives through an explicit risk decision.

P01Population and applicability. Build an authoritative denominator before calculating coverage; record the query, owner, collection time, tenant, environment, inclusions, exclusions, and unresolved objects.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P03Population and applicability. Represent an empty population, discovery failure, unsupported platform, inaccessible provider evidence, and approved out-of-scope decision as five distinct results.

P04Population and applicability. Sample in both directions—from the authority to the live estate and from the live estate to the authority—and retain missing, duplicate, stale, orphaned, and cross-tenant results.

P05Population and applicability. Resolve applicability across sleeping, ephemeral, disconnected, unmanaged, duplicated, shared-address, and safety-sensitive assets; each edge receives an evidenced in-scope, out-of-scope, unknown, or time-bounded exception result.

P06Population and applicability. Include dormant, ephemeral, disconnected, externally managed, provider-held, aliased, cloned, and cross-tenant objects in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

P07Population and applicability. Define nested scope at enterprise, business service, tenant, environment, platform, object, identity, data set, and transaction levels; prohibit a parent result from hiding a failing child.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W03Ownership and approval. For outsourced operation, assign an internal accountable owner and identify the provider operator, tenant administrator, evidence supplier, notification route, and contractual gap.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W05Ownership and approval. Bind asset owners, platform and network operators, procurement, and security operations to a RACI for the Safeguard and name the authority that resolves conflicting source or risk decisions.

W06Ownership and approval. Name who may transition discovered → pending identity → approved/unapproved → contained/exception → retired with custody evidence, who approves the transition, who supplies evidence, and who independently reviews it.

W07Ownership and approval. Model delegated authority, quorum or dual approval where warranted, escalation deadlines, provider handoffs, conflict resolution, and executive risk acceptance.

D01Data contract and identity. Define a stable object identity, aliases, parent/child relationships, tenant and environment keys, source provenance, first/last-seen time, owner, state, and tombstone behavior.

D02Data contract and identity. Version the schema and normalization rules; preserve the raw-source identifier, collection time, parser version, confidence, and prior value for every material decision field.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV2, M1, M2, M3, M4, M5, M6, M7, M8) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D05Data contract and identity. Use the reconciled enterprise asset authority as the governed current-state record; persist identity, owner, provenance, prior/new state, reason, actor, time, and exception link.

D06Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle discovered → pending identity → approved/unapproved → contained/exception → retired with custody evidence.

D07Data contract and identity. Version schemas and state transitions with migration, backfill, deduplication, lineage, historical denominator, deletion, and rollback semantics.

I01Dependencies and integrations. Record prerequisite state for no explicit predecessor in the pinned CAS page; add locally required dependencies and justify every omitted or substituted predecessor.

I02Dependencies and integrations. For every API, agent, file, message, manual attestation, or provider export, specify authentication, authorization, schema, pagination, rate limits, replay, idempotency, and error handling.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I04Dependencies and integrations. Define a fallback and reconciliation path for provider outage, credential expiry, network partition, schema drift, delayed delivery, partial results, and manual operation.

I05Dependencies and integrations. Reconcile procurement, EDR/MDM, hypervisors, cloud inventories, DHCP/IPAM, network discovery, and disposal records and expose source-specific health, latency, confidence, omissions, and conflict resolution.

I06Dependencies and integrations. Require every connector carrying observed, approved, unapproved, ownerless, stale, duplicate, and retired object identity to preserve tenant, object identity, source time, collection time, completeness, and failure status.

I07Dependencies and integrations. Define consistency rules across disagreeing sources, source precedence, confidence, reconciliation queues, dead-letter handling, reprocessing, and end-to-end trace identity.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Make one asset authority reconcile procurement, MDM/EDR, hypervisors, cloud organizations and accounts, network discovery, DHCP/IPAM, and disposal records.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C02Control flow and enforcement. Name the closest reliable policy, procedure, configuration, identity, network, application, data, provider, or human decision point that changes the protected state.

C03Control flow and enforcement. Define allowed, denied, contained, quarantined, deferred, exception, unknown, failed, rolled-back, and closed outcomes where they apply; each outcome needs an owner and next action.

C04Control flow and enforcement. Specify validation, authorization, idempotency, retry, deduplication, concurrency, transaction boundary, rollback, and compensating action for automated and manual execution.

C05Control flow and enforcement. Implement the state transition in the reconciled enterprise asset authority and preserve the exact operating control point, policy or procedure version, result, and downstream update.

C06Control flow and enforcement. Implement the explicit state machine discovered → pending identity → approved/unapproved → contained/exception → retired with custody evidence; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

C07Control flow and enforcement. Specify concurrent decisions, partial success, compensating transactions, repeated requests, stale policy, dependency outage, and recovery from an interrupted state transition.

T01Timing and lifecycle. Preserve the official cadence terms found in the pinned description (bi-annually, annually); define faster local SLOs where asset change, exposure, safety, or threat consequence requires them.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T03Timing and lifecycle. Store event time, source time zone, collection time, processing time, decision time, and expiry; define handling for clock skew, late arrivals, backfill, and daylight-saving changes.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T05Timing and lifecycle. Set freshness and action SLOs from the rate of change in physical, virtual, cloud, mobile, IoT/OT, lab, and regularly connected third-party enterprise assets; source age, queue age, exception age, and closure age remain separate clocks.

T06Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for discovered → pending identity → approved/unapproved → contained/exception → retired with custody evidence; alert before each deadline becomes overdue.

T07Timing and lifecycle. Allocate an end-to-end SLO budget across discovery, collection, processing, approval, enforcement, verification, and closure; prioritize overdue work by consequence and exposure.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “A scanner's silence never proves absence: sleeping laptops, private subnets, serverless services, SaaS tenants, isolated OT and travel devices need other sources.” Convert every condition into a detectable state and response.

X02Exceptions and failure modes. Require exception scope, exact affected objects, owner, reason, threat and business consequence, compensating control, evidence, start, expiry, review trigger, and tested exit.

X03Exceptions and failure modes. Define fail-open, fail-closed, fail-safe, partial, unknown, stale, provider-unsupported, safety-constrained, privacy-constrained, and emergency states where relevant.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X05Exceptions and failure modes. Treat sleeping, ephemeral, disconnected, unmanaged, duplicated, shared-address, and safety-sensitive assets as designed non-happy paths with an owner, compensating control, expiry, safety or business constraint, and retest.

X06Exceptions and failure modes. Treat dormant, ephemeral, disconnected, externally managed, provider-held, aliased, cloned, and cross-tenant objects as named failure or exception paths with an owner, compensating control, expiry, and retest.

X07Exceptions and failure modes. Exercise compound failures where an exception, stale source, provider outage, unavailable owner, and degraded control overlap; define one safe command and one accountable decision.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Prove both completeness and field quality against an independently assembled aggregate population.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E02Evidence and metrics. Publish numerator and denominator as drill-down object sets with query version, collection time, exclusions, unknowns, duplicates, stale records, and a declared empty-population rule.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 10 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E04Evidence and metrics. Retain configuration or procedure version, source receipt, positive and negative results, exception evidence, reviewer identity, integrity hash, retention class, and replay instructions.

E05Evidence and metrics. Derive coverage and effectiveness from the reconciled enterprise asset authority plus independent source receipts; report unknown, stale, conflicting, failed, and excepted objects separately.

E06Evidence and metrics. Publish matched, missing, duplicate, stale, ownerless, unapproved, unevaluable, and retired-without-proof counts with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

E07Evidence and metrics. Require an independent party to reconstruct the decision from source receipts and reproduce the population, state transition, calculation, test result, exception, and final closure.

S01Security, privacy, and resilience. Apply least privilege and separation of duties to the authority, connectors, policy engine, evidence store, exception workflow, break-glass path, and administrative recovery.

S02Security, privacy, and resilience. Minimize secrets and personal or regulated data in requirements, telemetry, tests, screenshots, exports, and public evidence; define redaction and controlled raw-evidence access.

S03Security, privacy, and resilience. Protect policy, state, timestamps, logs, tests, and approvals against tampering with independent custody, immutable history where warranted, and alerting on disabled evidence paths.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S05Security, privacy, and resilience. Protect write and approval authority over the reconciled enterprise asset authority; monitor privileged changes, exports, deletions, source disablement, and recovery.

S06Security, privacy, and resilience. Restrict authority to change discovered → pending identity → approved/unapproved → contained/exception → retired with custody evidence; log privileged changes, protect evidence history, and test administrative recovery.

S07Security, privacy, and resilience. Threat-model the implementation system itself: forged evidence, poisoned inventory, privilege abuse, cross-tenant confusion, policy rollback, audit deletion, denial of service, and recovery compromise.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V02Verification and adversarial tests. Run an unauthorized or invalid negative control plus stale, duplicate, malformed, out-of-order, cross-tenant, and bypass variants; verify the intended denial or safe disposition.

V03Verification and adversarial tests. Inject source, credential, parser, policy, network, provider, queue, storage, clock, reviewer, and rollback failures; verify health detection and the declared degraded state.

V04Verification and adversarial tests. Use risk-stratified platform samples covering critical, common, exceptional, newly changed, provider-managed, safety-sensitive, remote, and ephemeral populations.

V05Verification and adversarial tests. Exercise approved and unauthorized seeded assets, a disappearing asset, a duplicate identity, and a failed discovery source through representative platforms and verify business behavior, control decision, telemetry, case workflow, rollback, and final state.

V06Verification and adversarial tests. Run the positive control a seeded approved object reconciled from two independent sources; exercise negative, stale, duplicate, bypass, and outage controls including an unknown object, duplicate identity, stale record, vanished object, failed source, and cross-tenant collision.

V07Verification and adversarial tests. Build a pairwise platform-and-failure matrix, then add high-consequence multi-factor cases, historical regression, source substitution, red-team challenge, and assessor replay.

R01Operations, change, and closure. Promote through design, observe, canary, enforce, and scale stages with entry and exit criteria, business positives, negative controls, exception readiness, and tested rollback.

R02Operations, change, and closure. Monitor population growth, source health, stale evidence, failed actions, backlog age, exception expiry, control bypass, false positives, false negatives, and recurring causes.

R03Operations, change, and closure. Invalidate affected receipts after source, parser, policy, owner, provider, architecture, software, data-use, or threat change; retain history while displaying the current state as stale.

R04Operations, change, and closure. Close only after the protected state changes, evidence is fresh, positive and negative controls pass, downstream authorities reconcile, residual risk is recorded, and recurrence monitoring is active.

R05Operations, change, and closure. Re-run reconciliation and affected tests whenever procurement, EDR/MDM, hypervisors, cloud inventories, DHCP/IPAM, network discovery, and disposal records change ownership, schema, coverage, provider, policy, or platform version.

R06Operations, change, and closure. Use matched, missing, duplicate, stale, ownerless, unapproved, unevaluable, and retired-without-proof counts to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

R07Operations, change, and closure. Use canary deployment, kill criteria, rollback, backlog burn-down, exception reduction, source-quality targets, quarterly design review, and a measurable retirement plan.

CIS Safeguard 1.2 · Address Unauthorized Assets · IG1 onward

Population and scope: The denominator is every asset observed outside the approved state, including unknown hardware, unmanaged virtual machines, stale cloud resources, rogue wireless devices and approved assets connected through an unapproved path. A detection can be false, but it cannot disappear merely because the device becomes unreachable.
Implementation and owner: Define a weekly-or-faster disposition queue joining the asset register to NAC, MDM, EDR, cloud and network evidence. The asset owner and network or cloud control owner must choose remove, deny, quarantine or formally authorize; each choice records who acted, where enforcement occurred and when the case closes.
Evidence and negative test: Plant an unauthorized test device and cloud instance, then confirm detection, ticket creation, containment at every reachable path and final inventory update. The numerator is cases with an evidenced disposition inside the SLO, not cases a scanner failed to see again; retest from a second segment or identity before closure.
Exception and failure boundary: Sleeping, roaming, powered-off and segmented assets stay open until custody or enforcement is established. Medical, OT or safety systems may use isolation instead of shutdown. A business request is not authorization until the register and enforcement policy agree, and recurring discoveries of the same asset reopen the root-cause problem.

PRD implementation register · 72 atomic requirements · 12 dimensions · inventory

O01Outcome and decision. Define the user, business, and risk outcome for Address Unauthorized Assets; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 1.2, official Asset Class Devices, Security Function Respond, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The denominator is every asset observed outside the approved state, including unknown hardware, unmanaged virtual machines, stale cloud resources, rogue wireless devices and approved assets connected through an unapproved path.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Address Unauthorized Assets to its operating object—physical, virtual, cloud, mobile, IoT/OT, lab, and regularly connected third-party enterprise assets—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Address Unauthorized Assets, express success as an observable decision over observed, approved, unapproved, ownerless, stale, duplicate, and retired object identity; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV2, M1, M2, M3, M4, M5) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 1.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Define a weekly-or-faster disposition queue joining the asset register to NAC, MDM, EDR, cloud and network evidence.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T01Timing and lifecycle. Preserve the official cadence terms found in the pinned description (weekly); define faster local SLOs where asset change, exposure, safety, or threat consequence requires them.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Sleeping, roaming, powered-off and segmented assets stay open until custody or enforcement is established.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Plant an unauthorized test device and cloud instance, then confirm detection, ticket creation, containment at every reachable path and final inventory update.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 7 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 1.3 · Utilize an Active Discovery Tool · IG2 onward

Population and scope: Cover every scannable routed zone, address family, cloud network and remote-access range at the required cadence; distinguish excluded, unreachable and deliberately non-scannable space. Kubernetes pods, short-lived workloads and SaaS are not reliably represented by a periodic IP sweep.
Implementation and owner: Operate authenticated or unauthenticated discovery from enough vantage points to cross segmentation without bypassing safety constraints. Inventory the scanners themselves, pin scope and credentials, alert on failed jobs, normalize observations to durable asset identities, and feed new candidates into 1.1/1.2 at least daily.
Evidence and negative test: Measure scheduled zones, successfully scanned zones, address space attempted, responsive objects normalized, and discoveries reconciled. Seed a temporary host in a covered subnet and a cloud instance shorter-lived than one scan cycle; the first must be found, while the second demonstrates the residual gap that event sources must cover.
Exception and failure boundary: Discovery coverage is zones successfully completed divided by in-scope zones, not discovered assets divided by an existing inventory; the latter can exceed 100% and reward duplicates. Rate limits, IDS blocks and credential failure are failed coverage. Safety-sensitive OT requires approved passive or controller evidence, never an undocumented exclusion.

PRD implementation register · 84 atomic requirements · 12 dimensions · inventory, discovery

O01Outcome and decision. Define the user, business, and risk outcome for Utilize an Active Discovery Tool; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 1.3, official Asset Class Devices, Security Function Detect, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Cover every scannable routed zone, address family, cloud network and remote-access range at the required cadence; distinguish excluded, unreachable and deliberately non-scannable space.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Utilize an Active Discovery Tool to its operating object—physical, virtual, cloud, mobile, IoT/OT, lab, and regularly connected third-party enterprise assets—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Utilize an Active Discovery Tool, express success as an observable decision over observed, approved, unapproved, ownerless, stale, duplicate, and retired object identity; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Utilize an Active Discovery Tool, express success as an observable decision over coverage of every intended discovery vantage point, source, job, parser, and reconciliation path; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P07Population and applicability. Include unreachable zones, short-lived objects, blind spots, rate limits, credential failure, encrypted or proprietary protocols, and silent sensors in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W07Ownership and approval. Name who may transition scheduled → started → observed → normalized → reconciled → dispositioned, with explicit partial and failed states, who approves the transition, who supplies evidence, and who independently reviews it.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV3, M1, M2, M3, M4, M5, M6, M7) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D07Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle scheduled → started → observed → normalized → reconciled → dispositioned, with explicit partial and failed states.

I01Dependencies and integrations. Record prerequisite state for Safeguard 4.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I07Dependencies and integrations. Require every connector carrying coverage of every intended discovery vantage point, source, job, parser, and reconciliation path to preserve tenant, object identity, source time, collection time, completeness, and failure status.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Operate authenticated or unauthenticated discovery from enough vantage points to cross segmentation without bypassing safety constraints.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C07Control flow and enforcement. Implement the explicit state machine scheduled → started → observed → normalized → reconciled → dispositioned, with explicit partial and failed states; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

T01Timing and lifecycle. Preserve the official cadence terms found in the pinned description (daily); define faster local SLOs where asset change, exposure, safety, or threat consequence requires them.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T07Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for scheduled → started → observed → normalized → reconciled → dispositioned, with explicit partial and failed states; alert before each deadline becomes overdue.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Discovery coverage is zones successfully completed divided by in-scope zones, not discovered assets divided by an existing inventory; the latter can exceed 100% and reward duplicates.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X07Exceptions and failure modes. Treat unreachable zones, short-lived objects, blind spots, rate limits, credential failure, encrypted or proprietary protocols, and silent sensors as named failure or exception paths with an owner, compensating control, expiry, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Measure scheduled zones, successfully scanned zones, address space attempted, responsive objects normalized, and discoveries reconciled.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 9 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E07Evidence and metrics. Publish scheduled, successful, partial, failed, stale, blind, newly discovered, unmatched, and reconciled observations with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S07Security, privacy, and resilience. Restrict authority to change scheduled → started → observed → normalized → reconciled → dispositioned, with explicit partial and failed states; log privileged changes, protect evidence history, and test administrative recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V07Verification and adversarial tests. Run the positive control a known object visible from each representative vantage point; exercise negative, stale, duplicate, bypass, and outage controls including an unknown and short-lived object, failed credential, blocked scan, silent sensor, parser drift, and uncovered segment.

R07Operations, change, and closure. Use scheduled, successful, partial, failed, stale, blind, newly discovered, unmatched, and reconciled observations to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

CIS Safeguard 1.4 · Use Dynamic Host Configuration Protocol (DHCP) Logging to Update Enterprise Asset Inventory · IG2 onward

Population and scope: The scope is every enterprise-managed DHCP service and equivalent address allocator across campuses, wireless, VPN, IPv4/IPv6, cloud and virtual networks. Static addresses, self-assigned IPv6, containers, NAT and SaaS remain outside DHCP's visibility and require complementary evidence.
Implementation and owner: Send authoritative lease and allocation events to a protected collector, preserve server, tenant, MAC or client identifier, hostname, address, lease time and network context, and reconcile them into the asset register at least weekly. The network owner also maintains a complete allocator inventory and clock synchronization.
Evidence and negative test: Generate a lease from a known test client, verify collection, parsing, asset matching and timely expiry; then use an unknown client to confirm it enters the unauthorized queue. Measure active allocators producing complete logs over all in-scope allocators and successful reconciliations over eligible lease events, with duplicates and privacy-randomized identifiers separated.
Exception and failure boundary: A positive count of correctly logging servers is success, despite the current CAS text interpreting one such measure as stale inventory. DHCP identifies a network attachment, not device ownership or approval. Shared MACs, relay loss, randomized mobile identities and overlapping cloud addresses need tenant and relay context before records are merged.

PRD implementation register · 84 atomic requirements · 12 dimensions · inventory, telemetry

O01Outcome and decision. Define the user, business, and risk outcome for Use Dynamic Host Configuration Protocol (DHCP) Logging to Update Enterprise Asset Inventory; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 1.4, official Asset Class Devices, Security Function Identify, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The scope is every enterprise-managed DHCP service and equivalent address allocator across campuses, wireless, VPN, IPv4/IPv6, cloud and virtual networks.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Use Dynamic Host Configuration Protocol (DHCP) Logging to Update Enterprise Asset Inventory to its operating object—physical, virtual, cloud, mobile, IoT/OT, lab, and regularly connected third-party enterprise assets—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Use Dynamic Host Configuration Protocol (DHCP) Logging to Update Enterprise Asset Inventory, express success as an observable decision over observed, approved, unapproved, ownerless, stale, duplicate, and retired object identity; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Use Dynamic Host Configuration Protocol (DHCP) Logging to Update Enterprise Asset Inventory, express success as an observable decision over complete, attributable, timely, protected, searchable, and actionable security telemetry plus source health; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P07Population and applicability. Include clock skew, actor loss, field truncation, parser drift, dropped or duplicate events, privacy redaction, provider gaps, encrypted paths, quota, and archive failure in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W07Ownership and approval. Name who may transition event produced → collected → parsed → enriched → stored → detected/reviewed → preserved/expired, who approves the transition, who supplies evidence, and who independently reviews it.

D03Data contract and identity. Map the pinned CAS variable set (GV41, M1, M2, M3, M4, M5, M6, M7) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D07Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle event produced → collected → parsed → enriched → stored → detected/reviewed → preserved/expired.

I01Dependencies and integrations. Record prerequisite state for Safeguard 1.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I07Dependencies and integrations. Require every connector carrying complete, attributable, timely, protected, searchable, and actionable security telemetry plus source health to preserve tenant, object identity, source time, collection time, completeness, and failure status.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Send authoritative lease and allocation events to a protected collector, preserve server, tenant, MAC or client identifier, hostname, address, lease time and network context, and reconcile them into the asset register at least weekly.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C07Control flow and enforcement. Implement the explicit state machine event produced → collected → parsed → enriched → stored → detected/reviewed → preserved/expired; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T07Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for event produced → collected → parsed → enriched → stored → detected/reviewed → preserved/expired; alert before each deadline becomes overdue.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “A positive count of correctly logging servers is success, despite the current CAS text interpreting one such measure as stale inventory.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X07Exceptions and failure modes. Treat clock skew, actor loss, field truncation, parser drift, dropped or duplicate events, privacy redaction, provider gaps, encrypted paths, quota, and archive failure as named failure or exception paths with an owner, compensating control, expiry, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Generate a lease from a known test client, verify collection, parsing, asset matching and timely expiry; then use an unknown client to confirm it enters the unauthorized queue.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 3 pinned CAS metric branch(es), 8 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E07Evidence and metrics. Publish healthy, silent, partial, late, malformed, duplicate, unowned, unreviewed, alerted, investigated, and archived sources or events with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S07Security, privacy, and resilience. Restrict authority to change event produced → collected → parsed → enriched → stored → detected/reviewed → preserved/expired; log privileged changes, protect evidence history, and test administrative recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V07Verification and adversarial tests. Run the positive control an allowed and denied canary event traced from source through review; exercise negative, stale, duplicate, bypass, and outage controls including source loss, parser/schema change, time skew, queue overflow, duplicate delivery, provider export outage, missed alert, and unreadable archive.

R07Operations, change, and closure. Use healthy, silent, partial, late, malformed, duplicate, unowned, unreviewed, alerted, investigated, and archived sources or events to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

CIS Safeguard 1.5 · Use a Passive Asset Discovery Tool · IG3 onward

Population and scope: Include network segments where passive telemetry can lawfully and technically observe asset presence, particularly unmanaged, fragile, IoT and OT populations. Encrypted payloads still expose useful flow, MAC, protocol and fingerprint observations. Switched, wireless, east-west cloud and host-only traffic may remain invisible.
Implementation and owner: Place passive sensors or consume switch, flow, wireless-controller and cloud-flow telemetry at documented choke points. Maintain sensor health, tap/SPAN loss, clock, parser version and segment mapping; deduplicate observations and route unknown assets to 1.2 without letting a fingerprint silently overwrite authoritative identity.
Evidence and negative test: Replay a benign test protocol and attach an unregistered device on each representative segment. Prove packet or flow arrival, classification, inventory correlation and alert latency; measure observable segments with healthy data over all segments selected for passive coverage, plus packet-drop and unknown-fingerprint rates.
Exception and failure boundary: A sensor that is online but sees no expected heartbeat has failed. TLS, NAT, overlay networks and asymmetric routing limit attribution; passive discovery cannot establish software inventory or authorization by itself. Safety or privacy exclusions state the data fields omitted, retention, compensating source and review date.

PRD implementation register · 84 atomic requirements · 12 dimensions · inventory, discovery

O01Outcome and decision. Define the user, business, and risk outcome for Use a Passive Asset Discovery Tool; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 1.5, official Asset Class Devices, Security Function Detect, and IG3 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Include network segments where passive telemetry can lawfully and technically observe asset presence, particularly unmanaged, fragile, IoT and OT populations.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Use a Passive Asset Discovery Tool to its operating object—physical, virtual, cloud, mobile, IoT/OT, lab, and regularly connected third-party enterprise assets—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Use a Passive Asset Discovery Tool, express success as an observable decision over observed, approved, unapproved, ownerless, stale, duplicate, and retired object identity; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Use a Passive Asset Discovery Tool, express success as an observable decision over coverage of every intended discovery vantage point, source, job, parser, and reconciliation path; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV3, GV4, M1, M2, M3, M4, M5) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 4.2, Safeguard 12.4; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Place passive sensors or consume switch, flow, wireless-controller and cloud-flow telemetry at documented choke points.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T01Timing and lifecycle. Preserve the official cadence terms found in the pinned description (weekly, at least weekly); define faster local SLOs where asset change, exposure, safety, or threat consequence requires them.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “A sensor that is online but sees no expected heartbeat has failed.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Replay a benign test protocol and attach an unregistered device on each representative segment.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 7 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

3.2 Control 2: Inventory and Control of Software Assets

Control 2 turns observed code into an authorized, supported and enforceable deployment population. It has to include SaaS, container images, portable programs and transitive components where the enterprise can govern them; an endpoint package list alone leaves the modern software estate largely unowned.

Inventory, support, removal and allowlisting are different decisions. A product can be authorized and vulnerable, signed and unapproved, or absent from a host scan while embedded in an image. The evidence follows artifact identity, source, environment and actual execution; the product name is only one attribute.

Primary measurement reference: official CAS Control 2; the cards below add an independent implementation boundary to that control.

CIS Safeguard 2.1 · Establish and Maintain a Software Inventory · IG1 onward

Population and scope: The population includes operating systems, installed packages, browser and office extensions, mobile apps, firmware where managed as software, container images, language dependencies, SaaS applications, cloud marketplace images and internally built releases. A package name alone cannot distinguish edition, version, source or support state.
Implementation and owner: Reconcile endpoint and server inventory, package managers, MDM, container registries, SBOMs, CI/CD catalogs, cloud and SaaS administration into one software authority linked to assets and business owners. Record publisher, product, version, install or deployment location, authorization, source, support channel and lifecycle dates; review at least twice yearly and on material change.
Evidence and negative test: Select samples from endpoints, clusters, repositories, cloud accounts and expense/SSO catalogs and trace both directions. Deploy an unauthorized package and an ephemeral container image to test detection. Report inventoried, unknown, unsupported, unowned, duplicate and unverifiable versions against a separately assembled deployment population.
Exception and failure boundary: Agent-only inventories miss portable binaries, build-time dependencies, dormant images, SaaS purchased outside SSO and firmware. An SBOM leaves the match to the running artifact unverified until the two are reconciled. Development tools may be authorized in build zones and forbidden in production; authorization therefore binds software, version, source, environment and purpose.

PRD implementation register · 96 atomic requirements · 12 dimensions · software_dev, inventory · expanded complexity

O01Outcome and decision. Define the user, business, and risk outcome for Establish and Maintain a Software Inventory; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 2.1, official Asset Class Software, Security Function Identify, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The population includes operating systems, installed packages, browser and office extensions, mobile apps, firmware where managed as software, container images, language dependencies, SaaS applications, cloud marketplace images and internally built releases.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Establish and Maintain a Software Inventory to its operating object—operating systems, packages, firmware, extensions, container images, dependencies, SaaS applications, and internally built releases—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Establish and Maintain a Software Inventory, express success as an observable decision over source-to-production software identity, design invariant, component trust, build provenance, test result, deployment state, runtime outcome, and vulnerability response; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Establish and Maintain a Software Inventory, express success as an observable decision over observed, approved, unapproved, ownerless, stale, duplicate, and retired object identity; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For the expanded Establish and Maintain a Software Inventory scope, resolve conflicts among security, safety, privacy, legal, availability, customer, and operational objectives through an explicit risk decision.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P05Population and applicability. Resolve applicability across portable binaries, dormant images, static linking, shadow SaaS, mutable packages, unsupported editions, and environment-specific authorization; each edge receives an evidenced in-scope, out-of-scope, unknown, or time-bounded exception result.

P06Population and applicability. Include generated and copied code, forks, vendoring, transitive dependencies, mutable tags, build plugins, feature flags, tenant logic, secrets, emergency release, and provider components in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

P07Population and applicability. Include dormant, ephemeral, disconnected, externally managed, provider-held, aliased, cloned, and cross-tenant objects in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

P08Population and applicability. Define nested scope at enterprise, business service, tenant, environment, platform, object, identity, data set, and transaction levels; prohibit a parent result from hiding a failing child.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W05Ownership and approval. Bind software and application owners, platform engineering, developers, procurement, and security to a RACI for the Safeguard and name the authority that resolves conflicting source or risk decisions.

W06Ownership and approval. Name who may transition designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired, who approves the transition, who supplies evidence, and who independently reviews it.

W07Ownership and approval. Name who may transition discovered → pending identity → approved/unapproved → contained/exception → retired with custody evidence, who approves the transition, who supplies evidence, and who independently reviews it.

W08Ownership and approval. Model delegated authority, quorum or dual approval where warranted, escalation deadlines, provider handoffs, conflict resolution, and executive risk acceptance.

D03Data contract and identity. Map the pinned CAS variable set (GV5, GV6, M1, M2, M3, M4) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D05Data contract and identity. Use the reconciled software and deployment authority as the governed current-state record; persist identity, owner, provenance, prior/new state, reason, actor, time, and exception link.

D06Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired.

D07Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle discovered → pending identity → approved/unapproved → contained/exception → retired with custody evidence.

D08Data contract and identity. Version schemas and state transitions with migration, backfill, deduplication, lineage, historical denominator, deletion, and rollback semantics.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I05Dependencies and integrations. Reconcile endpoint/package inventories, MDM, registries, SBOMs, CI/CD, cloud catalogs, SSO, procurement, and publisher lifecycle sources and expose source-specific health, latency, confidence, omissions, and conflict resolution.

I06Dependencies and integrations. Require every connector carrying source-to-production software identity, design invariant, component trust, build provenance, test result, deployment state, runtime outcome, and vulnerability response to preserve tenant, object identity, source time, collection time, completeness, and failure status.

I07Dependencies and integrations. Require every connector carrying observed, approved, unapproved, ownerless, stale, duplicate, and retired object identity to preserve tenant, object identity, source time, collection time, completeness, and failure status.

I08Dependencies and integrations. Define consistency rules across disagreeing sources, source precedence, confidence, reconciliation queues, dead-letter handling, reprocessing, and end-to-end trace identity.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Reconcile endpoint and server inventory, package managers, MDM, container registries, SBOMs, CI/CD catalogs, cloud and SaaS administration into one software authority linked to assets and business owners.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C05Control flow and enforcement. Implement the state transition in the reconciled software and deployment authority and preserve the exact operating control point, policy or procedure version, result, and downstream update.

C06Control flow and enforcement. Implement the explicit state machine designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

C07Control flow and enforcement. Implement the explicit state machine discovered → pending identity → approved/unapproved → contained/exception → retired with custody evidence; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

C08Control flow and enforcement. Specify concurrent decisions, partial success, compensating transactions, repeated requests, stale policy, dependency outage, and recovery from an interrupted state transition.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T05Timing and lifecycle. Set freshness and action SLOs from the rate of change in operating systems, packages, firmware, extensions, container images, dependencies, SaaS applications, and internally built releases; source age, queue age, exception age, and closure age remain separate clocks.

T06Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired; alert before each deadline becomes overdue.

T07Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for discovered → pending identity → approved/unapproved → contained/exception → retired with custody evidence; alert before each deadline becomes overdue.

T08Timing and lifecycle. Allocate an end-to-end SLO budget across discovery, collection, processing, approval, enforcement, verification, and closure; prioritize overdue work by consequence and exposure.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Agent-only inventories miss portable binaries, build-time dependencies, dormant images, SaaS purchased outside SSO and firmware.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X05Exceptions and failure modes. Treat portable binaries, dormant images, static linking, shadow SaaS, mutable packages, unsupported editions, and environment-specific authorization as designed non-happy paths with an owner, compensating control, expiry, safety or business constraint, and retest.

X06Exceptions and failure modes. Treat generated and copied code, forks, vendoring, transitive dependencies, mutable tags, build plugins, feature flags, tenant logic, secrets, emergency release, and provider components as named failure or exception paths with an owner, compensating control, expiry, and retest.

X07Exceptions and failure modes. Treat dormant, ephemeral, disconnected, externally managed, provider-held, aliased, cloned, and cross-tenant objects as named failure or exception paths with an owner, compensating control, expiry, and retest.

X08Exceptions and failure modes. Exercise compound failures where an exception, stale source, provider outage, unavailable owner, and degraded control overlap; define one safe command and one accountable decision.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Select samples from endpoints, clusters, repositories, cloud accounts and expense/SSO catalogs and trace both directions.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 6 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E05Evidence and metrics. Derive coverage and effectiveness from the reconciled software and deployment authority plus independent source receipts; report unknown, stale, conflicting, failed, and excepted objects separately.

E06Evidence and metrics. Publish reviewed, unreviewed, reproducible, provenance-bound, vulnerable, test-failed, exception, deployed-unverified, drifted, rolled-back, and regression-protected releases with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

E07Evidence and metrics. Publish matched, missing, duplicate, stale, ownerless, unapproved, unevaluable, and retired-without-proof counts with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

E08Evidence and metrics. Require an independent party to reconstruct the decision from source receipts and reproduce the population, state transition, calculation, test result, exception, and final closure.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S05Security, privacy, and resilience. Protect write and approval authority over the reconciled software and deployment authority; monitor privileged changes, exports, deletions, source disablement, and recovery.

S06Security, privacy, and resilience. Restrict authority to change designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired; log privileged changes, protect evidence history, and test administrative recovery.

S07Security, privacy, and resilience. Restrict authority to change discovered → pending identity → approved/unapproved → contained/exception → retired with custody evidence; log privileged changes, protect evidence history, and test administrative recovery.

S08Security, privacy, and resilience. Threat-model the implementation system itself: forged evidence, poisoned inventory, privilege abuse, cross-tenant confusion, policy rollback, audit deletion, denial of service, and recovery compromise.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V05Verification and adversarial tests. Exercise an approved release, an unapproved binary, an unexpected dependency, a short-lived image, and a publisher end-of-support event through representative platforms and verify business behavior, control decision, telemetry, case workflow, rollback, and final state.

V06Verification and adversarial tests. Run the positive control a trusted build that preserves the security invariant through deployment and runtime; exercise negative, stale, duplicate, bypass, and outage controls including a substituted dependency, unreviewed change, poisoned build input, failed security test, bypass path, vulnerable release, rollback, and regression.

V07Verification and adversarial tests. Run the positive control a seeded approved object reconciled from two independent sources; exercise negative, stale, duplicate, bypass, and outage controls including an unknown object, duplicate identity, stale record, vanished object, failed source, and cross-tenant collision.

V08Verification and adversarial tests. Build a pairwise platform-and-failure matrix, then add high-consequence multi-factor cases, historical regression, source substitution, red-team challenge, and assessor replay.

R05Operations, change, and closure. Re-run reconciliation and affected tests whenever endpoint/package inventories, MDM, registries, SBOMs, CI/CD, cloud catalogs, SSO, procurement, and publisher lifecycle sources change ownership, schema, coverage, provider, policy, or platform version.

R06Operations, change, and closure. Use reviewed, unreviewed, reproducible, provenance-bound, vulnerable, test-failed, exception, deployed-unverified, drifted, rolled-back, and regression-protected releases to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

R07Operations, change, and closure. Use matched, missing, duplicate, stale, ownerless, unapproved, unevaluable, and retired-without-proof counts to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

R08Operations, change, and closure. Use canary deployment, kill criteria, rollback, backlog burn-down, exception reduction, source-quality targets, quarterly design review, and a measurable retirement plan.

CIS Safeguard 2.2 · Ensure Authorized Software is Currently Supported · IG1 onward

Population and scope: Assess every authorized product and version against a named publisher or accountable internal support channel, including OS editions, firmware, libraries, container bases, appliances and SaaS features. “Still runs,” community activity and a reseller's assurance are not a supported lifecycle.
Implementation and owner: The software owner records end-of-support dates, update channel, current supported target and migration decision. Review monthly or on vendor notice; unsupported items are upgraded, removed or placed under a time-bounded risk exception with isolation, monitoring and an exit plan.
Evidence and negative test: Verify lifecycle claims at the vendor or maintained-project source, then sample the deployed artifacts and use each artifact as the version authority. Measure supported deployments, documented exceptions and unapproved unsupported deployments over all authorized deployments; test that a simulated end-of-life notice opens affected-asset work.
Exception and failure boundary: The current CAS measures reverse its “with exception” and “without exception” variables, so implementers must define their own stable denominator. Extended support counts only when a contract covers the exact edition and fixes the relevant risks. Frozen OT and embedded products need compensating controls and a replacement date, not permanent acceptance.

PRD implementation register · 84 atomic requirements · 12 dimensions · software_dev, vulnerability

O01Outcome and decision. Define the user, business, and risk outcome for Ensure Authorized Software is Currently Supported; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 2.2, official Asset Class Software, Security Function Identify, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Assess every authorized product and version against a named publisher or accountable internal support channel, including OS editions, firmware, libraries, container bases, appliances and SaaS features.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Ensure Authorized Software is Currently Supported to its operating object—operating systems, packages, firmware, extensions, container images, dependencies, SaaS applications, and internally built releases—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Ensure Authorized Software is Currently Supported, express success as an observable decision over source-to-production software identity, design invariant, component trust, build provenance, test result, deployment state, runtime outcome, and vulnerability response; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Ensure Authorized Software is Currently Supported, express success as an observable decision over affected artifact identity, exploitability, business consequence, remediation choice, deployed fix, compensating control, and residual exposure; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P07Population and applicability. Include unknown versions, false positives, unavailable fixes, vendor lag, ephemeral workloads, unscannable platforms, inherited dependencies, mitigation-only states, and recurrence in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W07Ownership and approval. Name who may transition discovered → validated → prioritized → assigned → fixed/mitigated/excepted → deployed → retested → closed/reopened, who approves the transition, who supplies evidence, and who independently reviews it.

D03Data contract and identity. Map the pinned CAS variable set (GV5, GV6, M1, M2, M3, M4, M5, M6, M7) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D07Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle discovered → validated → prioritized → assigned → fixed/mitigated/excepted → deployed → retested → closed/reopened.

I01Dependencies and integrations. Record prerequisite state for Safeguard 2.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I07Dependencies and integrations. Require every connector carrying affected artifact identity, exploitability, business consequence, remediation choice, deployed fix, compensating control, and residual exposure to preserve tenant, object identity, source time, collection time, completeness, and failure status.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “The software owner records end-of-support dates, update channel, current supported target and migration decision.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C07Control flow and enforcement. Implement the explicit state machine discovered → validated → prioritized → assigned → fixed/mitigated/excepted → deployed → retested → closed/reopened; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

T01Timing and lifecycle. Preserve the official cadence terms found in the pinned description (monthly); define faster local SLOs where asset change, exposure, safety, or threat consequence requires them.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T07Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for discovered → validated → prioritized → assigned → fixed/mitigated/excepted → deployed → retested → closed/reopened; alert before each deadline becomes overdue.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “The current CAS measures reverse its “with exception” and “without exception” variables, so implementers must define their own stable denominator.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X07Exceptions and failure modes. Treat unknown versions, false positives, unavailable fixes, vendor lag, ephemeral workloads, unscannable platforms, inherited dependencies, mitigation-only states, and recurrence as named failure or exception paths with an owner, compensating control, expiry, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Verify lifecycle claims at the vendor or maintained-project source, then sample the deployed artifacts and use each artifact as the version authority.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 4 pinned CAS metric branch(es), 9 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E07Evidence and metrics. Publish open, validated, false-positive, overdue, mitigated, excepted, deployed-unverified, retest-failed, reopened, and exposure-weighted findings with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S07Security, privacy, and resilience. Restrict authority to change discovered → validated → prioritized → assigned → fixed/mitigated/excepted → deployed → retested → closed/reopened; log privileged changes, protect evidence history, and test administrative recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V07Verification and adversarial tests. Run the positive control a known vulnerable artifact repaired and independently retested; exercise negative, stale, duplicate, bypass, and outage controls including credential failure, wrong version match, unavailable fix, mitigation bypass, failed deployment, rollback, recurring finding, and exposed unowned asset.

R07Operations, change, and closure. Use open, validated, false-positive, overdue, mitigated, excepted, deployed-unverified, retest-failed, reopened, and exposure-weighted findings to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

CIS Safeguard 2.3 · Address Unauthorized Software · IG1 onward

Population and scope: Include installed, portable, remotely executed, sideloaded, containerized and user-authorized SaaS software whose product, version, source, environment or purpose falls outside policy. Malware response may overlap, but ordinary unapproved utilities and shadow SaaS remain in this queue.
Implementation and owner: At least monthly, join discovery to the authorized inventory and assign remove, block, quarantine or authorize decisions. Endpoint, cloud, platform and application owners enforce the action at the closest reliable control point and repair the acquisition path, privilege or repository policy that allowed recurrence.
Evidence and negative test: Install a benign unapproved binary, extension and container in test scope; verify discovery, containment, ticket evidence and non-reinstallation. Use remediated unauthorized instances divided by all unauthorized instances found in the period; the CAS formula dividing by remaining findings becomes undefined at full remediation and can exceed one.
Exception and failure boundary: Forensic retention may delay deletion but requires execution prevention and custody. A hash allow rule cannot cover mutable scripts or signed-but-unapproved software. Developer freedom is bounded by environment and data access; recurring software after closure is a control failure, not a new isolated ticket.

PRD implementation register · 72 atomic requirements · 12 dimensions · software_dev

O01Outcome and decision. Define the user, business, and risk outcome for Address Unauthorized Software; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 2.3, official Asset Class Software, Security Function Respond, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Include installed, portable, remotely executed, sideloaded, containerized and user-authorized SaaS software whose product, version, source, environment or purpose falls outside policy.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Address Unauthorized Software to its operating object—operating systems, packages, firmware, extensions, container images, dependencies, SaaS applications, and internally built releases—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Address Unauthorized Software, express success as an observable decision over source-to-production software identity, design invariant, component trust, build provenance, test result, deployment state, runtime outcome, and vulnerability response; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV5, GV7, M1, M2, M3, M4) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 1.1, Safeguard 2.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “At least monthly, join discovery to the authorized inventory and assign remove, block, quarantine or authorize decisions.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Forensic retention may delay deletion but requires execution prevention and custody.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Install a benign unapproved binary, extension and container in test scope; verify discovery, containment, ticket evidence and non-reinstallation.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 7 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 2.4 · Utilize Automated Software Inventory Tools · IG2 onward

Population and scope: Cover all platforms capable of automated collection and declare where an agent, API, registry scan, package query or image analysis is used. Scanning only corporate laptops leaves servers, cloud images, containers, mobile, network appliances and remote assets outside the denominator.
Implementation and owner: Operate tools on a defined schedule, monitor collection age and failures, normalize product/version identities, and reconcile results to both asset and software authorities. Event-driven deployment and registry sources should supplement periodic scans for workloads shorter than the scan interval.
Evidence and negative test: Measure assets with fresh, successful, sufficiently detailed results over eligible assets, then sample raw evidence against the normalized inventory. Seed one package and one portable artifact; test detection, version accuracy and removal. A tool installed but not reporting does not count as covered.
Exception and failure boundary: Unsupported platforms and privacy constraints require a named alternative source. Credentials that cannot enumerate system scope, offline devices and rate-limited APIs are coverage failures. Automated discovery supplies observation, not approval, publisher authenticity or support status.

PRD implementation register · 84 atomic requirements · 12 dimensions · software_dev, inventory

O01Outcome and decision. Define the user, business, and risk outcome for Utilize Automated Software Inventory Tools; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 2.4, official Asset Class Software, Security Function Detect, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Cover all platforms capable of automated collection and declare where an agent, API, registry scan, package query or image analysis is used.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Utilize Automated Software Inventory Tools to its operating object—operating systems, packages, firmware, extensions, container images, dependencies, SaaS applications, and internally built releases—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Utilize Automated Software Inventory Tools, express success as an observable decision over source-to-production software identity, design invariant, component trust, build provenance, test result, deployment state, runtime outcome, and vulnerability response; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Utilize Automated Software Inventory Tools, express success as an observable decision over observed, approved, unapproved, ownerless, stale, duplicate, and retired object identity; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV7, M1, M2, M3, M4, M5) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 1.1, Safeguard 2.3; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Operate tools on a defined schedule, monitor collection age and failures, normalize product/version identities, and reconcile results to both asset and software authorities.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T01Timing and lifecycle. Preserve the official cadence terms found in the pinned description (event- and risk-defined local cadence); define faster local SLOs where asset change, exposure, safety, or threat consequence requires them.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Unsupported platforms and privacy constraints require a named alternative source.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Measure assets with fresh, successful, sufficiently detailed results over eligible assets, then sample raw evidence against the normalized inventory.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 7 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 2.5 · Allowlist Authorized Software · IG2 onward

Population and scope: The executable population includes binaries, packages, installers, interpreters and application launch paths in the protected environment. Define whether policy is deny-by-default, audit-only or publisher/path based; broad writable paths and “any signed code” silently collapse the boundary.
Implementation and owner: Build policy from known business workflows and trusted distribution, enforce at OS, endpoint, container admission or application control, and maintain emergency and update paths. Start in observation, remove noise, then enforce by environment; application owner and security owner jointly approve changes and review at least twice yearly.
Evidence and negative test: Run approved applications and updates as positive controls, then unsigned, renamed, copied-to-writable-path and signed-but-unapproved binaries as negative controls. Measure eligible assets with enforcing policy and blocked unauthorized executions; retain policy version, decision and exception identity.
Exception and failure boundary: Allowlisting does not judge safe behavior and cannot replace vulnerability or malware controls. Interpreters, macros, plugins, containers and remote tools can execute through an allowed parent. Break-glass exceptions are narrow, logged, expiring and tested; audit mode is not enforcement.

PRD implementation register · 84 atomic requirements · 12 dimensions · software_dev, enforcement

O01Outcome and decision. Define the user, business, and risk outcome for Allowlist Authorized Software; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 2.5, official Asset Class Software, Security Function Protect, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The executable population includes binaries, packages, installers, interpreters and application launch paths in the protected environment.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Allowlist Authorized Software to its operating object—operating systems, packages, firmware, extensions, container images, dependencies, SaaS applications, and internally built releases—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Allowlist Authorized Software, express success as an observable decision over source-to-production software identity, design invariant, component trust, build provenance, test result, deployment state, runtime outcome, and vulnerability response; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Allowlist Authorized Software, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P07Population and applicability. Include audit-only mode, unsupported platforms, local overrides, race conditions, cached state, alternate paths, fail-open behavior, and emergency bypass in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W07Ownership and approval. Name who may transition observe → evaluate → decide → enforce → verify outcome → rollback/close, who approves the transition, who supplies evidence, and who independently reviews it.

D03Data contract and identity. Map the pinned CAS variable set (GV3, GV5, GV7, GV8, GV9, M1, M2, M3, M4, M5, M6) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D07Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle observe → evaluate → decide → enforce → verify outcome → rollback/close.

I01Dependencies and integrations. Record prerequisite state for Safeguard 1.1, Safeguard 2.1, Safeguard 2.3, Safeguard 4.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I07Dependencies and integrations. Require every connector carrying an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point to preserve tenant, object identity, source time, collection time, completeness, and failure status.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Build policy from known business workflows and trusted distribution, enforce at OS, endpoint, container admission or application control, and maintain emergency and update paths.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C07Control flow and enforcement. Implement the explicit state machine observe → evaluate → decide → enforce → verify outcome → rollback/close; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T07Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for observe → evaluate → decide → enforce → verify outcome → rollback/close; alert before each deadline becomes overdue.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Allowlisting does not judge safe behavior and cannot replace vulnerability or malware controls.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X07Exceptions and failure modes. Treat audit-only mode, unsupported platforms, local overrides, race conditions, cached state, alternate paths, fail-open behavior, and emergency bypass as named failure or exception paths with an owner, compensating control, expiry, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Run approved applications and updates as positive controls, then unsigned, renamed, copied-to-writable-path and signed-but-unapproved binaries as negative controls.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 11 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E07Evidence and metrics. Publish eligible, enforcing, audit-only, failed, bypassed, excepted, rolled-back, and outcome-verified populations with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S07Security, privacy, and resilience. Restrict authority to change observe → evaluate → decide → enforce → verify outcome → rollback/close; log privileged changes, protect evidence history, and test administrative recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V07Verification and adversarial tests. Run the positive control an approved business action that completes through the enforced path; exercise negative, stale, duplicate, bypass, and outage controls including a prohibited action, alternate path, local override, stale policy, control outage, emergency bypass, and rollback failure.

R07Operations, change, and closure. Use eligible, enforcing, audit-only, failed, bypassed, excepted, rolled-back, and outcome-verified populations to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

CIS Safeguard 2.6 · Allowlist Authorized Libraries · IG2 onward

Population and scope: The population is every dynamically or statically incorporated library, framework, package, plugin and shared object used at build or runtime, including transitive dependencies and container layers. Filename, import name or a broad publisher is too weak when packages can be substituted.
Implementation and owner: Pin approved component identity, version or constrained range, source repository, integrity digest and permitted application/environment in lockfiles, artifact repositories, build policy and runtime loading controls where supported. Block public-package fallback and unreviewed plugin directories; assign component owners and an emergency update path.
Evidence and negative test: Build the same application with an approved component, an unexpected transitive dependency, a dependency-confusion name and a modified digest. Prove admission rejection or an explicit review, artifact/SBOM linkage and runtime match for sampled deployments. Coverage is protected build/deploy paths, not merely components listed.
Exception and failure boundary: Static linking and vendoring hide runtime package queries; dynamically generated code and customer plugins need separate trust boundaries. A vulnerable but approved library still fails Control 7/16. The CAS dependency on network configuration does not establish this safeguard; software inventory, secure builds and repository trust do.

PRD implementation register · 84 atomic requirements · 12 dimensions · software_dev, enforcement

O01Outcome and decision. Define the user, business, and risk outcome for Allowlist Authorized Libraries; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 2.6, official Asset Class Software, Security Function Protect, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The population is every dynamically or statically incorporated library, framework, package, plugin and shared object used at build or runtime, including transitive dependencies and container layers.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Allowlist Authorized Libraries to its operating object—operating systems, packages, firmware, extensions, container images, dependencies, SaaS applications, and internally built releases—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Allowlist Authorized Libraries, express success as an observable decision over source-to-production software identity, design invariant, component trust, build provenance, test result, deployment state, runtime outcome, and vulnerability response; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Allowlist Authorized Libraries, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV8, GV9, M1, M2, M3, M4) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 2.1, Safeguard 2.5, Safeguard 4.2; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Pin approved component identity, version or constrained range, source repository, integrity digest and permitted application/environment in lockfiles, artifact repositories, build policy and runtime loading controls where supported.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Static linking and vendoring hide runtime package queries; dynamically generated code and customer plugins need separate trust boundaries.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Build the same application with an approved component, an unexpected transitive dependency, a dependency-confusion name and a modified digest.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 6 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 2.7 · Allowlist Authorized Scripts · IG3 onward

Population and scope: Include shell, PowerShell, Python, JavaScript, office macros, CI/CD definitions, infrastructure-as-code hooks and other interpreted automation wherever scripts can alter enterprise state. Extension and interpreter signature alone do not identify the actual content.
Implementation and owner: Enforce signed scripts, content hashes, controlled repositories, constrained interpreters and approved execution paths according to platform. Separate developer authoring from production execution, protect signing keys, record signer and review, and provide a logged, time-limited operational break-glass channel.
Evidence and negative test: Execute an approved script, a one-byte-modified copy, an inline command, an encoded command and a trusted script from an untrusted path. Verify blocking or containment plus durable logs that preserve content identity and parent process; test key revocation and policy rollback.
Exception and failure boundary: Mutable network shares, generated scripts, notebooks and CI variables can change behavior without changing a filename. Signed malware or a compromised signing key remains allowed unless trust is revoked. Audit-only policies and user-writable allow paths do not pass; necessary unsigned legacy automation needs isolation, owner and retirement date.

PRD implementation register · 84 atomic requirements · 12 dimensions · software_dev, enforcement

O01Outcome and decision. Define the user, business, and risk outcome for Allowlist Authorized Scripts; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 2.7, official Asset Class Software, Security Function Protect, and IG3 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Include shell, PowerShell, Python, JavaScript, office macros, CI/CD definitions, infrastructure-as-code hooks and other interpreted automation wherever scripts can alter enterprise state.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Allowlist Authorized Scripts to its operating object—operating systems, packages, firmware, extensions, container images, dependencies, SaaS applications, and internally built releases—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Allowlist Authorized Scripts, express success as an observable decision over source-to-production software identity, design invariant, component trust, build provenance, test result, deployment state, runtime outcome, and vulnerability response; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Allowlist Authorized Scripts, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV3, GV8, M1, M2, M3, M4) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 2.1, Safeguard 4.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Enforce signed scripts, content hashes, controlled repositories, constrained interpreters and approved execution paths according to platform.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Mutable network shares, generated scripts, notebooks and CI variables can change behavior without changing a filename.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Execute an approved script, a one-byte-modified copy, an inline command, an encoded command and a trusted script from an untrusted path.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 6 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

3.3 Control 3: Data Protection

Control 3 starts with data purpose and ownership, then joins inventory, permissions, lifecycle, cryptography, segmentation, DLP and audit. The control succeeds when a data set keeps the same identity and policy as it moves through primary storage, replicas, exports, providers, backups and AI or analytics paths.

Encryption has several sharply different jobs. Full-disk encryption protects a lost locked endpoint; transport protection secures a hop; storage encryption protects a copy; application-held keys can separate administrators. The cards preserve those threat boundaries instead of merging every encrypted state into one check.

Primary measurement reference: official CAS Control 3; the cards below add an independent implementation boundary to that control.

CIS Safeguard 3.1 · Establish and Maintain a Data Management Process · IG1 onward

Population and scope: The process covers enterprise data through collection, creation, use, sharing, archival and disposal across endpoints, servers, databases, cloud, SaaS, backups, analytics, AI systems and service providers. Legal retention, privacy, security sensitivity and business value may impose different, sometimes conflicting clocks.
Implementation and owner: Assign a data owner and custodian model, sensitivity criteria, handling rules, minimum and maximum retention, disposal methods, approved transfer locations and exception authority. Legal, privacy, security and business owners resolve conflicts; review annually and whenever products, jurisdictions, providers or material data uses change.
Evidence and negative test: Choose representative data types and trace each rule into a real system configuration and lifecycle event. Verify owner acknowledgement, retention and deletion jobs, transfer restrictions and exception decisions; the CAS document-completeness score is only a design check and cannot prove enforcement.
Exception and failure boundary: Unknown data starts at a conservative classification. Litigation hold suspends deletion only for the named scope and has release controls. Provider defaults, immutable backups, ML training copies and derived data require explicit treatment; a policy that says “retain as needed” or “securely delete” has no testable boundary.

PRD implementation register · 96 atomic requirements · 12 dimensions · data_lifecycle, governance · expanded complexity

O01Outcome and decision. Define the user, business, and risk outcome for Establish and Maintain a Data Management Process; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 3.1, official Asset Class Data, Security Function Govern, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The process covers enterprise data through collection, creation, use, sharing, archival and disposal across endpoints, servers, databases, cloud, SaaS, backups, analytics, AI systems and service providers.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Establish and Maintain a Data Management Process to its operating object—sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Establish and Maintain a Data Management Process, express success as an observable decision over data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Establish and Maintain a Data Management Process, express success as an observable decision over a documented decision system with policy, process, procedure, accountable owner, approval, and review; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For the expanded Establish and Maintain a Data Management Process scope, resolve conflicts among security, safety, privacy, legal, availability, customer, and operational objectives through an explicit risk decision.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P05Population and applicability. Resolve applicability across unknown classification, encrypted or tokenized copies, cross-region replicas, immutable backups, derived data, litigation holds, and provider deletion limits; each edge receives an evidenced in-scope, out-of-scope, unknown, or time-bounded exception result.

P06Population and applicability. Include unstructured and derived data, logs, caches, backups, exports, client-side copies, cross-region processing, AI corpora, holds, and provider residues in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

P07Population and applicability. Include missing policy clauses, conflicting authorities, local deviations, obsolete documentation, and decisions made outside the governed workflow in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W05Ownership and approval. Bind data owners and custodians, product teams, privacy, legal, security, records management, and providers to a RACI for the Safeguard and name the authority that resolves conflicting source or risk decisions.

W06Ownership and approval. Name who may transition created/collected → classified → approved use and flow → retained/held → disposed with verification, who approves the transition, who supplies evidence, and who independently reviews it.

W07Ownership and approval. Name who may transition draft → reviewed → approved → effective → exception/withdrawn → superseded, who approves the transition, who supplies evidence, and who independently reviews it.

W08Ownership and approval. Model delegated authority, quorum or dual approval where warranted, escalation deadlines, provider handoffs, conflict resolution, and executive risk acceptance.

D03Data contract and identity. Map the pinned CAS variable set (GV10, GV11, GV13, GV14, GV15, GV16, M1, M2, M3, M4, M5, M6) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D05Data contract and identity. Use the data inventory, classification, ownership, and lifecycle authority as the governed current-state record; persist identity, owner, provenance, prior/new state, reason, actor, time, and exception link.

D06Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle created/collected → classified → approved use and flow → retained/held → disposed with verification.

D07Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle draft → reviewed → approved → effective → exception/withdrawn → superseded.

D08Data contract and identity. Version schemas and state transitions with migration, backfill, deduplication, lineage, historical denominator, deletion, and rollback semantics.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I05Dependencies and integrations. Reconcile data catalogs, schemas, DLP discovery, cloud/SaaS APIs, owner attestations, flow records, backup catalogs, and legal/privacy schedules and expose source-specific health, latency, confidence, omissions, and conflict resolution.

I06Dependencies and integrations. Require every connector carrying data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state to preserve tenant, object identity, source time, collection time, completeness, and failure status.

I07Dependencies and integrations. Require every connector carrying a documented decision system with policy, process, procedure, accountable owner, approval, and review to preserve tenant, object identity, source time, collection time, completeness, and failure status.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Assign a data owner and custodian model, sensitivity criteria, handling rules, minimum and maximum retention, disposal methods, approved transfer locations and exception authority.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C05Control flow and enforcement. Implement the state transition in the data inventory, classification, ownership, and lifecycle authority and preserve the exact operating control point, policy or procedure version, result, and downstream update.

C06Control flow and enforcement. Implement the explicit state machine created/collected → classified → approved use and flow → retained/held → disposed with verification; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

C07Control flow and enforcement. Implement the explicit state machine draft → reviewed → approved → effective → exception/withdrawn → superseded; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

T01Timing and lifecycle. Preserve the official cadence terms found in the pinned description (annually); define faster local SLOs where asset change, exposure, safety, or threat consequence requires them.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T05Timing and lifecycle. Set freshness and action SLOs from the rate of change in sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows; source age, queue age, exception age, and closure age remain separate clocks.

T06Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for created/collected → classified → approved use and flow → retained/held → disposed with verification; alert before each deadline becomes overdue.

T07Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for draft → reviewed → approved → effective → exception/withdrawn → superseded; alert before each deadline becomes overdue.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Unknown data starts at a conservative classification.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X05Exceptions and failure modes. Treat unknown classification, encrypted or tokenized copies, cross-region replicas, immutable backups, derived data, litigation holds, and provider deletion limits as designed non-happy paths with an owner, compensating control, expiry, safety or business constraint, and retest.

X06Exceptions and failure modes. Treat unstructured and derived data, logs, caches, backups, exports, client-side copies, cross-region processing, AI corpora, holds, and provider residues as named failure or exception paths with an owner, compensating control, expiry, and retest.

X07Exceptions and failure modes. Treat missing policy clauses, conflicting authorities, local deviations, obsolete documentation, and decisions made outside the governed workflow as named failure or exception paths with an owner, compensating control, expiry, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Choose representative data types and trace each rule into a real system configuration and lifecycle event.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 12 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E05Evidence and metrics. Derive coverage and effectiveness from the data inventory, classification, ownership, and lifecycle authority plus independent source receipts; report unknown, stale, conflicting, failed, and excepted objects separately.

E06Evidence and metrics. Publish known, unknown, classified, ownerless, over-retained, prematurely deleted, unapproved copy, blocked flow, held, and disposal-verified data sets with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

E07Evidence and metrics. Publish clause coverage, owner and reviewer completeness, approval age, triggered reviews, deviations, overdue actions, and superseded versions still in use with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S05Security, privacy, and resilience. Protect write and approval authority over the data inventory, classification, ownership, and lifecycle authority; monitor privileged changes, exports, deletions, source disablement, and recovery.

S06Security, privacy, and resilience. Restrict authority to change created/collected → classified → approved use and flow → retained/held → disposed with verification; log privileged changes, protect evidence history, and test administrative recovery.

S07Security, privacy, and resilience. Restrict authority to change draft → reviewed → approved → effective → exception/withdrawn → superseded; log privileged changes, protect evidence history, and test administrative recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V05Verification and adversarial tests. Exercise approved and unapproved copies, allowed and denied readers, retention boundaries, deletion verification, key loss, and cross-boundary transfers through representative platforms and verify business behavior, control decision, telemetry, case workflow, rollback, and final state.

V06Verification and adversarial tests. Run the positive control an approved data set following its declared use, access, transfer, retention, and disposal path; exercise negative, stale, duplicate, bypass, and outage controls including an unknown or misclassified copy, forbidden reader or flow, early deletion, expired retention, failed disposal, and provider residue.

V07Verification and adversarial tests. Run the positive control an approved current process used for a representative decision; exercise negative, stale, duplicate, bypass, and outage controls including an obsolete version, missing approver, undocumented deviation, overdue review, and bypassed workflow.

R05Operations, change, and closure. Re-run reconciliation and affected tests whenever data catalogs, schemas, DLP discovery, cloud/SaaS APIs, owner attestations, flow records, backup catalogs, and legal/privacy schedules change ownership, schema, coverage, provider, policy, or platform version.

R06Operations, change, and closure. Use known, unknown, classified, ownerless, over-retained, prematurely deleted, unapproved copy, blocked flow, held, and disposal-verified data sets to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

R07Operations, change, and closure. Use clause coverage, owner and reviewer completeness, approval age, triggered reviews, deviations, overdue actions, and superseded versions still in use to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

CIS Safeguard 3.2 · Establish and Maintain a Data Inventory · IG1 onward

Population and scope: Inventory sensitive data sets and stores, their owners, purposes, classification, systems, regions, flows, processors, retention and deletion state; use a stable data-set or processing-activity identity as the counting unit, with individual rows and files retained as subordinate evidence. Include replicas, caches, logs, backups, test copies, exports and AI retrieval or training corpora.
Implementation and owner: Combine owner attestations with database/catalog scans, cloud and SaaS APIs, DLP discovery, schemas and data-flow records. Link each item to the asset/service inventory and management process, prioritize sensitive data, and update on creation or movement with at least annual reconciliation.
Evidence and negative test: Seed labelled sensitive data into an approved store and an unapproved copy, then prove discovery, correct classification, owner routing and cleanup. Measure complete mappings over all discovered in-scope data sets, with unknown and partial mappings separate; sample inventory records back to live stores and vice versa.
Exception and failure boundary: Encrypted or tokenized data remains in scope because keys, re-identification or use may preserve sensitivity. Unstructured, ephemeral, client-side, cross-account and provider-held copies need tailored discovery. The current CAS wrongly tests the item-count measure for age instead of its month measure; implement freshness independently.

PRD implementation register · 96 atomic requirements · 12 dimensions · data_lifecycle, inventory · expanded complexity

O01Outcome and decision. Define the user, business, and risk outcome for Establish and Maintain a Data Inventory; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 3.2, official Asset Class Data, Security Function Identify, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Inventory sensitive data sets and stores, their owners, purposes, classification, systems, regions, flows, processors, retention and deletion state; use a stable data-set or processing-activity identity as the counting unit, with individual rows and files retained as subordinate evidence.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Establish and Maintain a Data Inventory to its operating object—sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Establish and Maintain a Data Inventory, express success as an observable decision over data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Establish and Maintain a Data Inventory, express success as an observable decision over observed, approved, unapproved, ownerless, stale, duplicate, and retired object identity; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For the expanded Establish and Maintain a Data Inventory scope, resolve conflicts among security, safety, privacy, legal, availability, customer, and operational objectives through an explicit risk decision.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W08Ownership and approval. Model delegated authority, quorum or dual approval where warranted, escalation deadlines, provider handoffs, conflict resolution, and executive risk acceptance.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV11, GV12, M1, M2, M3, M4, M5, M6, M7, M8, M9) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D08Data contract and identity. Version schemas and state transitions with migration, backfill, deduplication, lineage, historical denominator, deletion, and rollback semantics.

I01Dependencies and integrations. Record prerequisite state for Safeguard 1.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Combine owner attestations with database/catalog scans, cloud and SaaS APIs, DLP discovery, schemas and data-flow records.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Encrypted or tokenized data remains in scope because keys, re-identification or use may preserve sensitivity.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Seed labelled sensitive data into an approved store and an unapproved copy, then prove discovery, correct classification, owner routing and cleanup.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 12 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 3.3 · Configure Data Access Control Lists · IG1 onward

Population and scope: The access population includes human, service, workload, support and provider identities reaching sensitive data through files, databases, APIs, applications, analytics, backups and administrative planes. A front-end role leaves enforcement on storage, export and emergency paths unverified.
Implementation and owner: Translate owner-approved need-to-know into group, role, ACL, row/column, object and key policies at the authoritative control points. Remove direct grants, separate administration from data use, review inherited and public access, and make joiner/mover/leaver plus emergency access update every layer.
Evidence and negative test: For sampled data sets, enumerate effective permissions and reconcile them to approved identities. Test an allowed user, a denied user, a stale group member, a service identity and an administrator through normal and alternate paths; retain policy, evaluator, decision and data-set identity.
Exception and failure boundary: Counts of mapped data and account types are not interchangeable, despite the CAS formula. Shared accounts and ownerless data cannot pass. Encryption without separate key authorization does not repair an open ACL; database owners, cloud support and backup operators require explicit, logged boundaries and expiring exceptions.

PRD implementation register · 96 atomic requirements · 12 dimensions · data_lifecycle, identity, enforcement

O01Outcome and decision. Define the user, business, and risk outcome for Configure Data Access Control Lists; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 3.3, official Asset Class Data, Security Function Protect, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The access population includes human, service, workload, support and provider identities reaching sensitive data through files, databases, APIs, applications, analytics, backups and administrative planes.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Configure Data Access Control Lists to its operating object—sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Configure Data Access Control Lists, express success as an observable decision over data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Configure Data Access Control Lists, express success as an observable decision over effective identity, authentication, authorization, privilege, session, and revocation state across every access path; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For Configure Data Access Control Lists, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P07Population and applicability. Include shared and service identities, nested groups, direct grants, cached sessions, federation gaps, recovery channels, API keys, emergency access, and provider support in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

P08Population and applicability. Include audit-only mode, unsupported platforms, local overrides, race conditions, cached state, alternate paths, fail-open behavior, and emergency bypass in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W07Ownership and approval. Name who may transition requested → approved → provisioned → exercised → reviewed → changed/revoked → session and token invalidated, who approves the transition, who supplies evidence, and who independently reviews it.

W08Ownership and approval. Name who may transition observe → evaluate → decide → enforce → verify outcome → rollback/close, who approves the transition, who supplies evidence, and who independently reviews it.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV3, GV12, GV13, GV14, GV17, GV22, M1, M2, M3, M4, M5, and 3 more) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D07Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle requested → approved → provisioned → exercised → reviewed → changed/revoked → session and token invalidated.

D08Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle observe → evaluate → decide → enforce → verify outcome → rollback/close.

I01Dependencies and integrations. Record prerequisite state for Safeguard 3.2, Safeguard 4.1, Safeguard 5.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I07Dependencies and integrations. Require every connector carrying effective identity, authentication, authorization, privilege, session, and revocation state across every access path to preserve tenant, object identity, source time, collection time, completeness, and failure status.

I08Dependencies and integrations. Require every connector carrying an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point to preserve tenant, object identity, source time, collection time, completeness, and failure status.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Translate owner-approved need-to-know into group, role, ACL, row/column, object and key policies at the authoritative control points.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C07Control flow and enforcement. Implement the explicit state machine requested → approved → provisioned → exercised → reviewed → changed/revoked → session and token invalidated; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

C08Control flow and enforcement. Implement the explicit state machine observe → evaluate → decide → enforce → verify outcome → rollback/close; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T07Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for requested → approved → provisioned → exercised → reviewed → changed/revoked → session and token invalidated; alert before each deadline becomes overdue.

T08Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for observe → evaluate → decide → enforce → verify outcome → rollback/close; alert before each deadline becomes overdue.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Counts of mapped data and account types are not interchangeable, despite the CAS formula.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X07Exceptions and failure modes. Treat shared and service identities, nested groups, direct grants, cached sessions, federation gaps, recovery channels, API keys, emergency access, and provider support as named failure or exception paths with an owner, compensating control, expiry, and retest.

X08Exceptions and failure modes. Treat audit-only mode, unsupported platforms, local overrides, race conditions, cached state, alternate paths, fail-open behavior, and emergency bypass as named failure or exception paths with an owner, compensating control, expiry, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “For sampled data sets, enumerate effective permissions and reconcile them to approved identities.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 15 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E07Evidence and metrics. Publish requested, approved, effective, excessive, orphaned, stale, emergency, revoked-but-active, and independently reviewed rights with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

E08Evidence and metrics. Publish eligible, enforcing, audit-only, failed, bypassed, excepted, rolled-back, and outcome-verified populations with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S07Security, privacy, and resilience. Restrict authority to change requested → approved → provisioned → exercised → reviewed → changed/revoked → session and token invalidated; log privileged changes, protect evidence history, and test administrative recovery.

S08Security, privacy, and resilience. Restrict authority to change observe → evaluate → decide → enforce → verify outcome → rollback/close; log privileged changes, protect evidence history, and test administrative recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V07Verification and adversarial tests. Run the positive control an authorized identity using the required assurance and least privilege; exercise negative, stale, duplicate, bypass, and outage controls including an unauthorized identity, missing factor, stale session, direct grant, inherited excess, revoked token, and recovery bypass.

V08Verification and adversarial tests. Run the positive control an approved business action that completes through the enforced path; exercise negative, stale, duplicate, bypass, and outage controls including a prohibited action, alternate path, local override, stale policy, control outage, emergency bypass, and rollback failure.

R07Operations, change, and closure. Use requested, approved, effective, excessive, orphaned, stale, emergency, revoked-but-active, and independently reviewed rights to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

R08Operations, change, and closure. Use eligible, enforcing, audit-only, failed, bypassed, excepted, rolled-back, and outcome-verified populations to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

CIS Safeguard 3.4 · Enforce Data Retention · IG1 onward

Population and scope: The boundary includes primary stores, replicas, queues, logs, search indexes, endpoints, exports, backups and provider copies. Each data category needs both minimum and maximum periods, with event-based triggers where appropriate; the longest system default must not silently become policy.
Implementation and owner: Map rules to deletion, archival, legal-hold and backup-expiry jobs owned by data and platform teams. Store the triggering event, jurisdiction, policy version and hold state with the record or data set; monitor failed and delayed jobs and propagate deletion downstream.
Evidence and negative test: Create test records with short expiry and hold states, advance time, then verify preservation before minimum, deletion after maximum, replica/index/cache propagation and auditable hold release. Measure eligible data sets whose live configurations and observed outcomes meet policy, not merely those with a written duration.
Exception and failure boundary: Immutable backups may defer physical deletion until media expiry, so access isolation and documented maximum cycle define the compensating boundary. Regulatory conflicts are resolved per data set and jurisdiction. Unknown creation dates, orphan exports and indefinite “archive” tiers are failures until bounded.

PRD implementation register · 84 atomic requirements · 12 dimensions · data_lifecycle, enforcement

O01Outcome and decision. Define the user, business, and risk outcome for Enforce Data Retention; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 3.4, official Asset Class Data, Security Function Protect, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The boundary includes primary stores, replicas, queues, logs, search indexes, endpoints, exports, backups and provider copies.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Enforce Data Retention to its operating object—sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Enforce Data Retention, express success as an observable decision over data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Enforce Data Retention, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV11, GV12, GV15, GV17, M1, M2, M3, M4, M5, M6) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 3.1, Safeguard 3.2; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Map rules to deletion, archival, legal-hold and backup-expiry jobs owned by data and platform teams.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Immutable backups may defer physical deletion until media expiry, so access isolation and documented maximum cycle define the compensating boundary.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Create test records with short expiry and hold states, advance time, then verify preservation before minimum, deletion after maximum, replica/index/cache propagation and auditable hold release.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 10 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 3.5 · Securely Dispose of Data · IG1 onward

Population and scope: Cover logical records, files, cryptographic keys, removable media, failed drives, cloud volumes, snapshots, backups, paper and provider-held data. Disposal means the information cannot be feasibly recovered under the declared threat model, not that a UI object disappeared.
Implementation and owner: Select deletion, cryptographic erasure, overwrite, media destruction or provider workflow according to sensitivity and medium. Separate authorization from execution, maintain chain of custody, verify destruction vendors and ensure replicas, indexes, keys and retention locks are addressed.
Evidence and negative test: Run a controlled deletion through each disposal path and verify storage, backup, search, API and recovery behavior after the stated completion time. Inspect destruction certificates against asset/media identifiers and sample sanitized media with an approved recovery test.
Exception and failure boundary: Flash wear levelling, snapshots, immutable storage and SaaS deletion windows limit immediate erasure. Legal hold blocks only the named records. Key destruction counts only when no plaintext or alternate key remains. Reconcile the disposed population to vendor certification before accepting completion.

PRD implementation register · 72 atomic requirements · 12 dimensions · data_lifecycle

O01Outcome and decision. Define the user, business, and risk outcome for Securely Dispose of Data; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 3.5, official Asset Class Data, Security Function Protect, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Cover logical records, files, cryptographic keys, removable media, failed drives, cloud volumes, snapshots, backups, paper and provider-held data.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Securely Dispose of Data to its operating object—sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Securely Dispose of Data, express success as an observable decision over data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV11, GV12, GV16, GV17, M1, M2, M3, M4, M5, M6) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 3.1, Safeguard 3.2; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Select deletion, cryptographic erasure, overwrite, media destruction or provider workflow according to sensitivity and medium.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Flash wear levelling, snapshots, immutable storage and SaaS deletion windows limit immediate erasure.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Run a controlled deletion through each disposal path and verify storage, backup, search, API and recovery behavior after the stated completion time.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 10 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 3.6 · Encrypt Data on End-User Devices · IG1 onward

Population and scope: Include enterprise data on laptops, desktops and managed mobile devices, plus local caches, swap, hibernation, removable storage and offline profiles. Full-disk encryption mainly protects powered-off or locked loss; it does not protect an authenticated session, synchronized cloud copy or attacker with keys.
Implementation and owner: Enforce platform-native encryption through MDM/endpoint configuration, escrow recovery material separately, bind keys to hardware and strong authentication, and block access when encryption is absent, suspended or recovery state is unhealthy. Define coverage for BYOD using container or application-level controls.
Evidence and negative test: Read actual encryption and key-protection state, not installed software. Test a compliant device, encryption suspension, recovery-key use, lost-device lock and a disk removed from the device; measure healthy encrypted eligible devices over all eligible devices, with last check time and exclusions.
Exception and failure boundary: A device reporting “encrypted” while auto-unlocked with an exposed key has weaker protection. Servers and databases belong under 3.11; removable media under 3.9. Unmanaged BYOD that cannot attest protection should receive browser-only or restricted data access, not an unverified exception.

PRD implementation register · 84 atomic requirements · 12 dimensions · data_lifecycle, encryption

O01Outcome and decision. Define the user, business, and risk outcome for Encrypt Data on End-User Devices; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 3.6, official Asset Class Data, Security Function Protect, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Include enterprise data on laptops, desktops and managed mobile devices, plus local caches, swap, hibernation, removable storage and offline profiles.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Encrypt Data on End-User Devices to its operating object—sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Encrypt Data on End-User Devices, express success as an observable decision over data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Encrypt Data on End-User Devices, express success as an observable decision over plaintext exposure against a named loss, theft, interception, storage-administrator, provider, or cross-tenant threat; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P07Population and applicability. Include unsupported endpoints, boot and unlocked state, alternate protocols, downgrade, copied data, key export, shared keys, backups, logs, and recovery in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W07Ownership and approval. Name who may transition data identified → policy selected → keys provisioned → encryption enforced → use/decrypt authorized → keys rotated/revoked → data retired, who approves the transition, who supplies evidence, and who independently reviews it.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV3, GV5, M1, M2, M3, M4, M5) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D07Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle data identified → policy selected → keys provisioned → encryption enforced → use/decrypt authorized → keys rotated/revoked → data retired.

I01Dependencies and integrations. Record prerequisite state for Safeguard 1.1, Safeguard 2.1, Safeguard 4.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I07Dependencies and integrations. Require every connector carrying plaintext exposure against a named loss, theft, interception, storage-administrator, provider, or cross-tenant threat to preserve tenant, object identity, source time, collection time, completeness, and failure status.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Enforce platform-native encryption through MDM/endpoint configuration, escrow recovery material separately, bind keys to hardware and strong authentication, and block access when encryption is absent, suspended or recovery state is unhealthy.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C07Control flow and enforcement. Implement the explicit state machine data identified → policy selected → keys provisioned → encryption enforced → use/decrypt authorized → keys rotated/revoked → data retired; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T07Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for data identified → policy selected → keys provisioned → encryption enforced → use/decrypt authorized → keys rotated/revoked → data retired; alert before each deadline becomes overdue.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “A device reporting “encrypted” while auto-unlocked with an exposed key has weaker protection.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X07Exceptions and failure modes. Treat unsupported endpoints, boot and unlocked state, alternate protocols, downgrade, copied data, key export, shared keys, backups, logs, and recovery as named failure or exception paths with an owner, compensating control, expiry, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Read actual encryption and key-protection state, not installed software.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 8 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E07Evidence and metrics. Publish eligible, protected, weak/legacy, keyless, shared-key, decryptable-by-unintended-party, exception, and recovery-tested objects with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S07Security, privacy, and resilience. Restrict authority to change data identified → policy selected → keys provisioned → encryption enforced → use/decrypt authorized → keys rotated/revoked → data retired; log privileged changes, protect evidence history, and test administrative recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V07Verification and adversarial tests. Run the positive control authorized encryption, decryption, rotation, and recovery for representative data; exercise negative, stale, duplicate, bypass, and outage controls including plaintext path, protocol downgrade, lost device, copied storage, unauthorized principal, revoked key, failed rotation, and unavailable recovery key.

R07Operations, change, and closure. Use eligible, protected, weak/legacy, keyless, shared-key, decryptable-by-unintended-party, exception, and recovery-tested objects to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

CIS Safeguard 3.7 · Establish and Maintain a Data Classification Scheme · IG2 onward

Population and scope: Define a small, ordered set of classifications tied to business impact and handling, covering confidentiality and any integrity or availability tiers the enterprise needs. Labels must apply consistently to structured, unstructured, derived and aggregated data; one harmless field can become sensitive in combination.
Implementation and owner: Publish decision rules, examples, default class, owner and reclassification process, then encode labels in catalogs, repositories, documents and policy engines. Resolve regulatory labels to the enterprise scheme without erasing their distinct obligations; review annually and on material data/use change.
Evidence and negative test: Give independent reviewers representative and ambiguous samples and measure agreement with the owner-approved answer. Trace each class to access, transfer, encryption, retention and disposal controls; seed a mislabelled item and verify detection and correction.
Exception and failure boundary: “Confidential” with no handling consequence is decorative. Automated classifiers have false positives and negatives and require sampling. Public data can still need integrity protection; declassification requires owner evidence, propagation to copies and confirmation that legal or contractual restrictions ended.

PRD implementation register · 96 atomic requirements · 12 dimensions · data_lifecycle, inventory, governance

O01Outcome and decision. Define the user, business, and risk outcome for Establish and Maintain a Data Classification Scheme; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 3.7, official Asset Class Data, Security Function Identify, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Define a small, ordered set of classifications tied to business impact and handling, covering confidentiality and any integrity or availability tiers the enterprise needs.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Establish and Maintain a Data Classification Scheme to its operating object—sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Establish and Maintain a Data Classification Scheme, express success as an observable decision over data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Establish and Maintain a Data Classification Scheme, express success as an observable decision over observed, approved, unapproved, ownerless, stale, duplicate, and retired object identity; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For Establish and Maintain a Data Classification Scheme, express success as an observable decision over a documented decision system with policy, process, procedure, accountable owner, approval, and review; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P08Population and applicability. Include missing policy clauses, conflicting authorities, local deviations, obsolete documentation, and decisions made outside the governed workflow in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W08Ownership and approval. Name who may transition draft → reviewed → approved → effective → exception/withdrawn → superseded, who approves the transition, who supplies evidence, and who independently reviews it.

D03Data contract and identity. Map the pinned CAS variable set (GV12, GV17, M1, M2, M3, M4, M5, M6, M7, M8) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D08Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle draft → reviewed → approved → effective → exception/withdrawn → superseded.

I01Dependencies and integrations. Record prerequisite state for Safeguard 3.1, Safeguard 3.2; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I08Dependencies and integrations. Require every connector carrying a documented decision system with policy, process, procedure, accountable owner, approval, and review to preserve tenant, object identity, source time, collection time, completeness, and failure status.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Publish decision rules, examples, default class, owner and reclassification process, then encode labels in catalogs, repositories, documents and policy engines.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C08Control flow and enforcement. Implement the explicit state machine draft → reviewed → approved → effective → exception/withdrawn → superseded; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T08Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for draft → reviewed → approved → effective → exception/withdrawn → superseded; alert before each deadline becomes overdue.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: ““Confidential” with no handling consequence is decorative.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X08Exceptions and failure modes. Treat missing policy clauses, conflicting authorities, local deviations, obsolete documentation, and decisions made outside the governed workflow as named failure or exception paths with an owner, compensating control, expiry, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Give independent reviewers representative and ambiguous samples and measure agreement with the owner-approved answer.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 10 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E08Evidence and metrics. Publish clause coverage, owner and reviewer completeness, approval age, triggered reviews, deviations, overdue actions, and superseded versions still in use with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S08Security, privacy, and resilience. Restrict authority to change draft → reviewed → approved → effective → exception/withdrawn → superseded; log privileged changes, protect evidence history, and test administrative recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V08Verification and adversarial tests. Run the positive control an approved current process used for a representative decision; exercise negative, stale, duplicate, bypass, and outage controls including an obsolete version, missing approver, undocumented deviation, overdue review, and bypassed workflow.

R08Operations, change, and closure. Use clause coverage, owner and reviewer completeness, approval age, triggered reviews, deviations, overdue actions, and superseded versions still in use to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

CIS Safeguard 3.8 · Document Data Flows · IG2 onward

Population and scope: Document where each material data set originates, moves, is transformed, crosses trust or jurisdiction boundaries and terminates, including APIs, queues, batch exports, email, analytics, backups, telemetry, SaaS/providers and AI retrieval/tool paths. Architecture boxes without data identity, purpose and direction are insufficient.
Implementation and owner: Generate flows from design records, service catalogs, gateway/mesh/cloud logs and owner interviews; bind source, destination, protocol, data class, purpose, controller/processor, region, protection and retention. Review annually and trigger change review from new integrations, routes, providers or processing purposes.
Evidence and negative test: Select high-risk flows and trace documentation against observed network/application events in both directions. Add a test integration and verify inventory/change workflow; measure documented material flows over flows found by independent observation, with dormant, emergency and shadow paths called out.
Exception and failure boundary: Encrypted traffic still has a flow and destination. Serverless callbacks, browser-to-third-party transfers, support exports and vendor subprocessors are commonly missed. A zero observed count may mean telemetry failure; unknown flows are investigated, not excluded to improve coverage.

PRD implementation register · 96 atomic requirements · 12 dimensions · data_lifecycle, inventory · expanded complexity

O01Outcome and decision. Define the user, business, and risk outcome for Document Data Flows; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 3.8, official Asset Class Data, Security Function Identify, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Document where each material data set originates, moves, is transformed, crosses trust or jurisdiction boundaries and terminates, including APIs, queues, batch exports, email, analytics, backups, telemetry, SaaS/providers and AI retrieval/tool paths.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Document Data Flows to its operating object—sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Document Data Flows, express success as an observable decision over data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Document Data Flows, express success as an observable decision over observed, approved, unapproved, ownerless, stale, duplicate, and retired object identity; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For the expanded Document Data Flows scope, resolve conflicts among security, safety, privacy, legal, availability, customer, and operational objectives through an explicit risk decision.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W08Ownership and approval. Model delegated authority, quorum or dual approval where warranted, escalation deadlines, provider handoffs, conflict resolution, and executive risk acceptance.

D03Data contract and identity. Map the pinned CAS variable set (GV12, M1, M2, M3, M4, M5) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D08Data contract and identity. Version schemas and state transitions with migration, backfill, deduplication, lineage, historical denominator, deletion, and rollback semantics.

I01Dependencies and integrations. Record prerequisite state for Safeguard 3.1, Safeguard 3.2; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Generate flows from design records, service catalogs, gateway/mesh/cloud logs and owner interviews; bind source, destination, protocol, data class, purpose, controller/processor, region, protection and retention.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Encrypted traffic still has a flow and destination.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Select high-risk flows and trace documentation against observed network/application events in both directions.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 6 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 3.9 · Encrypt Data on Removable Media · IG2 onward

Population and scope: The population includes authorized USB storage, external drives, memory cards and other removable media carrying enterprise data, plus endpoints allowed to mount them. Phones used only as managed endpoints follow mobile policy; device transfer modes and virtual media may create equivalent paths.
Implementation and owner: Default-deny removable storage, then issue managed encrypted media with hardware or software keys, strong authentication, inventory and custody. Configure endpoints to write only through approved encryption, block unencrypted formats and define secure exchange with systems that cannot support the control.
Evidence and negative test: Insert approved encrypted, approved-but-unlocked, and unapproved/plain media into representative systems; verify mount/write decisions, encryption state, logs, key recovery and data readability off-device. Measure enforcing eligible endpoints and encrypted issued media separately.
Exception and failure boundary: Installed host encryption leaves individual media writes unverified. OT/service workflows may need broker stations, one-way transfer and malware scanning. Lost keys, shared passwords, exported plaintext and vendor media need incident or exception handling with an expiry.

PRD implementation register · 84 atomic requirements · 12 dimensions · data_lifecycle, encryption

O01Outcome and decision. Define the user, business, and risk outcome for Encrypt Data on Removable Media; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 3.9, official Asset Class Data, Security Function Protect, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The population includes authorized USB storage, external drives, memory cards and other removable media carrying enterprise data, plus endpoints allowed to mount them.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Encrypt Data on Removable Media to its operating object—sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Encrypt Data on Removable Media, express success as an observable decision over data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Encrypt Data on Removable Media, express success as an observable decision over plaintext exposure against a named loss, theft, interception, storage-administrator, provider, or cross-tenant threat; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Default-deny removable storage, then issue managed encrypted media with hardware or software keys, strong authentication, inventory and custody.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Installed host encryption leaves individual media writes unverified.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Insert approved encrypted, approved-but-unlocked, and unapproved/plain media into representative systems; verify mount/write decisions, encryption state, logs, key recovery and data readability off-device.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 8 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 3.10 · Encrypt Sensitive Data in Transit · IG2 onward

Population and scope: Include sensitive data crossing process, host, network, account, provider and physical trust boundaries through web, API, messaging, database, file transfer, email, remote administration and service-to-service traffic. “Internal network” is not an automatic trusted exemption.
Implementation and owner: Define approved protocols, versions, cipher/key and certificate trust for each flow; enforce at clients and services, disable downgrade and plaintext listeners, authenticate both ends where risk requires, and manage private keys, renewal and revocation. Application owners own endpoints; platform teams supply guardrails.
Evidence and negative test: Probe every representative endpoint and alternate route for plaintext, downgrade, expired/untrusted certificates, hostname failure and mutual-auth bypass. Capture negotiated protection and application authorization; send a canary through expected flows and verify that proxies, queues and providers do not expose a plaintext hop.
Exception and failure boundary: TLS termination changes the boundary: traffic behind the terminator needs a new decision. Encryption does not validate recipient authorization or stop endpoint logging. Legacy devices require an isolated gateway and retirement date; “provider encrypts” needs tenant-specific configuration and evidence.

PRD implementation register · 84 atomic requirements · 12 dimensions · data_lifecycle, encryption

O01Outcome and decision. Define the user, business, and risk outcome for Encrypt Sensitive Data in Transit; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 3.10, official Asset Class Data, Security Function Protect, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Include sensitive data crossing process, host, network, account, provider and physical trust boundaries through web, API, messaging, database, file transfer, email, remote administration and service-to-service traffic.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Encrypt Sensitive Data in Transit to its operating object—sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Encrypt Sensitive Data in Transit, express success as an observable decision over data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Encrypt Sensitive Data in Transit, express success as an observable decision over plaintext exposure against a named loss, theft, interception, storage-administrator, provider, or cross-tenant threat; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV3, GV12, M1, M2, M3) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 3.2, Safeguard 4.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Define approved protocols, versions, cipher/key and certificate trust for each flow; enforce at clients and services, disable downgrade and plaintext listeners, authenticate both ends where risk requires, and manage private keys, renewal and revocation.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “TLS termination changes the boundary: traffic behind the terminator needs a new decision.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Probe every representative endpoint and alternate route for plaintext, downgrade, expired/untrusted certificates, hostname failure and mutual-auth bypass.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 5 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 3.11 · Encrypt Sensitive Data at Rest · IG2 onward

Population and scope: Cover sensitive data in databases, object/block/file stores, application state, snapshots, replicas, search indexes, caches and backups on servers and providers. Storage-layer encryption meets the CIS minimum, while the threat model decides whether provider/admin separation or application-level keys are also required.
Implementation and owner: Enable encryption at each storage service, separate key administration from data administration where needed, set rotation/revocation and recovery, restrict plaintext exports, and bind key policy to data classification and tenant/account. Record which layer protects which copy.
Evidence and negative test: Inspect live storage and key policies, then test authorized read, unauthorized identity, direct-media or snapshot access, key disablement and restore. Measure encrypted in-scope stores over discovered stores and separately report keys controlled by the same administrator.
Exception and failure boundary: The current CAS inputs and M3/M4/M5 references are internally inconsistent; do not automate them verbatim. Server-side encryption with a provider-owned key protects lost media but may not constrain provider or tenant admins. Hashing, masking and tokenization are different controls and must preserve re-identification boundaries.

PRD implementation register · 84 atomic requirements · 12 dimensions · data_lifecycle, encryption

O01Outcome and decision. Define the user, business, and risk outcome for Encrypt Sensitive Data at Rest; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 3.11, official Asset Class Data, Security Function Protect, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Cover sensitive data in databases, object/block/file stores, application state, snapshots, replicas, search indexes, caches and backups on servers and providers.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Encrypt Sensitive Data at Rest to its operating object—sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Encrypt Sensitive Data at Rest, express success as an observable decision over data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Encrypt Sensitive Data at Rest, express success as an observable decision over plaintext exposure against a named loss, theft, interception, storage-administrator, provider, or cross-tenant threat; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV4, GV5, GV12, GV19, M1, M2, M3, M4, M5) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 1.1, Safeguard 2.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Enable encryption at each storage service, separate key administration from data administration where needed, set rotation/revocation and recovery, restrict plaintext exports, and bind key policy to data classification and tenant/account.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “The current CAS inputs and M3/M4/M5 references are internally inconsistent; do not automate them verbatim.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Inspect live storage and key policies, then test authorized read, unauthorized identity, direct-media or snapshot access, key disablement and restore.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 10 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 3.12 · Segment Data Processing and Storage Based on Sensitivity · IG2 onward

Population and scope: The boundary follows data and workloads across network segments, cloud accounts/projects, clusters, databases, analytics and administration. A system inherits the highest sensitivity it can access unless a verified isolation mechanism prevents lower-trust components from crossing the boundary.
Implementation and owner: Place high-sensitivity workloads in dedicated trust zones with explicit identity, network, storage and management-plane policy; restrict ingress, egress, replication and operator paths. Use architecture and data-flow records to drive placement and change admission, not VLAN names alone.
Evidence and negative test: Attempt access from lower-trust workloads, identities, networks and management planes; verify denial and alerting while approved flows still work. Trace every sensitive-data location to a permitted zone and every permitted zone back to an owner and data purpose.
Exception and failure boundary: Shared control planes, CI/CD, backup systems, observability, jump hosts and keys can bridge otherwise separate networks. Encryption alone does not create segmentation. Multi-tenant SaaS needs contractual and technical tenant-isolation evidence; an exception states the exact bridge, filters, monitoring and closure date.

PRD implementation register · 96 atomic requirements · 12 dimensions · data_lifecycle, enforcement, governance

O01Outcome and decision. Define the user, business, and risk outcome for Segment Data Processing and Storage Based on Sensitivity; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 3.12, official Asset Class Data, Security Function Protect, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The boundary follows data and workloads across network segments, cloud accounts/projects, clusters, databases, analytics and administration.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Segment Data Processing and Storage Based on Sensitivity to its operating object—sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Segment Data Processing and Storage Based on Sensitivity, express success as an observable decision over data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Segment Data Processing and Storage Based on Sensitivity, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For Segment Data Processing and Storage Based on Sensitivity, express success as an observable decision over a documented decision system with policy, process, procedure, accountable owner, approval, and review; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV4, GV12, GV18, M1, M2, M3) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 3.2, Safeguard 12.4; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Place high-sensitivity workloads in dedicated trust zones with explicit identity, network, storage and management-plane policy; restrict ingress, egress, replication and operator paths.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Shared control planes, CI/CD, backup systems, observability, jump hosts and keys can bridge otherwise separate networks.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Attempt access from lower-trust workloads, identities, networks and management planes; verify denial and alerting while approved flows still work.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 6 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 3.13 · Deploy a Data Loss Prevention Solution · IG3 onward

Population and scope: DLP scope spans endpoints, email, web, cloud storage, SaaS, collaboration, databases and sanctioned transfer paths where sensitive data can be identified or controlled. Coverage claims must state data types, channels, managed/unmanaged devices, encrypted traffic visibility and detect-only versus block mode.
Implementation and owner: Start from the data inventory and highest-consequence exfiltration paths, deploy classifiers and exact-data or fingerprint rules, route incidents to owners, tune with labelled samples and feed confirmed discoveries back to the inventory. Separate policy administration, exception approval and investigation.
Evidence and negative test: Use true-positive, benign look-alike, obfuscated, compressed, encrypted and high-volume test data across each declared channel. Measure channel/population coverage, precision on adjudicated alerts, time to disposition and policy bypasses; an installed agent or license count is not successful coverage.
Exception and failure boundary: DLP cannot see end-to-end encrypted, unmanaged or unsupported paths and can harm privacy. Blocking may be unsafe for production transfers, so monitor-and-respond can be valid when explicitly bounded. Screenshots, photos, retyping, model prompts and approved-but-malicious insiders require other controls.

PRD implementation register · 84 atomic requirements · 12 dimensions · data_lifecycle, enforcement

O01Outcome and decision. Define the user, business, and risk outcome for Deploy a Data Loss Prevention Solution; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 3.13, official Asset Class Data, Security Function Protect, and IG3 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “DLP scope spans endpoints, email, web, cloud storage, SaaS, collaboration, databases and sanctioned transfer paths where sensitive data can be identified or controlled.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Deploy a Data Loss Prevention Solution to its operating object—sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Deploy a Data Loss Prevention Solution, express success as an observable decision over data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Deploy a Data Loss Prevention Solution, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV3, GV5, GV18, M1, M2, M3, M4, M5) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 2.1, Safeguard 3.2; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Start from the data inventory and highest-consequence exfiltration paths, deploy classifiers and exact-data or fingerprint rules, route incidents to owners, tune with labelled samples and feed confirmed discoveries back to the inventory.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “DLP cannot see end-to-end encrypted, unmanaged or unsupported paths and can harm privacy.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Use true-positive, benign look-alike, obfuscated, compressed, encrypted and high-volume test data across each declared channel.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 8 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 3.14 · Log Sensitive Data Access · IG3 onward

Population and scope: Log reads, queries, exports, modification, deletion and permission/key changes for sensitive data, including human, service, provider-support and administrative paths. Infrastructure access logs alone may not identify the record or data set actually touched.
Implementation and owner: Enable native database, storage, application and key audit events; preserve actor, effective identity, action, object/data set, result, time, source, volume and correlation context. Route to protected centralized storage, minimize unnecessary sensitive payloads, and link detections to owners.
Evidence and negative test: Perform allowed read/update/delete/export and denied attempts with human and service identities, then trace complete events through collection, parsing, retention and review. Measure enabled, recently emitting in-scope data stores over all discovered stores, plus sampled event completeness and alert outcomes.
Exception and failure boundary: Bulk analytics, break-glass, support access, backups and application connection pools can obscure the real actor. Logging every row may be infeasible; statement, object and volume logs can meet the risk need if bounded. A configured logger that cannot survive tampering or is never reviewed supplies evidence but little control.

PRD implementation register · 96 atomic requirements · 12 dimensions · data_lifecycle, identity, telemetry

O01Outcome and decision. Define the user, business, and risk outcome for Log Sensitive Data Access; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 3.14, official Asset Class Data, Security Function Detect, and IG3 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Log reads, queries, exports, modification, deletion and permission/key changes for sensitive data, including human, service, provider-support and administrative paths.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Log Sensitive Data Access to its operating object—sensitive and business data, replicas, logs, backups, exports, derived data, AI corpora, keys, and data flows—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Log Sensitive Data Access, express success as an observable decision over data identity, sensitivity, owner, purpose, location, flow, access, retention, copy, derivation, and disposal state; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Log Sensitive Data Access, express success as an observable decision over effective identity, authentication, authorization, privilege, session, and revocation state across every access path; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For Log Sensitive Data Access, express success as an observable decision over complete, attributable, timely, protected, searchable, and actionable security telemetry plus source health; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P08Population and applicability. Include clock skew, actor loss, field truncation, parser drift, dropped or duplicate events, privacy redaction, provider gaps, encrypted paths, quota, and archive failure in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W08Ownership and approval. Name who may transition event produced → collected → parsed → enriched → stored → detected/reviewed → preserved/expired, who approves the transition, who supplies evidence, and who independently reviews it.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D08Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle event produced → collected → parsed → enriched → stored → detected/reviewed → preserved/expired.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I08Dependencies and integrations. Require every connector carrying complete, attributable, timely, protected, searchable, and actionable security telemetry plus source health to preserve tenant, object identity, source time, collection time, completeness, and failure status.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Enable native database, storage, application and key audit events; preserve actor, effective identity, action, object/data set, result, time, source, volume and correlation context.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C08Control flow and enforcement. Implement the explicit state machine event produced → collected → parsed → enriched → stored → detected/reviewed → preserved/expired; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T08Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for event produced → collected → parsed → enriched → stored → detected/reviewed → preserved/expired; alert before each deadline becomes overdue.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Bulk analytics, break-glass, support access, backups and application connection pools can obscure the real actor.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X08Exceptions and failure modes. Treat clock skew, actor loss, field truncation, parser drift, dropped or duplicate events, privacy redaction, provider gaps, encrypted paths, quota, and archive failure as named failure or exception paths with an owner, compensating control, expiry, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Perform allowed read/update/delete/export and denied attempts with human and service identities, then trace complete events through collection, parsing, retention and review.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 8 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E08Evidence and metrics. Publish healthy, silent, partial, late, malformed, duplicate, unowned, unreviewed, alerted, investigated, and archived sources or events with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S08Security, privacy, and resilience. Restrict authority to change event produced → collected → parsed → enriched → stored → detected/reviewed → preserved/expired; log privileged changes, protect evidence history, and test administrative recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V08Verification and adversarial tests. Run the positive control an allowed and denied canary event traced from source through review; exercise negative, stale, duplicate, bypass, and outage controls including source loss, parser/schema change, time skew, queue overflow, duplicate delivery, provider export outage, missed alert, and unreadable archive.

R08Operations, change, and closure. Use healthy, silent, partial, late, malformed, duplicate, unowned, unreviewed, alerted, investigated, and archived sources or events to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

3.4 Control 4: Secure Configuration of Enterprise Assets and Software

Control 4 is the second major implementation spine. A baseline is a versioned engineering decision for one product, role and environment, followed by deployment, live-state verification and an expiring deviation. Naming a Benchmark or assigning a policy does not establish that state.

The same discipline extends from sessions and firewalls to DNS, management protocols, mobile lockout, wipe and work profiles. Configuration claims are accepted only after a positive business path and a negative bypass path both behave as intended.

Primary measurement reference: official CAS Control 4; the cards below add an independent implementation boundary to that control.

CIS Safeguard 4.1 · Establish and Maintain a Secure Configuration Process · IG1 onward

Population and scope: The process covers each supported asset and software family, version, role and environment, including endpoints, servers, mobile, IoT, operating systems, applications, databases, containers, cloud resources and provider-managed tenant settings. A benchmark name without profile, version and applicability decisions is not a configuration standard.
Implementation and owner: Create risk-based, version-controlled baselines from authoritative hardening guidance; document values, rationale, allowed deviations, deployment method, validation and rollback. Platform owners approve and automate them through images, MDM, configuration management, policy-as-code and CI/CD; review annually and on significant product, threat or architecture change.
Evidence and negative test: Build a clean instance from the baseline and test required business paths, then introduce a prohibited setting and verify drift detection and repair. Sample live assets against their exact baseline and report eligible, assessed, compliant, drifted, excepted and unevaluable populations with baseline and scanner versions.
Exception and failure boundary: A secure setting can break safety, availability or vendor support, so deviations are exact, owned, compensated, expiring and retested. SaaS/provider settings and ephemeral workloads need API or deployment-time evidence. The CAS ratio measures documentation coverage; live asset enforcement requires a separate check.

PRD implementation register · 96 atomic requirements · 12 dimensions · enforcement, governance · expanded complexity

O01Outcome and decision. Define the user, business, and risk outcome for Establish and Maintain a Secure Configuration Process; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 4.1, official Asset Class Documentation, Security Function Govern, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The process covers each supported asset and software family, version, role and environment, including endpoints, servers, mobile, IoT, operating systems, applications, databases, containers, cloud resources and provider-managed tenant settings.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Establish and Maintain a Secure Configuration Process to its operating object—role-specific secure baselines and effective configurations for endpoints, servers, mobile, cloud, network, software, and administrative paths—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Establish and Maintain a Secure Configuration Process, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Establish and Maintain a Secure Configuration Process, express success as an observable decision over a documented decision system with policy, process, procedure, accountable owner, approval, and review; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For the expanded Establish and Maintain a Secure Configuration Process scope, resolve conflicts among security, safety, privacy, legal, availability, customer, and operational objectives through an explicit risk decision.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P05Population and applicability. Resolve applicability across unsupported settings, local overrides, inherited cloud policy, vendor defaults, emergency access, safety constraints, drift, and rollback; each edge receives an evidenced in-scope, out-of-scope, unknown, or time-bounded exception result.

P06Population and applicability. Include audit-only mode, unsupported platforms, local overrides, race conditions, cached state, alternate paths, fail-open behavior, and emergency bypass in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W05Ownership and approval. Bind platform and application owners, network engineering, security architecture, change management, and service owners to a RACI for the Safeguard and name the authority that resolves conflicting source or risk decisions.

W06Ownership and approval. Name who may transition observe → evaluate → decide → enforce → verify outcome → rollback/close, who approves the transition, who supplies evidence, and who independently reviews it.

W08Ownership and approval. Model delegated authority, quorum or dual approval where warranted, escalation deadlines, provider handoffs, conflict resolution, and executive risk acceptance.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV3, GV5, M1, M2, M3, M4, M5, M6) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D05Data contract and identity. Use the versioned secure-configuration authority and exception register as the governed current-state record; persist identity, owner, provenance, prior/new state, reason, actor, time, and exception link.

D06Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle observe → evaluate → decide → enforce → verify outcome → rollback/close.

D08Data contract and identity. Version schemas and state transitions with migration, backfill, deduplication, lineage, historical denominator, deletion, and rollback semantics.

I01Dependencies and integrations. Record prerequisite state for Safeguard 2.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I05Dependencies and integrations. Reconcile benchmarks, golden images, configuration management, IaC, MDM, cloud policy, network controllers, drift scans, and change records and expose source-specific health, latency, confidence, omissions, and conflict resolution.

I06Dependencies and integrations. Require every connector carrying an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point to preserve tenant, object identity, source time, collection time, completeness, and failure status.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Create risk-based, version-controlled baselines from authoritative hardening guidance; document values, rationale, allowed deviations, deployment method, validation and rollback.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C05Control flow and enforcement. Implement the state transition in the versioned secure-configuration authority and exception register and preserve the exact operating control point, policy or procedure version, result, and downstream update.

C06Control flow and enforcement. Implement the explicit state machine observe → evaluate → decide → enforce → verify outcome → rollback/close; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T05Timing and lifecycle. Set freshness and action SLOs from the rate of change in role-specific secure baselines and effective configurations for endpoints, servers, mobile, cloud, network, software, and administrative paths; source age, queue age, exception age, and closure age remain separate clocks.

T06Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for observe → evaluate → decide → enforce → verify outcome → rollback/close; alert before each deadline becomes overdue.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “A secure setting can break safety, availability or vendor support, so deviations are exact, owned, compensated, expiring and retested.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X05Exceptions and failure modes. Treat unsupported settings, local overrides, inherited cloud policy, vendor defaults, emergency access, safety constraints, drift, and rollback as designed non-happy paths with an owner, compensating control, expiry, safety or business constraint, and retest.

X06Exceptions and failure modes. Treat audit-only mode, unsupported platforms, local overrides, race conditions, cached state, alternate paths, fail-open behavior, and emergency bypass as named failure or exception paths with an owner, compensating control, expiry, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Build a clean instance from the baseline and test required business paths, then introduce a prohibited setting and verify drift detection and repair.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 9 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E05Evidence and metrics. Derive coverage and effectiveness from the versioned secure-configuration authority and exception register plus independent source receipts; report unknown, stale, conflicting, failed, and excepted objects separately.

E06Evidence and metrics. Publish eligible, enforcing, audit-only, failed, bypassed, excepted, rolled-back, and outcome-verified populations with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S05Security, privacy, and resilience. Protect write and approval authority over the versioned secure-configuration authority and exception register; monitor privileged changes, exports, deletions, source disablement, and recovery.

S06Security, privacy, and resilience. Restrict authority to change observe → evaluate → decide → enforce → verify outcome → rollback/close; log privileged changes, protect evidence history, and test administrative recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V05Verification and adversarial tests. Exercise approved business behavior, a prohibited setting or service, policy tampering, failed rollout, drift recurrence, and tested rollback through representative platforms and verify business behavior, control decision, telemetry, case workflow, rollback, and final state.

V06Verification and adversarial tests. Run the positive control an approved business action that completes through the enforced path; exercise negative, stale, duplicate, bypass, and outage controls including a prohibited action, alternate path, local override, stale policy, control outage, emergency bypass, and rollback failure.

R05Operations, change, and closure. Re-run reconciliation and affected tests whenever benchmarks, golden images, configuration management, IaC, MDM, cloud policy, network controllers, drift scans, and change records change ownership, schema, coverage, provider, policy, or platform version.

R06Operations, change, and closure. Use eligible, enforcing, audit-only, failed, bypassed, excepted, rolled-back, and outcome-verified populations to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

CIS Safeguard 4.2 · Establish and Maintain a Secure Configuration Process for Network Infrastructure · IG1 onward

Population and scope: Include routers, switches, firewalls, wireless, load balancers, DNS/DHCP, VPN, SD-WAN, cloud networks, service meshes and management controllers across physical and virtual infrastructure. Managed-service responsibility changes who operates a setting, not whether the tenant-specific boundary exists.
Implementation and owner: Maintain versioned baselines by device role and trust zone covering management plane, authentication, protocols, routing, logging, time, services, backups and control-plane protection. Deploy through reviewed templates or APIs, protect secrets, validate syntax and state, and keep tested rollback and out-of-band recovery.
Evidence and negative test: Compare running and intended configuration after normalization, sample devices from every role, and inject a harmless drift in a test segment. Verify approval, deployment, detection, rollback and log evidence; measure current successful assessments and exceptions against the authoritative device/control-plane population.
Exception and failure boundary: High availability pairs, controller-generated state and emergency routing can make text diffs misleading. Provider defaults, inherited policies and overlays require effective-state checks. Legacy equipment gets isolated management and replacement dates; an unreachable device is unevaluated, never compliant.

PRD implementation register · 108 atomic requirements · 12 dimensions · enforcement, network, governance · expanded complexity

O01Outcome and decision. Define the user, business, and risk outcome for Establish and Maintain a Secure Configuration Process for Network Infrastructure; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 4.2, official Asset Class Documentation, Security Function Govern, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Include routers, switches, firewalls, wireless, load balancers, DNS/DHCP, VPN, SD-WAN, cloud networks, service meshes and management controllers across physical and virtual infrastructure.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Establish and Maintain a Secure Configuration Process for Network Infrastructure to its operating object—role-specific secure baselines and effective configurations for endpoints, servers, mobile, cloud, network, software, and administrative paths—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Establish and Maintain a Secure Configuration Process for Network Infrastructure, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Establish and Maintain a Secure Configuration Process for Network Infrastructure, express success as an observable decision over intended connectivity, trust zone, route, protocol, identity, management path, traffic decision, and observed outcome; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For Establish and Maintain a Secure Configuration Process for Network Infrastructure, express success as an observable decision over a documented decision system with policy, process, procedure, accountable owner, approval, and review; name the business effect of each accepted, rejected, and unresolved state.

O09Outcome and decision. For the expanded Establish and Maintain a Secure Configuration Process for Network Infrastructure scope, resolve conflicts among security, safety, privacy, legal, availability, customer, and operational objectives through an explicit risk decision.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P07Population and applicability. Include IPv6, overlays, east-west paths, remote and roaming devices, direct egress, alternate resolvers, QUIC, asymmetric routes, provider abstraction, and emergency consoles in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

P09Population and applicability. Define nested scope at enterprise, business service, tenant, environment, platform, object, identity, data set, and transaction levels; prohibit a parent result from hiding a failing child.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W07Ownership and approval. Name who may transition requested flow → identity/context resolved → policy evaluated → allowed/denied → logged → reviewed → rule retired, who approves the transition, who supplies evidence, and who independently reviews it.

W09Ownership and approval. Model delegated authority, quorum or dual approval where warranted, escalation deadlines, provider handoffs, conflict resolution, and executive risk acceptance.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D07Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle requested flow → identity/context resolved → policy evaluated → allowed/denied → logged → reviewed → rule retired.

D09Data contract and identity. Version schemas and state transitions with migration, backfill, deduplication, lineage, historical denominator, deletion, and rollback semantics.

I01Dependencies and integrations. Record prerequisite state for Safeguard 2.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I07Dependencies and integrations. Require every connector carrying intended connectivity, trust zone, route, protocol, identity, management path, traffic decision, and observed outcome to preserve tenant, object identity, source time, collection time, completeness, and failure status.

I09Dependencies and integrations. Define consistency rules across disagreeing sources, source precedence, confidence, reconciliation queues, dead-letter handling, reprocessing, and end-to-end trace identity.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Maintain versioned baselines by device role and trust zone covering management plane, authentication, protocols, routing, logging, time, services, backups and control-plane protection.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C07Control flow and enforcement. Implement the explicit state machine requested flow → identity/context resolved → policy evaluated → allowed/denied → logged → reviewed → rule retired; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

C09Control flow and enforcement. Specify concurrent decisions, partial success, compensating transactions, repeated requests, stale policy, dependency outage, and recovery from an interrupted state transition.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T07Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for requested flow → identity/context resolved → policy evaluated → allowed/denied → logged → reviewed → rule retired; alert before each deadline becomes overdue.

T09Timing and lifecycle. Allocate an end-to-end SLO budget across discovery, collection, processing, approval, enforcement, verification, and closure; prioritize overdue work by consequence and exposure.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “High availability pairs, controller-generated state and emergency routing can make text diffs misleading.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X07Exceptions and failure modes. Treat IPv6, overlays, east-west paths, remote and roaming devices, direct egress, alternate resolvers, QUIC, asymmetric routes, provider abstraction, and emergency consoles as named failure or exception paths with an owner, compensating control, expiry, and retest.

X09Exceptions and failure modes. Exercise compound failures where an exception, stale source, provider outage, unavailable owner, and degraded control overlap; define one safe command and one accountable decision.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Compare running and intended configuration after normalization, sample devices from every role, and inject a harmless drift in a test segment.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 9 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E07Evidence and metrics. Publish known, unknown, allowed, denied, shadow, bypassed, asymmetric, stale-rule, exception, and unobserved paths with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

E09Evidence and metrics. Require an independent party to reconstruct the decision from source receipts and reproduce the population, state transition, calculation, test result, exception, and final closure.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S07Security, privacy, and resilience. Restrict authority to change requested flow → identity/context resolved → policy evaluated → allowed/denied → logged → reviewed → rule retired; log privileged changes, protect evidence history, and test administrative recovery.

S09Security, privacy, and resilience. Threat-model the implementation system itself: forged evidence, poisoned inventory, privilege abuse, cross-tenant confusion, policy rollback, audit deletion, denial of service, and recovery compromise.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V07Verification and adversarial tests. Run the positive control an approved flow over the required secure management or business path; exercise negative, stale, duplicate, bypass, and outage controls including an unapproved route, protocol downgrade, direct egress, alternate DNS/QUIC path, segmentation bypass, AAA loss, stale rule, and rollback failure.

V09Verification and adversarial tests. Build a pairwise platform-and-failure matrix, then add high-consequence multi-factor cases, historical regression, source substitution, red-team challenge, and assessor replay.

R07Operations, change, and closure. Use known, unknown, allowed, denied, shadow, bypassed, asymmetric, stale-rule, exception, and unobserved paths to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

R09Operations, change, and closure. Use canary deployment, kill criteria, rollback, backlog burn-down, exception reduction, source-quality targets, quarterly design review, and a measurable retirement plan.

CIS Safeguard 4.3 · Configure Automatic Session Locking on Enterprise Assets · IG1 onward

Population and scope: Eligible interactive sessions include desktop, laptop, mobile, virtual desktop, jump host and administrative consoles that can expose enterprise data or authority after inactivity. Service sessions, kiosks and operational displays need an explicit functional decision and remain in the population with their chosen treatment.
Implementation and owner: Enforce no more than 15 minutes on general-purpose systems and two minutes on mobile through central configuration, with reauthentication on unlock. Choose shorter periods for privileged or exposed contexts, prevent ordinary users from extending them and coordinate with application/session controls where the OS lock leaves remote sessions alive.
Evidence and negative test: Measure effective live policy and last check for all eligible devices, then leave a session idle beyond the threshold and verify screen lock, protected data, remote/virtual behavior and reauthentication. Test policy tampering and resume from sleep; count unsupported and exception devices separately.
Exception and failure boundary: A screen saver without authentication fails. Long-running dashboards, clinical stations and shared production consoles may use presence, badge, physical zoning or supervised kiosk controls under an expiring risk decision. Session lock limits walk-up misuse; it does not terminate tokens, network sessions or unattended batch authority.

PRD implementation register · 72 atomic requirements · 12 dimensions · enforcement

O01Outcome and decision. Define the user, business, and risk outcome for Configure Automatic Session Locking on Enterprise Assets; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 4.3, official Asset Class Devices, Security Function Protect, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Eligible interactive sessions include desktop, laptop, mobile, virtual desktop, jump host and administrative consoles that can expose enterprise data or authority after inactivity.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Configure Automatic Session Locking on Enterprise Assets to its operating object—role-specific secure baselines and effective configurations for endpoints, servers, mobile, cloud, network, software, and administrative paths—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Configure Automatic Session Locking on Enterprise Assets, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Enforce no more than 15 minutes on general-purpose systems and two minutes on mobile through central configuration, with reauthentication on unlock.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T01Timing and lifecycle. Preserve the official cadence terms found in the pinned description (15 minutes, 2 minutes); define faster local SLOs where asset change, exposure, safety, or threat consequence requires them.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “A screen saver without authentication fails.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Measure effective live policy and last check for all eligible devices, then leave a session idle beyond the threshold and verify screen lock, protected data, remote/virtual behavior and reauthentication.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 9 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 4.4 · Implement and Manage a Firewall on Servers · IG1 onward

Population and scope: The server population includes physical, virtual, cloud and container hosts plus serverless or platform equivalents where a local or workload policy is available. Network firewalls do not automatically cover east-west, loopback, overlay, host-network and same-subnet paths.
Implementation and owner: Apply default-deny or least-exposure ingress and, where risk supports it, egress rules at host, workload, security-group or virtual-firewall layers. Generate policy from service ownership and flows, centrally manage changes, preserve break-glass access and reconcile listening services to allowed sources and ports.
Evidence and negative test: From allowed and disallowed source zones, test required ports, unexpected listeners, IPv4/IPv6, overlay and management paths. Inspect effective rules and enforcement status on every eligible server; verify disabling the agent or adding a local rule alerts and repairs without locking out recovery.
Exception and failure boundary: Platform services and clustered control traffic need documented rules, not blanket any-to-any. Host policy absent because a product is unsupported requires compensating segmentation and a retirement plan. Installed software, an empty policy or “running” status is not proof of enforcement.

PRD implementation register · 84 atomic requirements · 12 dimensions · enforcement, network

O01Outcome and decision. Define the user, business, and risk outcome for Implement and Manage a Firewall on Servers; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 4.4, official Asset Class Devices, Security Function Protect, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The server population includes physical, virtual, cloud and container hosts plus serverless or platform equivalents where a local or workload policy is available.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Implement and Manage a Firewall on Servers to its operating object—role-specific secure baselines and effective configurations for endpoints, servers, mobile, cloud, network, software, and administrative paths—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Implement and Manage a Firewall on Servers, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Implement and Manage a Firewall on Servers, express success as an observable decision over intended connectivity, trust zone, route, protocol, identity, management path, traffic decision, and observed outcome; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Apply default-deny or least-exposure ingress and, where risk supports it, egress rules at host, workload, security-group or virtual-firewall layers.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Platform services and clustered control traffic need documented rules, not blanket any-to-any.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “From allowed and disallowed source zones, test required ports, unexpected listeners, IPv4/IPv6, overlay and management paths.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 9 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 4.5 · Implement and Manage a Firewall on End-User Devices · IG1 onward

Population and scope: Cover managed desktops, laptops and other end-user devices on corporate, home, public, VPN and disconnected networks, for both IP families and every network profile. The CIS requirement is default-deny inbound except explicitly allowed services and ports.
Implementation and owner: Centrally enforce host firewall profiles, block local user override, minimize inbound exceptions by application, source and profile, and keep outbound controls proportional to the threat model. MDM/endpoint owners monitor state and define safe recovery so a bad rule can be rolled back.
Evidence and negative test: Probe a representative device from trusted, guest and remote networks over IPv4/IPv6, verify allowed business functions and denied unexpected ports, then disable the firewall or change profile to test detection. Measure effective enforcing configurations over eligible devices, not installed components.
Exception and failure boundary: Developer servers, peer collaboration, assistive technology and support tools need narrow time-bound rules. VPN split tunnelling and profile misclassification can select the wrong policy. The CAS operations/measures shift M2/M3/M4 labels, so consumers must map the intended numerator directly instead of executing the text mechanically.

PRD implementation register · 84 atomic requirements · 12 dimensions · enforcement, network

O01Outcome and decision. Define the user, business, and risk outcome for Implement and Manage a Firewall on End-User Devices; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 4.5, official Asset Class Devices, Security Function Protect, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Cover managed desktops, laptops and other end-user devices on corporate, home, public, VPN and disconnected networks, for both IP families and every network profile.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Implement and Manage a Firewall on End-User Devices to its operating object—role-specific secure baselines and effective configurations for endpoints, servers, mobile, cloud, network, software, and administrative paths—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Implement and Manage a Firewall on End-User Devices, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Implement and Manage a Firewall on End-User Devices, express success as an observable decision over intended connectivity, trust zone, route, protocol, identity, management path, traffic decision, and observed outcome; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV3, GV5, M1, M2, M3, M4) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Centrally enforce host firewall profiles, block local user override, minimize inbound exceptions by application, source and profile, and keep outbound controls proportional to the threat model.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Developer servers, peer collaboration, assistive technology and support tools need narrow time-bound rules.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Probe a representative device from trusted, guest and remote networks over IPv4/IPv6, verify allowed business functions and denied unexpected ports, then disable the firewall or change profile to test detection.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 7 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 4.6 · Securely Manage Enterprise Assets and Software · IG1 onward

Population and scope: Management scope includes local and remote administration of devices, operating systems, applications, cloud/SaaS, hypervisors, containers and infrastructure-as-code. It covers protocol security, management-plane reachability, administrator identity, change provenance, secrets and session recording where consequence requires it.
Implementation and owner: Route administration through dedicated trusted paths using SSH, HTTPS or equivalent authenticated encryption, central identity/MFA, least privilege and version-controlled changes. Disable Telnet/HTTP and direct public management, protect IaC state and keys, separate production administration, and log both API and interactive actions.
Evidence and negative test: Attempt management from an unauthorized network and identity, try insecure protocol and expired credential paths, then verify denial and alerting. Trace a sampled change from approval or commit through deployment, effective state and rollback; enumerate unmanaged interfaces and locally changed assets.
Exception and failure boundary: Encryption alone does not make an exposed management plane safe. Vendor emergency channels, console ports, support tunnels and cloud root accounts require explicit custody and monitoring. Operationally essential insecure protocols stay inside isolated gateways with expiry and migration plans.

PRD implementation register · 84 atomic requirements · 12 dimensions · enforcement, software_dev

O01Outcome and decision. Define the user, business, and risk outcome for Securely Manage Enterprise Assets and Software; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 4.6, official Asset Class Devices, Security Function Protect, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Management scope includes local and remote administration of devices, operating systems, applications, cloud/SaaS, hypervisors, containers and infrastructure-as-code.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Securely Manage Enterprise Assets and Software to its operating object—role-specific secure baselines and effective configurations for endpoints, servers, mobile, cloud, network, software, and administrative paths—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Securely Manage Enterprise Assets and Software, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Securely Manage Enterprise Assets and Software, express success as an observable decision over source-to-production software identity, design invariant, component trust, build provenance, test result, deployment state, runtime outcome, and vulnerability response; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P07Population and applicability. Include generated and copied code, forks, vendoring, transitive dependencies, mutable tags, build plugins, feature flags, tenant logic, secrets, emergency release, and provider components in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W07Ownership and approval. Name who may transition designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired, who approves the transition, who supplies evidence, and who independently reviews it.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D07Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I07Dependencies and integrations. Require every connector carrying source-to-production software identity, design invariant, component trust, build provenance, test result, deployment state, runtime outcome, and vulnerability response to preserve tenant, object identity, source time, collection time, completeness, and failure status.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Route administration through dedicated trusted paths using SSH, HTTPS or equivalent authenticated encryption, central identity/MFA, least privilege and version-controlled changes.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C07Control flow and enforcement. Implement the explicit state machine designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T07Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired; alert before each deadline becomes overdue.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Encryption alone does not make an exposed management plane safe.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X07Exceptions and failure modes. Treat generated and copied code, forks, vendoring, transitive dependencies, mutable tags, build plugins, feature flags, tenant logic, secrets, emergency release, and provider components as named failure or exception paths with an owner, compensating control, expiry, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Attempt management from an unauthorized network and identity, try insecure protocol and expired credential paths, then verify denial and alerting.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 8 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E07Evidence and metrics. Publish reviewed, unreviewed, reproducible, provenance-bound, vulnerable, test-failed, exception, deployed-unverified, drifted, rolled-back, and regression-protected releases with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S07Security, privacy, and resilience. Restrict authority to change designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired; log privileged changes, protect evidence history, and test administrative recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V07Verification and adversarial tests. Run the positive control a trusted build that preserves the security invariant through deployment and runtime; exercise negative, stale, duplicate, bypass, and outage controls including a substituted dependency, unreviewed change, poisoned build input, failed security test, bypass path, vulnerable release, rollback, and regression.

R07Operations, change, and closure. Use reviewed, unreviewed, reproducible, provenance-bound, vulnerable, test-failed, exception, deployed-unverified, drifted, rolled-back, and regression-protected releases to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

CIS Safeguard 4.7 · Manage Default Accounts on Enterprise Assets and Software · IG1 onward

Population and scope: Include factory, built-in, sample, guest, root, administrator, maintenance, cloud break-glass and vendor-support accounts across assets and software. Renaming an account does not remove its known identifier, privileges, recovery path or default credential.
Implementation and owner: Disable or render default accounts unusable; where impossible, rotate to unique managed secrets, restrict sources and roles, monitor use and assign an accountable custodian. Build the treatment into provisioning and verify upgrades or factory resets do not restore defaults.
Evidence and negative test: Attempt authentication with published defaults and enumerate enabled built-in identities on representative systems. Test installation, upgrade and reset; reconcile every unavoidable enabled account to a unique secret, restriction and owner. The correct ratio is unusable-or-secured default accounts over identified defaults.
Exception and failure boundary: The CAS formula lacks parentheses and can overstate the result. Shared vendor credentials, hidden support accounts and cloud-provider access need contract and technical controls. A default account required for recovery can remain enabled only with vaulted credentials, MFA where supported, alerting, periodic test and strict use conditions.

PRD implementation register · 96 atomic requirements · 12 dimensions · enforcement, identity, software_dev

O01Outcome and decision. Define the user, business, and risk outcome for Manage Default Accounts on Enterprise Assets and Software; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 4.7, official Asset Class Users, Security Function Protect, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Include factory, built-in, sample, guest, root, administrator, maintenance, cloud break-glass and vendor-support accounts across assets and software.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Manage Default Accounts on Enterprise Assets and Software to its operating object—role-specific secure baselines and effective configurations for endpoints, servers, mobile, cloud, network, software, and administrative paths—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Manage Default Accounts on Enterprise Assets and Software, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Manage Default Accounts on Enterprise Assets and Software, express success as an observable decision over effective identity, authentication, authorization, privilege, session, and revocation state across every access path; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For Manage Default Accounts on Enterprise Assets and Software, express success as an observable decision over source-to-production software identity, design invariant, component trust, build provenance, test result, deployment state, runtime outcome, and vulnerability response; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P08Population and applicability. Include generated and copied code, forks, vendoring, transitive dependencies, mutable tags, build plugins, feature flags, tenant logic, secrets, emergency release, and provider components in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W08Ownership and approval. Name who may transition designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired, who approves the transition, who supplies evidence, and who independently reviews it.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV5, GV20, M1, M2, M3, M4, M5, M6) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D08Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired.

I01Dependencies and integrations. Record prerequisite state for Safeguard 1.1, Safeguard 2.1, Safeguard 5.2; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I08Dependencies and integrations. Require every connector carrying source-to-production software identity, design invariant, component trust, build provenance, test result, deployment state, runtime outcome, and vulnerability response to preserve tenant, object identity, source time, collection time, completeness, and failure status.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Disable or render default accounts unusable; where impossible, rotate to unique managed secrets, restrict sources and roles, monitor use and assign an accountable custodian.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C08Control flow and enforcement. Implement the explicit state machine designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T08Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired; alert before each deadline becomes overdue.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “The CAS formula lacks parentheses and can overstate the result.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X08Exceptions and failure modes. Treat generated and copied code, forks, vendoring, transitive dependencies, mutable tags, build plugins, feature flags, tenant logic, secrets, emergency release, and provider components as named failure or exception paths with an owner, compensating control, expiry, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Attempt authentication with published defaults and enumerate enabled built-in identities on representative systems.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 9 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E08Evidence and metrics. Publish reviewed, unreviewed, reproducible, provenance-bound, vulnerable, test-failed, exception, deployed-unverified, drifted, rolled-back, and regression-protected releases with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S08Security, privacy, and resilience. Restrict authority to change designed → reviewed → built from pinned inputs → tested → approved → deployed → observed → fixed/rolled back → retired; log privileged changes, protect evidence history, and test administrative recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V08Verification and adversarial tests. Run the positive control a trusted build that preserves the security invariant through deployment and runtime; exercise negative, stale, duplicate, bypass, and outage controls including a substituted dependency, unreviewed change, poisoned build input, failed security test, bypass path, vulnerable release, rollback, and regression.

R08Operations, change, and closure. Use reviewed, unreviewed, reproducible, provenance-bound, vulnerable, test-failed, exception, deployed-unverified, drifted, rolled-back, and regression-protected releases to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

CIS Safeguard 4.8 · Uninstall or Disable Unnecessary Services on Enterprise Assets and Software · IG2 onward

Population and scope: The population includes OS daemons, listeners, application modules, cloud features, management APIs, packages, browser services and container sidecars that are installed or enabled. “Authorized somewhere” does not make a service necessary on every role or reachable from every zone.
Implementation and owner: Define required services per asset role in the secure baseline, remove packages when practical, otherwise disable and block them, and prevent automatic re-enablement. Tie exceptions to a business dependency and observe actual listening sockets, processes and cloud/API configuration.
Evidence and negative test: Compare live services and ports to the role baseline, disable a benign test service and verify persistence after restart/update, then start an unapproved listener to test detection and remediation. Report unnecessary running, installed-disabled and unassessed separately.
Exception and failure boundary: Socket activation, scheduled tasks, containers and on-demand cloud features may be dormant during a snapshot. Disabling without removing can still leave exploitable code, while removal may break patching or support. Legacy dependencies need isolation and an exit milestone; authorized-but-misconfigured services remain failures under other safeguards.

PRD implementation register · 84 atomic requirements · 12 dimensions · enforcement, software_dev

O01Outcome and decision. Define the user, business, and risk outcome for Uninstall or Disable Unnecessary Services on Enterprise Assets and Software; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 4.8, official Asset Class Devices, Security Function Protect, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The population includes OS daemons, listeners, application modules, cloud features, management APIs, packages, browser services and container sidecars that are installed or enabled.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Uninstall or Disable Unnecessary Services on Enterprise Assets and Software to its operating object—role-specific secure baselines and effective configurations for endpoints, servers, mobile, cloud, network, software, and administrative paths—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Uninstall or Disable Unnecessary Services on Enterprise Assets and Software, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Uninstall or Disable Unnecessary Services on Enterprise Assets and Software, express success as an observable decision over source-to-production software identity, design invariant, component trust, build provenance, test result, deployment state, runtime outcome, and vulnerability response; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 1.1, Safeguard 2.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Define required services per asset role in the secure baseline, remove packages when practical, otherwise disable and block them, and prevent automatic re-enablement.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Socket activation, scheduled tasks, containers and on-demand cloud features may be dormant during a snapshot.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Compare live services and ports to the role baseline, disable a benign test service and verify persistence after restart/update, then start an unapproved listener to test detection and remediation.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 9 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 4.9 · Configure Trusted DNS Servers on Enterprise Assets · IG2 onward

Population and scope: Cover DNS settings and effective resolution paths on endpoints, servers, network devices, VPNs, mobile, cloud networks, containers and applications using embedded or encrypted DNS. The trusted set must specify resolver identity, purpose, policy and failover, not merely an IP address.
Implementation and owner: Enforce enterprise or explicitly approved resolvers through DHCP/RA, device policy, VPN, cloud and application configuration; authenticate encrypted DNS where used, control bypass, protect resolver administration and monitor fallback. Separate internal namespaces, public recursion and provider dependencies.
Evidence and negative test: Resolve test names through normal and failure paths and confirm the actual resolver, policy response, logging and DNSSEC behavior where required. Attempt a rogue resolver, hard-coded public DNS and browser DoH; measure assets with verified effective paths over eligible assets.
Exception and failure boundary: Captive portals, roaming clients, split DNS, IPv6 RDNSS and application-level DoH can bypass endpoint settings. A reputable external resolver may still violate data or jurisdiction requirements. Resolver availability failover must not silently fall back to an untrusted path.

PRD implementation register · 84 atomic requirements · 12 dimensions · enforcement, network

O01Outcome and decision. Define the user, business, and risk outcome for Configure Trusted DNS Servers on Enterprise Assets; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 4.9, official Asset Class Devices, Security Function Protect, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Cover DNS settings and effective resolution paths on endpoints, servers, network devices, VPNs, mobile, cloud networks, containers and applications using embedded or encrypted DNS.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Configure Trusted DNS Servers on Enterprise Assets to its operating object—role-specific secure baselines and effective configurations for endpoints, servers, mobile, cloud, network, software, and administrative paths—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Configure Trusted DNS Servers on Enterprise Assets, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Configure Trusted DNS Servers on Enterprise Assets, express success as an observable decision over intended connectivity, trust zone, route, protocol, identity, management path, traffic decision, and observed outcome; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV3, M1, M2, M3, M4) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 1.1, Safeguard 4.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Enforce enterprise or explicitly approved resolvers through DHCP/RA, device policy, VPN, cloud and application configuration; authenticate encrypted DNS where used, control bypass, protect resolver administration and monitor fallback.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Captive portals, roaming clients, split DNS, IPv6 RDNSS and application-level DoH can bypass endpoint settings.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Resolve test names through normal and failure paths and confirm the actual resolver, policy response, logging and DNSSEC behavior where required.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 6 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 4.10 · Enforce Automatic Device Lockout on Portable End-User Devices · IG2 onward

Population and scope: Eligible devices are laptops, tablets and smartphones with local authentication and enterprise data or authority. CIS caps local failed attempts at 20 for laptops and 10 for phones/tablets; remote identity lockout and online rate limiting are related but distinct populations.
Implementation and owner: Enforce thresholds through MDM/endpoint policy with escalating delay, lock or secure wipe appropriate to data and recovery risk. Protect recovery credentials, prevent user override and align biometric/PIN fallback, offline attempts and hardware-backed limits with the declared policy.
Evidence and negative test: On test devices, exceed the threshold using local, biometric-fallback and offline paths, verify lock state, data preservation or wipe, alerting and approved recovery. Inspect effective policy and last attestation for all eligible devices; assigned configuration profiles are supporting metadata.
Exception and failure boundary: Aggressive wipe can cause denial of service or destroy unsynchronized evidence; choose lock versus wipe deliberately. Devices without support require full encryption, restricted data and replacement. Help-desk reset and boot/recovery modes must not create an unmonitored bypass.

PRD implementation register · 72 atomic requirements · 12 dimensions · enforcement

O01Outcome and decision. Define the user, business, and risk outcome for Enforce Automatic Device Lockout on Portable End-User Devices; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 4.10, official Asset Class Devices, Security Function Protect, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Eligible devices are laptops, tablets and smartphones with local authentication and enterprise data or authority.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Enforce Automatic Device Lockout on Portable End-User Devices to its operating object—role-specific secure baselines and effective configurations for endpoints, servers, mobile, cloud, network, software, and administrative paths—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Enforce Automatic Device Lockout on Portable End-User Devices, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV3, M1, M2, M3, M4, M5) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 1.1, Safeguard 4.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Enforce thresholds through MDM/endpoint policy with escalating delay, lock or secure wipe appropriate to data and recovery risk.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Aggressive wipe can cause denial of service or destroy unsynchronized evidence; choose lock versus wipe deliberately.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “On test devices, exceed the threshold using local, biometric-fallback and offline paths, verify lock state, data preservation or wipe, alerting and approved recovery.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 7 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 4.11 · Enforce Remote Wipe Capability on Portable End-User Devices · IG2 onward

Population and scope: Scope enterprise-owned portable devices and the enterprise workspace/data on supported personally owned devices. Remote wipe depends on enrolment, connectivity, identity and provider availability; it is a response capability, not assurance that every lost offline device is erased.
Implementation and owner: Enroll devices before access, maintain MDM authority and last contact, separate full-device from selective wipe, require incident authorization and preserve a chain of actions. Pair with encryption, local lock, revocation of tokens/keys and recovery or legal-hold decisions.
Evidence and negative test: Use a sacrificial enrolled device to test command authorization, delivery, offline queueing, workspace/full wipe result, token revocation and audit receipt. Report capable/enrolled/recently reachable/tested populations separately; a button displayed in the console is not a completed wipe.
Exception and failure boundary: Powered-off, reset, jailbroken, unenrolled and permanently offline devices may never receive the command. BYOD usually permits selective enterprise wipe only. Wiping can conflict with evidence preservation and worker-owned data, so incident, legal and privacy owners define the decision boundary in advance.

PRD implementation register · 96 atomic requirements · 12 dimensions · enforcement, recovery, network

O01Outcome and decision. Define the user, business, and risk outcome for Enforce Remote Wipe Capability on Portable End-User Devices; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 4.11, official Asset Class Data, Security Function Protect, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Scope enterprise-owned portable devices and the enterprise workspace/data on supported personally owned devices.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Enforce Remote Wipe Capability on Portable End-User Devices to its operating object—role-specific secure baselines and effective configurations for endpoints, servers, mobile, cloud, network, software, and administrative paths—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Enforce Remote Wipe Capability on Portable End-User Devices, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Enforce Remote Wipe Capability on Portable End-User Devices, express success as an observable decision over recoverable business service, protected recovery point, trustworthy copy, dependency, recovery objective, and verified restored outcome; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For Enforce Remote Wipe Capability on Portable End-User Devices, express success as an observable decision over intended connectivity, trust zone, route, protocol, identity, management path, traffic decision, and observed outcome; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P07Population and applicability. Include silent job failure, corrupt source, ransomware reachability, missing key, provider or region loss, quota, partial restore, stale runbook, and clean-room unavailability in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

P08Population and applicability. Include IPv6, overlays, east-west paths, remote and roaming devices, direct egress, alternate resolvers, QUIC, asymmetric routes, provider abstraction, and emergency consoles in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W07Ownership and approval. Name who may transition protected object identified → copy created → isolated/verified → retained → selected → restored → business-validated → expired, who approves the transition, who supplies evidence, and who independently reviews it.

W08Ownership and approval. Name who may transition requested flow → identity/context resolved → policy evaluated → allowed/denied → logged → reviewed → rule retired, who approves the transition, who supplies evidence, and who independently reviews it.

D03Data contract and identity. Map the pinned CAS variable set (GV1, GV3, M1, M2, M3) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D07Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle protected object identified → copy created → isolated/verified → retained → selected → restored → business-validated → expired.

D08Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle requested flow → identity/context resolved → policy evaluated → allowed/denied → logged → reviewed → rule retired.

I01Dependencies and integrations. Record prerequisite state for Safeguard 1.1, Safeguard 4.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I07Dependencies and integrations. Require every connector carrying recoverable business service, protected recovery point, trustworthy copy, dependency, recovery objective, and verified restored outcome to preserve tenant, object identity, source time, collection time, completeness, and failure status.

I08Dependencies and integrations. Require every connector carrying intended connectivity, trust zone, route, protocol, identity, management path, traffic decision, and observed outcome to preserve tenant, object identity, source time, collection time, completeness, and failure status.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Enroll devices before access, maintain MDM authority and last contact, separate full-device from selective wipe, require incident authorization and preserve a chain of actions.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C07Control flow and enforcement. Implement the explicit state machine protected object identified → copy created → isolated/verified → retained → selected → restored → business-validated → expired; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

C08Control flow and enforcement. Implement the explicit state machine requested flow → identity/context resolved → policy evaluated → allowed/denied → logged → reviewed → rule retired; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T07Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for protected object identified → copy created → isolated/verified → retained → selected → restored → business-validated → expired; alert before each deadline becomes overdue.

T08Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for requested flow → identity/context resolved → policy evaluated → allowed/denied → logged → reviewed → rule retired; alert before each deadline becomes overdue.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Powered-off, reset, jailbroken, unenrolled and permanently offline devices may never receive the command.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X07Exceptions and failure modes. Treat silent job failure, corrupt source, ransomware reachability, missing key, provider or region loss, quota, partial restore, stale runbook, and clean-room unavailability as named failure or exception paths with an owner, compensating control, expiry, and retest.

X08Exceptions and failure modes. Treat IPv6, overlays, east-west paths, remote and roaming devices, direct egress, alternate resolvers, QUIC, asymmetric routes, provider abstraction, and emergency consoles as named failure or exception paths with an owner, compensating control, expiry, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Use a sacrificial enrolled device to test command authorization, delivery, offline queueing, workspace/full wipe result, token revocation and audit receipt.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 5 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E07Evidence and metrics. Publish protected, missed, failed, stale, corrupt, reachable-by-production, keyless, untested, restore-failed, and business-validated recovery objects with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

E08Evidence and metrics. Publish known, unknown, allowed, denied, shadow, bypassed, asymmetric, stale-rule, exception, and unobserved paths with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S07Security, privacy, and resilience. Restrict authority to change protected object identified → copy created → isolated/verified → retained → selected → restored → business-validated → expired; log privileged changes, protect evidence history, and test administrative recovery.

S08Security, privacy, and resilience. Restrict authority to change requested flow → identity/context resolved → policy evaluated → allowed/denied → logged → reviewed → rule retired; log privileged changes, protect evidence history, and test administrative recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V07Verification and adversarial tests. Run the positive control a representative point-in-time restoration that passes data and business checks; exercise negative, stale, duplicate, bypass, and outage controls including failed job, corrupt copy, deletion/encryption attempt, lost key, unavailable provider, dependency omission, partial restore, and missed recovery objective.

V08Verification and adversarial tests. Run the positive control an approved flow over the required secure management or business path; exercise negative, stale, duplicate, bypass, and outage controls including an unapproved route, protocol downgrade, direct egress, alternate DNS/QUIC path, segmentation bypass, AAA loss, stale rule, and rollback failure.

R07Operations, change, and closure. Use protected, missed, failed, stale, corrupt, reachable-by-production, keyless, untested, restore-failed, and business-validated recovery objects to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

R08Operations, change, and closure. Use known, unknown, allowed, denied, shadow, bypassed, asymmetric, stale-rule, exception, and unobserved paths to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

CIS Safeguard 4.12 · Separate Enterprise Workspaces on Mobile End-User Devices · IG3 onward

Population and scope: The boundary separates enterprise applications, identities, data, clipboard, storage, backup and network paths from personal apps and accounts on supported mobile devices. A work profile icon leaves exports, notifications, screenshots, accessibility services and cloud-backup separation unverified.
Implementation and owner: Use managed work profiles or containers, managed app configuration, per-app VPN and data-transfer policies; block unmanaged destinations, personal backups and unauthorized account mixing. Define corporate-owned, COPE and BYOD profiles separately and make access conditional on attested workspace state.
Evidence and negative test: Move test data through copy/paste, share sheets, open-in, screenshots, notifications, backups, keyboards, accessibility and personal cloud applications; verify intended allow/deny behavior and selective wipe. Measure eligible devices with healthy effective policy, not just an MDM agent.
Exception and failure boundary: Platform capabilities differ by OS version and ownership model. Some leakage paths cannot be fully blocked and require data minimization or browser-only access. The current CAS provides no metric for 4.12, so the organization must declare population, transfer tests, acceptance thresholds and unsupported-device treatment.

PRD implementation register · 72 atomic requirements · 12 dimensions · enforcement

O01Outcome and decision. Define the user, business, and risk outcome for Separate Enterprise Workspaces on Mobile End-User Devices; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 4.12, official Asset Class Data, Security Function Protect, and IG3 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The boundary separates enterprise applications, identities, data, clipboard, storage, backup and network paths from personal apps and accounts on supported mobile devices.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Separate Enterprise Workspaces on Mobile End-User Devices to its operating object—role-specific secure baselines and effective configurations for endpoints, servers, mobile, cloud, network, software, and administrative paths—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Separate Enterprise Workspaces on Mobile End-User Devices, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Use managed work profiles or containers, managed app configuration, per-app VPN and data-transfer policies; block unmanaged destinations, personal backups and unauthorized account mixing.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Platform capabilities differ by OS version and ownership model.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Move test data through copy/paste, share sheets, open-in, screenshots, notifications, backups, keyboards, accessibility and personal cloud applications; verify intended allow/deny behavior and selective wipe.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 0 pinned CAS metric branch(es), 9 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

4 Identity, vulnerability, telemetry, and user-facing defenses

Controls 5–10 connect identities to permissions, software state to repair, and system behavior to usable evidence. The implementation test follows an identity or asset through the whole path; a central product is useful only when local and fallback paths produce the same decision.

4.1 Control 5: Account Management

Control 5 establishes identity populations before access decisions can be trusted. Human, administrator and service identities need stable owners and lifecycle records across central, local, cloud, SaaS and recovery stores; federation never erases a local account that can still authenticate.

Account type changes the evidence. Workforce inactivity can use sign-in and HR events, while a workload may run rarely and needs deployment binding, credential rotation and observed-use evidence. Dedicated administrators need both identity separation and a clean administrative computing path.

Primary measurement reference: official CAS Control 5; the cards below add an independent implementation boundary to that control.

CIS Safeguard 5.1 · Establish and Maintain an Inventory of Accounts · IG1 onward

Population and scope: Include all human, administrator and service accounts in directories, local systems, applications, databases, cloud/SaaS tenants, CI/CD, devices and provider portals, whether interactive, federated, dormant, disabled or emergency. Alias and federation records must resolve to the effective person or workload without hiding local bypass accounts.
Implementation and owner: Reconcile authoritative HR/vendor/workload sources with every authentication system at least quarterly and on lifecycle events. Record immutable account ID, type, owner/person, department or system, purpose, privilege, source, creation/start/stop, status and last review; preserve disabled records as audit evidence.
Evidence and negative test: Enumerate accounts independently from identity systems and compare both directions to the register. Create, transfer and terminate test identities, including a local and federated account, and verify authorization, metadata, disablement and audit preservation within SLOs.
Exception and failure boundary: The current CAS formulas divide complete accounts by two and label unauthorized accounts as “accuracy,” producing invalid results. Shared, orphaned, guest, provider and emergency identities need owners and end dates. An account absent from the central directory is not out of scope when it can authenticate.

PRD implementation register · 96 atomic requirements · 12 dimensions · identity, inventory · expanded complexity

O01Outcome and decision. Define the user, business, and risk outcome for Establish and Maintain an Inventory of Accounts; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 5.1, official Asset Class Users, Security Function Identify, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Include all human, administrator and service accounts in directories, local systems, applications, databases, cloud/SaaS tenants, CI/CD, devices and provider portals, whether interactive, federated, dormant, disabled or emergency.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Establish and Maintain an Inventory of Accounts to its operating object—human, administrative, service, workload, device, emergency, provider, and shared or default account identities—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Establish and Maintain an Inventory of Accounts, express success as an observable decision over effective identity, authentication, authorization, privilege, session, and revocation state across every access path; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Establish and Maintain an Inventory of Accounts, express success as an observable decision over observed, approved, unapproved, ownerless, stale, duplicate, and retired object identity; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For the expanded Establish and Maintain an Inventory of Accounts scope, resolve conflicts among security, safety, privacy, legal, availability, customer, and operational objectives through an explicit risk decision.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P05Population and applicability. Resolve applicability across dormant, orphaned, shared, default, break-glass, non-interactive, federated, cross-tenant, and ownerless accounts; each edge receives an evidenced in-scope, out-of-scope, unknown, or time-bounded exception result.

P06Population and applicability. Include shared and service identities, nested groups, direct grants, cached sessions, federation gaps, recovery channels, API keys, emergency access, and provider support in applicability and assign every object an in-scope, out-of-scope, unknown, failed, or exception state.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W05Ownership and approval. Bind identity governance, HR, managers, application and platform owners, PAM operators, service owners, and security to a RACI for the Safeguard and name the authority that resolves conflicting source or risk decisions.

W06Ownership and approval. Name who may transition requested → approved → provisioned → exercised → reviewed → changed/revoked → session and token invalidated, who approves the transition, who supplies evidence, and who independently reviews it.

W08Ownership and approval. Model delegated authority, quorum or dual approval where warranted, escalation deadlines, provider handoffs, conflict resolution, and executive risk acceptance.

D03Data contract and identity. Map the pinned CAS variable set (GV5, GV22, GV23, M1, M2, M3, M4, M5, M6, M7, M8, M9) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D05Data contract and identity. Use the authoritative account inventory and identity lifecycle as the governed current-state record; persist identity, owner, provenance, prior/new state, reason, actor, time, and exception link.

D06Data contract and identity. Persist stable identity, source provenance, timestamp, actor, reason, and prior/new state for the lifecycle requested → approved → provisioned → exercised → reviewed → changed/revoked → session and token invalidated.

D08Data contract and identity. Version schemas and state transitions with migration, backfill, deduplication, lineage, historical denominator, deletion, and rollback semantics.

I01Dependencies and integrations. Record prerequisite state for Safeguard 2.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I05Dependencies and integrations. Reconcile HR/workforce systems, directories, IAM, cloud tenants, PAM, application databases, secrets platforms, provider consoles, and authentication logs and expose source-specific health, latency, confidence, omissions, and conflict resolution.

I06Dependencies and integrations. Require every connector carrying effective identity, authentication, authorization, privilege, session, and revocation state across every access path to preserve tenant, object identity, source time, collection time, completeness, and failure status.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Reconcile authoritative HR/vendor/workload sources with every authentication system at least quarterly and on lifecycle events.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C05Control flow and enforcement. Implement the state transition in the authoritative account inventory and identity lifecycle and preserve the exact operating control point, policy or procedure version, result, and downstream update.

C06Control flow and enforcement. Implement the explicit state machine requested → approved → provisioned → exercised → reviewed → changed/revoked → session and token invalidated; define validation, idempotency, retry, concurrency, rollback, and closure for each transition.

T01Timing and lifecycle. Preserve the official cadence terms found in the pinned description (quarterly); define faster local SLOs where asset change, exposure, safety, or threat consequence requires them.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T05Timing and lifecycle. Set freshness and action SLOs from the rate of change in human, administrative, service, workload, device, emergency, provider, and shared or default account identities; source age, queue age, exception age, and closure age remain separate clocks.

T06Timing and lifecycle. Set detection, decision, action, freshness, review, and expiry SLOs for requested → approved → provisioned → exercised → reviewed → changed/revoked → session and token invalidated; alert before each deadline becomes overdue.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “The current CAS formulas divide complete accounts by two and label unauthorized accounts as “accuracy,” producing invalid results.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X05Exceptions and failure modes. Treat dormant, orphaned, shared, default, break-glass, non-interactive, federated, cross-tenant, and ownerless accounts as designed non-happy paths with an owner, compensating control, expiry, safety or business constraint, and retest.

X06Exceptions and failure modes. Treat shared and service identities, nested groups, direct grants, cached sessions, federation gaps, recovery channels, API keys, emergency access, and provider support as named failure or exception paths with an owner, compensating control, expiry, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Enumerate accounts independently from identity systems and compare both directions to the register.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 12 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E05Evidence and metrics. Derive coverage and effectiveness from the authoritative account inventory and identity lifecycle plus independent source receipts; report unknown, stale, conflicting, failed, and excepted objects separately.

E06Evidence and metrics. Publish requested, approved, effective, excessive, orphaned, stale, emergency, revoked-but-active, and independently reviewed rights with query version, denominator timestamp, exclusions, unknowns, and drill-down receipts.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S05Security, privacy, and resilience. Protect write and approval authority over the authoritative account inventory and identity lifecycle; monitor privileged changes, exports, deletions, source disablement, and recovery.

S06Security, privacy, and resilience. Restrict authority to change requested → approved → provisioned → exercised → reviewed → changed/revoked → session and token invalidated; log privileged changes, protect evidence history, and test administrative recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V05Verification and adversarial tests. Exercise joiner, mover, leaver, dormant and orphan accounts, default credentials, privilege separation, secret rotation, and directory outage through representative platforms and verify business behavior, control decision, telemetry, case workflow, rollback, and final state.

V06Verification and adversarial tests. Run the positive control an authorized identity using the required assurance and least privilege; exercise negative, stale, duplicate, bypass, and outage controls including an unauthorized identity, missing factor, stale session, direct grant, inherited excess, revoked token, and recovery bypass.

R05Operations, change, and closure. Re-run reconciliation and affected tests whenever HR/workforce systems, directories, IAM, cloud tenants, PAM, application databases, secrets platforms, provider consoles, and authentication logs change ownership, schema, coverage, provider, policy, or platform version.

R06Operations, change, and closure. Use requested, approved, effective, excessive, orphaned, stale, emergency, revoked-but-active, and independently reviewed rights to drive backlog, renewal, incident handling, trend review, and retirement; recurrence reopens root-cause work.

CIS Safeguard 5.2 · Use Unique Passwords · IG1 onward

Population and scope: Every password-bearing account must use a secret not reused by another enterprise or personal account; cover users, local admins, devices, applications and break-glass identities. CIS gives length floors of eight characters with MFA and 14 without, while stronger modern policy should also screen compromised values and avoid predictable rotations.
Implementation and owner: Use an identity platform/password manager to generate and store unique secrets, block known-compromised and default passwords, rate-limit guessing, and migrate service accounts to managed keys or workload identity. Protect reset and recovery paths as strongly as sign-in; never collect plaintext for compliance.
Evidence and negative test: Test policy at creation, change, reset and imported-account paths with short, known-breached and reused canary passwords where safe. Review effective enforcement and credential-compromise events, not a policy document alone; verify help-desk and legacy protocols cannot bypass length or MFA assumptions.
Exception and failure boundary: Uniqueness across systems cannot be proven by reversible comparison without creating risk; enforce generation and monitor exposure instead. MFA does not make eight-character shared passwords acceptable. Legacy maximum lengths, hard-coded devices and emergency accounts require vaulted random secrets, access monitoring and replacement plans.

PRD implementation register · 72 atomic requirements · 12 dimensions · identity

O01Outcome and decision. Define the user, business, and risk outcome for Use Unique Passwords; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 5.2, official Asset Class Users, Security Function Protect, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Every password-bearing account must use a secret not reused by another enterprise or personal account; cover users, local admins, devices, applications and break-glass identities.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Use Unique Passwords to its operating object—human, administrative, service, workload, device, emergency, provider, and shared or default account identities—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Use Unique Passwords, express success as an observable decision over effective identity, authentication, authorization, privilege, session, and revocation state across every access path; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV20, M1, M2, M3, M4, M5) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Use an identity platform/password manager to generate and store unique secrets, block known-compromised and default passwords, rate-limit guessing, and migrate service accounts to managed keys or workload identity.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Uniqueness across systems cannot be proven by reversible comparison without creating risk; enforce generation and monitor exposure instead.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Test policy at creation, change, reset and imported-account paths with short, known-breached and reused canary passwords where safe.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 6 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 5.3 · Disable Dormant Accounts · IG1 onward

Population and scope: The population includes enabled human, administrative, guest, local, cloud, SaaS and service identities whose last meaningful activity can be determined. CIS calls for disablement or deletion after 45 inactive days where supported, but planned leave, emergency and non-interactive schedules need explicit semantics.
Implementation and owner: Define activity per account type, calculate dormancy from reliable sign-in/use events, notify owners, disable before deletion and preserve audit links. Run at least daily or frequently enough to meet 45 days; excluded emergency/service identities receive use monitoring and scheduled owner recertification.
Evidence and negative test: Create a canary account, advance or simulate inactivity, and verify notification, disablement, session/token revocation and blocked sign-in. Sample last-activity accuracy across federated and local systems; measure enabled dormant accounts over all dormant accounts, with unknown activity separated.
Exception and failure boundary: A password change, background token refresh or failed login may falsely appear active; an account can also remain dangerous while never signing in. Maternity/medical leave needs suspension and reactivation workflow. Service accounts belong to 5.5 lifecycle even when no interactive “last login” exists.

PRD implementation register · 84 atomic requirements · 12 dimensions · identity, enforcement

O01Outcome and decision. Define the user, business, and risk outcome for Disable Dormant Accounts; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 5.3, official Asset Class Users, Security Function Protect, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The population includes enabled human, administrative, guest, local, cloud, SaaS and service identities whose last meaningful activity can be determined.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Disable Dormant Accounts to its operating object—human, administrative, service, workload, device, emergency, provider, and shared or default account identities—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Disable Dormant Accounts, express success as an observable decision over effective identity, authentication, authorization, privilege, session, and revocation state across every access path; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Disable Dormant Accounts, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV22, M1, M2, M3, M4, M5, M6) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 5.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Define activity per account type, calculate dormancy from reliable sign-in/use events, notify owners, disable before deletion and preserve audit links.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T01Timing and lifecycle. Preserve the official cadence terms found in the pinned description (45 days); define faster local SLOs where asset change, exposure, safety, or threat consequence requires them.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “A password change, background token refresh or failed login may falsely appear active; an account can also remain dangerous while never signing in.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Create a canary account, advance or simulate inactivity, and verify notification, disablement, session/token revocation and blocked sign-in.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 7 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 5.4 · Restrict Administrator Privileges to Dedicated Administrator Accounts · IG1 onward

Population and scope: Cover every human with elevated authority across endpoint, server, network, cloud, SaaS, database, CI/CD and security tooling. The same person may hold user and admin identities, but ordinary browsing, email and productivity activity must occur under the non-privileged identity.
Implementation and owner: Issue named dedicated admin accounts, require strong MFA and privileged workstations or paths, remove elevation from daily accounts, and use just-in-time or task-scoped privilege where possible. Separate tiers so compromise of one admin context does not grant every layer; log elevation and break-glass use.
Evidence and negative test: Attempt ordinary email/web access from an admin identity, administrative action from the daily identity, and cross-tier access; verify policy and alerts. Enumerate effective privilege independently from account labels and reconcile every privileged identity to an authorized administrator and non-privileged working account.
Exception and failure boundary: A dedicated username used on the same contaminated workstation offers limited separation. Local sudo, cloud role assumption and application superuser paths must be included. Non-human privileges belong to service-account governance; emergency accounts remain isolated, vaulted, tested and monitored, with routine use prohibited.

PRD implementation register · 84 atomic requirements · 12 dimensions · identity, enforcement

O01Outcome and decision. Define the user, business, and risk outcome for Restrict Administrator Privileges to Dedicated Administrator Accounts; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 5.4, official Asset Class Users, Security Function Protect, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Cover every human with elevated authority across endpoint, server, network, cloud, SaaS, database, CI/CD and security tooling.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Restrict Administrator Privileges to Dedicated Administrator Accounts to its operating object—human, administrative, service, workload, device, emergency, provider, and shared or default account identities—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Restrict Administrator Privileges to Dedicated Administrator Accounts, express success as an observable decision over effective identity, authentication, authorization, privilege, session, and revocation state across every access path; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Restrict Administrator Privileges to Dedicated Administrator Accounts, express success as an observable decision over an enforceable allow, deny, contain, quarantine, require, remove, or transform decision at the closest reliable control point; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 5.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Issue named dedicated admin accounts, require strong MFA and privileged workstations or paths, remove elevation from daily accounts, and use just-in-time or task-scoped privilege where possible.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “A dedicated username used on the same contaminated workstation offers limited separation.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Attempt ordinary email/web access from an admin identity, administrative action from the daily identity, and cross-tier access; verify policy and alerts.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 7 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 5.5 · Establish and Maintain an Inventory of Service Accounts · IG2 onward

Population and scope: Include non-human identities used by services, workloads, jobs, devices, integrations, bots, RPA, APIs and CI/CD across directories, clouds, SaaS and local systems, including certificates, API keys and federated workload roles. One shared “service account” for many workloads destroys ownership and revocation boundaries.
Implementation and owner: Record owner/team, workload and environment, purpose, privilege, authentication system, credential type/location, creation, rotation/expiry, dependencies and quarterly review. Prefer short-lived workload identity and automatic rotation; bind issuance to deployed workload and decommission with the service.
Evidence and negative test: Enumerate non-human identities and credentials from each authentication/secret system, compare to deployed workloads and owners, and rotate/revoke a canary without outage. Test that an old secret fails and that use from the wrong workload or environment alerts.
Exception and failure boundary: The current CAS repeats the invalid inventory formulas from 5.1 and even tests three required fields against four. Accounts with no interactive login still need observed-use evidence. Vendor integrations, shared API tokens and orphaned CI variables require contract/source mapping, scoped privileges and expiry.

PRD implementation register · 96 atomic requirements · 12 dimensions · identity, inventory · expanded complexity

O01Outcome and decision. Define the user, business, and risk outcome for Establish and Maintain an Inventory of Service Accounts; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 5.5, official Asset Class Users, Security Function Identify, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Include non-human identities used by services, workloads, jobs, devices, integrations, bots, RPA, APIs and CI/CD across directories, clouds, SaaS and local systems, including certificates, API keys and federated workload roles.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Establish and Maintain an Inventory of Service Accounts to its operating object—human, administrative, service, workload, device, emergency, provider, and shared or default account identities—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Establish and Maintain an Inventory of Service Accounts, express success as an observable decision over effective identity, authentication, authorization, privilege, session, and revocation state across every access path; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Establish and Maintain an Inventory of Service Accounts, express success as an observable decision over observed, approved, unapproved, ownerless, stale, duplicate, and retired object identity; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For the expanded Establish and Maintain an Inventory of Service Accounts scope, resolve conflicts among security, safety, privacy, legal, availability, customer, and operational objectives through an explicit risk decision.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W08Ownership and approval. Model delegated authority, quorum or dual approval where warranted, escalation deadlines, provider handoffs, conflict resolution, and executive risk acceptance.

D03Data contract and identity. Map the pinned CAS variable set (GV23, M1, M2, M3, M4, M5, M6, M7, M8, M9) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D08Data contract and identity. Version schemas and state transitions with migration, backfill, deduplication, lineage, historical denominator, deletion, and rollback semantics.

I01Dependencies and integrations. Record prerequisite state for Safeguard 6.6; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Record owner/team, workload and environment, purpose, privilege, authentication system, credential type/location, creation, rotation/expiry, dependencies and quarterly review.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “The current CAS repeats the invalid inventory formulas from 5.1 and even tests three required fields against four.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Enumerate non-human identities and credentials from each authentication/secret system, compare to deployed workloads and owners, and rotate/revoke a canary without outage.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 2 pinned CAS metric branch(es), 10 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

CIS Safeguard 5.6 · Centralize Account Management · IG2 onward

Population and scope: Centralization applies to identities that supported systems can delegate to a directory or identity provider, across workforce, cloud and SaaS. It does not mean one failure domain for every trust tier, nor does an SSO tile prove local accounts and recovery paths are controlled.
Implementation and owner: Select authoritative identity services, federate applications, automate lifecycle and group/role provisioning, restrict local account creation, and maintain resilient break-glass access. Separate workforce, privileged, customer and workload identity where their assurance, availability or privacy requirements differ.
Evidence and negative test: Inventory every authentication point, test central disablement and role change through representative applications, and try a local/login recovery bypass. Measure eligible applications with enforced federation and lifecycle, plus remaining local accounts and unintegrated systems; test identity-provider outage and recovery.
Exception and failure boundary: Legacy, OT and isolated systems may need local identities with compensating vaulting and reconciliation. Centralization can amplify compromise and outage, so admin separation, conditional access, logs and tested continuity are required. Multiple necessary identity domains are valid when their boundary is deliberate and governed.

PRD implementation register · 72 atomic requirements · 12 dimensions · identity

O01Outcome and decision. Define the user, business, and risk outcome for Centralize Account Management; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 5.6, official Asset Class Users, Security Function Govern, and IG2 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Centralization applies to identities that supported systems can delegate to a directory or identity provider, across workforce, cloud and SaaS.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Centralize Account Management to its operating object—human, administrative, service, workload, device, emergency, provider, and shared or default account identities—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Centralize Account Management, express success as an observable decision over effective identity, authentication, authorization, privilege, session, and revocation state across every access path; name the business effect of each accepted, rejected, and unresolved state.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

D03Data contract and identity. Map the pinned CAS variable set (GV1, M1, M2, M3) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

I01Dependencies and integrations. Record prerequisite state for Safeguard 1.1, Safeguard 2.1; add locally required dependencies and justify every omitted or substituted predecessor.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Select authoritative identity services, federate applications, automate lifecycle and group/role provisioning, restrict local account creation, and maintain resilient break-glass access.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “Legacy, OT and isolated systems may need local identities with compensating vaulting and reconciliation.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Inventory every authentication point, test central disablement and role change through representative applications, and try a local/login recovery bypass.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 4 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

4.2 Control 6: Access Control Management

Control 6 follows access from request to effective permission and finally revocation. The strongest receipt is a tested resource decision: the intended identity succeeds, the disallowed identity and alternate path fail, and termination removes active sessions, keys and local fallbacks within the promised time.

Central identity, MFA and RBAC reduce inconsistency while introducing a high-consequence dependency. Resilient break-glass, separated administration and resource-level authorization are part of the design; an SSO tile or MFA prompt at one front door cannot cover a direct administrative or recovery route.

Primary measurement reference: official CAS Control 6; the cards below add an independent implementation boundary to that control.

CIS Safeguard 6.1 · Establish an Access Granting Process · IG1 onward

Population and scope: The process covers employees, contractors, guests, partners, service identities and administrators gaining access through new hire, new workload, role or project change and emergency need. It must reach every authoritative system, including local and provider-managed privileges outside central provisioning.
Implementation and owner: Require identified requester, owner/manager approval, business purpose, role or entitlement, start/end time, segregation-of-duties check and target system; automate from authoritative events and make privileged or sensitive access expire by default. Preserve who approved and the exact effective entitlement.
Evidence and negative test: Run canary new-hire, transfer, temporary and emergency requests, then compare approved access with effective accounts, groups, roles, keys and sessions at the promised time. Sample denials and rejected conflicts as well as successful grants; track late, excess and manually bypassed access.
Exception and failure boundary: A completed ticket is not a grant receipt, and group membership may yield hidden nested privilege. Pre-authorized birthright access still needs documented role logic. Service-provider support, shared links and data exports are access paths; emergency grants are logged, time-bounded and reviewed after use.

PRD implementation register · 96 atomic requirements · 12 dimensions · identity, governance · expanded complexity

O01Outcome and decision. Define the user, business, and risk outcome for Establish an Access Granting Process; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 6.1, official Asset Class Documentation, Security Function Govern, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “The process covers employees, contractors, guests, partners, service identities and administrators gaining access through new hire, new workload, role or project change and emergency need.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Establish an Access Granting Process to its operating object—effective entitlements for human, service, workload, provider, emergency, and delegated identities across every access path—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Establish an Access Granting Process, express success as an observable decision over effective identity, authentication, authorization, privilege, session, and revocation state across every access path; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Establish an Access Granting Process, express success as an observable decision over a documented decision system with policy, process, procedure, accountable owner, approval, and review; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For the expanded Establish an Access Granting Process scope, resolve conflicts among security, safety, privacy, legal, availability, customer, and operational objectives through an explicit risk decision.

P02Population and applicability. Evaluate on-premises, cloud IaaS/PaaS/SaaS, mobile, remote, IoT/OT, build, backup, provider, and AI surfaces whenever the Safeguard's named object exists.

P05Population and applicability. Resolve applicability across direct grants, inherited rights, nested groups, cached sessions, local accounts, API keys, federation failure, unsupported MFA, and emergency access; each edge receives an evidenced in-scope, out-of-scope, unknown, or time-bounded exception result.

W01Ownership and approval. Name the accountable business owner, operating owner, evidence owner, exception approver, independent reviewer, and escalation recipient for this Safeguard.

W02Ownership and approval. Define who may create, change, approve, enforce, pause, roll back, renew an exception, and close the implementation; prevent one actor from self-approving every stage.

W04Ownership and approval. Specify delegation, backup personnel, on-call coverage, decision authority during an incident, and the handover test used when an owner leaves or becomes unavailable.

W05Ownership and approval. Bind resource and data owners, managers, identity teams, platform operators, security, HR, and independent reviewers to a RACI for the Safeguard and name the authority that resolves conflicting source or risk decisions.

W08Ownership and approval. Model delegated authority, quorum or dual approval where warranted, escalation deadlines, provider handoffs, conflict resolution, and executive risk acceptance.

D03Data contract and identity. Map the pinned CAS variable set (M1, M2) to local fields or mark each unavailable variable as unsupported, inapplicable, or unknown with a reason.

D04Data contract and identity. Define null, zero, duplicate, stale, deleted, unreachable, partially observed, and conflicting-source semantics before dashboards or automation consume the data.

D05Data contract and identity. Use the access request, approval, policy, and effective-permission authority as the governed current-state record; persist identity, owner, provenance, prior/new state, reason, actor, time, and exception link.

D08Data contract and identity. Version schemas and state transitions with migration, backfill, deduplication, lineage, historical denominator, deletion, and rollback semantics.

I03Dependencies and integrations. Preserve tenant, region, environment, object identity, source event time, collection time, and source-health state across every connector and normalization hop.

I05Dependencies and integrations. Reconcile HR and ticket workflows, IAM/SSO, directories, application roles, cloud policies, PAM, network access, data ACLs, and provider controls and expose source-specific health, latency, confidence, omissions, and conflict resolution.

C01Control flow and enforcement. Use this implementation claim as the control-flow anchor: “Require identified requester, owner/manager approval, business purpose, role or entitlement, start/end time, segregation-of-duties check and target system; automate from authoritative events and make privileged or sensitive access expire by default.” Decompose it into input, validation, decision, action, recorded outcome, and closure states.

C05Control flow and enforcement. Implement the state transition in the access request, approval, policy, and effective-permission authority and preserve the exact operating control point, policy or procedure version, result, and downstream update.

T02Timing and lifecycle. Set separate SLOs for discovery, ingestion, decision, action, owner acknowledgement, evidence freshness, exception review, verification, and final closure.

T04Timing and lifecycle. Trigger early review after material architecture, provider, policy, software, threat, regulation, ownership, data-use, incident, or control-source change.

T05Timing and lifecycle. Set freshness and action SLOs from the rate of change in effective entitlements for human, service, workload, provider, emergency, and delegated identities across every access path; source age, queue age, exception age, and closure age remain separate clocks.

X01Exceptions and failure modes. Use this failure-boundary claim as a required exception test: “A completed ticket is not a grant receipt, and group membership may yield hidden nested privilege.” Convert every condition into a detectable state and response.

X04Exceptions and failure modes. Return expired or weakened exceptions to failure; reopen the root cause when the same object or acquisition path recurs after closure.

X05Exceptions and failure modes. Treat direct grants, inherited rights, nested groups, cached sessions, local accounts, API keys, federation failure, unsupported MFA, and emergency access as designed non-happy paths with an owner, compensating control, expiry, safety or business constraint, and retest.

E01Evidence and metrics. Use this verification claim as the first acceptance receipt: “Run canary new-hire, transfer, temporary and emergency requests, then compare approved access with effective accounts, groups, roles, keys and sessions at the promised time.” Retain the inputs, procedure, expected result, observed result, actor, time, and artifact identity.

E03Evidence and metrics. Reconcile 1 pinned CAS metric branch(es), 2 named measure or global variable(s), assumption state, and local operating-effectiveness evidence before automating a score.

E05Evidence and metrics. Derive coverage and effectiveness from the access request, approval, policy, and effective-permission authority plus independent source receipts; report unknown, stale, conflicting, failed, and excepted objects separately.

S04Security, privacy, and resilience. Define capacity, quota, dependency, regional, provider, offline, and disaster behavior; preserve a tested degraded-mode decision and recovery path.

S05Security, privacy, and resilience. Protect write and approval authority over the access request, approval, policy, and effective-permission authority; monitor privileged changes, exports, deletions, source disablement, and recovery.

V01Verification and adversarial tests. Run a legitimate positive control through the real production-equivalent path and verify both business success and the complete evidence receipt.

V05Verification and adversarial tests. Exercise allowed and denied identities, joiner/mover/leaver changes, step-up and recovery paths, session revocation, privilege escalation, and policy outage through representative platforms and verify business behavior, control decision, telemetry, case workflow, rollback, and final state.

R05Operations, change, and closure. Re-run reconciliation and affected tests whenever HR and ticket workflows, IAM/SSO, directories, application roles, cloud policies, PAM, network access, data ACLs, and provider controls change ownership, schema, coverage, provider, policy, or platform version.

CIS Safeguard 6.2 · Establish an Access Revoking Process · IG1 onward

Population and scope: Scope termination, contract end, role/project change, rights removal, compromise and emergency containment for accounts, groups, roles, sessions, tokens, keys, devices, sharing links and physical/remote paths. Disabling one directory account may leave active SaaS sessions or local credentials.
Implementation and owner: Trigger immediate termination disablement and risk-based revocation SLOs, propagate to all authentication and authorization systems, revoke sessions/keys, recover assets and transfer ownership. Preserve the identity record for audit while removing effective access; automate reconciliation and escalate failures.
Evidence and negative test: Simulate termination and role change for federated, local, mobile, cloud and service access; verify sign-in, existing sessions, API tokens, group inheritance and recovery paths all fail or change on time. Measure effective closure across systems, not HR-ticket completion.
Exception and failure boundary: Legal hold preserves data and logs, not access. Offline devices, provider delays and immutable credentials require network denial or key rotation. Shared accounts make individual revocation impossible and are a design defect; emergency access opened during an incident must have an automatic expiry and retrospective review.

PRD implementation register · 96 atomic requirements · 12 dimensions · identity, governance · expanded complexity

O01Outcome and decision. Define the user, business, and risk outcome for Establish an Access Revoking Process; name the protected decision and the observable state change produced by this Safeguard.

O02Outcome and decision. Bind every backlog item to CIS Safeguard 6.2, official Asset Class Documentation, Security Function Govern, and IG1 first appearance; retain the source retrieval date.

O03Outcome and decision. Use this original local scope claim as the starting contract: “Scope termination, contract end, role/project change, rights removal, compromise and emergency containment for accounts, groups, roles, sessions, tokens, keys, devices, sharing links and physical/remote paths.” Convert each object in the claim into a queryable population or an approved applicability decision.

O05Outcome and decision. Connect Establish an Access Revoking Process to its operating object—effective entitlements for human, service, workload, provider, emergency, and delegated identities across every access path—and define the security decision, business consequence, and residual risk for every terminal state.

O06Outcome and decision. For Establish an Access Revoking Process, express success as an observable decision over effective identity, authentication, authorization, privilege, session, and revocation state across every access path; name the business effect of each accepted, rejected, and unresolved state.

O07Outcome and decision. For Establish an Access Revoking Process, express success as an observable decision over a documented decision system with policy, process, procedure, accountable owner, approval, and review; name the business effect of each accepted, rejected, and unresolved state.

O08Outcome and decision. For the expanded Establish an Access Revoking Process scope, resolve conflicts among security, safety, privacy, legal, availability, customer, and operational objectives through an explicit risk decision.