{
  "framework": "ASOM-Fed",
  "version": "3.0",
  "inherits": "NIST SP 800-53 Rev. 5",
  "families": [
    {
      "id": "TM",
      "name": "Terrain Management",
      "description": "Know the ground before you defend it. These controls establish and maintain an authoritative picture of what exists, what it is worth, and how it connects."
    },
    {
      "id": "KT",
      "name": "Key Terrain and Decisive Points",
      "description": "Not all ground is equal. These controls identify the elements whose loss unhinges the defence, and prove whether an adversary can reach them."
    },
    {
      "id": "SM",
      "name": "Scheme of Maneuver",
      "description": "Defensive moves are chosen deliberately, assigned to specific ground, and tracked to an implementation state — not assumed because a product was purchased."
    },
    {
      "id": "TA",
      "name": "Tempo and Temporal Advantage",
      "description": "The decisive question is whether the defender can decide and act faster than the adversary can achieve their objective. These controls make tempo measurable and authorised."
    },
    {
      "id": "CE",
      "name": "Cycle Execution and Assurance",
      "description": "The framework is a loop, not a document. These controls govern cadence, intelligence requirements, computation of posture, and the evidentiary record."
    },
    {
      "id": "CG",
      "name": "Command and Governance",
      "description": "Intent, phase, and rules of engagement are set by an accountable authority, and findings are dispositioned rather than admired."
    },
    {
      "id": "RC",
      "name": "Reconstitution and Recovery",
      "description": "A defence that cannot restore the mission has only deferred the loss. These controls make recovery a rehearsed capability held outside the blast radius, and require it to be proven rather than planned."
    },
    {
      "id": "FO",
      "name": "Federal Obligations",
      "description": "Terrain that exists because the organisation is a federal one. These controls name the ground that statute, authorising legislation, and the federal operating model put on the map — privacy, CUI, shared tenancy, operational technology, statutory availability, and the supply chain — so that obligations are defended as terrain rather than tracked as paperwork."
    },
    {
      "id": "WF",
      "name": "Workforce Terrain",
      "description": "The people who operate the estate are terrain: they can be reconnoitred, targeted, turned, and lost. These controls put the workforce on the map — who holds authority, who is trusted with what, and how fast that trust can be withdrawn."
    },
    {
      "id": "FC",
      "name": "Facilities Terrain",
      "description": "Physical ground is the oldest terrain there is, and the one federal estates most often leave off the overlay. These controls cover the buildings, the zones inside them, the maintenance paths that reach through them, and the environmental conditions the mission depends on."
    },
    {
      "id": "LC",
      "name": "Lines of Communication",
      "description": "Suppliers, integrators and software components are the routes by which the estate is resupplied, and therefore the routes by which it is reached. These controls treat them as ground to be registered, constrained, watched, and cut when necessary."
    }
  ],
  "controls": [
    {
      "id": "TM-1",
      "family": "TM",
      "title": "Terrain Inventory and Overlay",
      "statement": "The organisation shall maintain a current graphical overlay of all systems, data stores, and external actors within the authorisation boundary, including the trust zones in which they reside.",
      "discussion": "A register in a spreadsheet is not terrain. Terrain is positional: it records where an element sits relative to boundaries and to other elements, because position determines how an adversary moves. The overlay is the single artefact from which every other ASOM product is derived.",
      "apply": "Build the architecture on the canvas; group elements into trust zones representing real boundaries.",
      "evidence": "Cyber Terrain Overlay (Figure 1 of the Brief); exported diagram source.",
      "assessment": "Examine the overlay; interview the architecture owner; compare against the authoritative asset inventory for completeness.",
      "inherits": [
        "CM-8",
        "PM-5",
        "RA-9"
      ],
      "csf": [
        "ID.AM-01",
        "ID.AM-03"
      ]
    },
    {
      "id": "TM-2",
      "family": "TM",
      "title": "Defensive Layer Classification",
      "statement": "Every element on the terrain shall be classified to exactly one defensive layer: identity, devices, networks, applications and workloads, or data.",
      "discussion": "Classification is what allows posture to be rolled up and compared. It also forces an explicit decision about which control domain owns each element, eliminating the orphaned assets that appear in most inventories.",
      "apply": "Set the defensive layer in the Inspector for each node; unclassified elements are flagged automatically.",
      "evidence": "Asset Register, \"Defensive layer\" column.",
      "assessment": "Examine the register for unclassified elements; test that layer totals reconcile to the full inventory.",
      "inherits": [
        "CM-8(1)",
        "RA-2"
      ],
      "csf": [
        "ID.AM-05"
      ]
    },
    {
      "id": "TM-3",
      "family": "TM",
      "title": "Asset Weighting",
      "statement": "Each element shall carry a defensive weight derived from its criticality to the mission and its exposure to untrusted actors, on a defined and consistently applied scale.",
      "discussion": "Weighting converts an undifferentiated inventory into a priority order. Without it, coverage percentages are misleading: protecting fifty low-value assets and leaving one crown jewel exposed can still report high compliance.",
      "apply": "Set criticality and exposure (1–5) per asset; weight is computed as their product.",
      "evidence": "Asset Register, weight column; total defensive weight in the Brief.",
      "assessment": "Examine the weighting scale definition; interview owners on two high-weight and two low-weight assets to confirm consistent application.",
      "inherits": [
        "RA-2",
        "RA-3"
      ],
      "csf": [
        "ID.AM-05",
        "ID.RA-05"
      ]
    },
    {
      "id": "TM-4",
      "family": "TM",
      "title": "Trust Zone Definition",
      "statement": "Trust zones shall be defined with explicit boundaries, and every element shall reside within a declared zone.",
      "discussion": "Zones make the boundary assumptions of the architecture visible and testable. An element outside any zone is an unexamined assumption.",
      "apply": "Draw zones on the canvas and place elements inside them; use the pack-into-zones tool to enforce containment.",
      "evidence": "Terrain overlay showing zone membership.",
      "assessment": "Examine the overlay for elements outside declared zones; test boundary enforcement against network configuration.",
      "inherits": [
        "SC-7",
        "AC-4"
      ],
      "csf": [
        "PR.IR-01"
      ]
    },
    {
      "id": "TM-5",
      "family": "TM",
      "title": "Connection and Denied-Path Register",
      "statement": "All permitted connections between elements shall be recorded, and paths that are deliberately blocked shall be recorded distinctly as denied paths.",
      "discussion": "Most architectures document what is allowed. Recording what is deliberately denied is what makes a defensive claim falsifiable, and is the input to reachability analysis.",
      "apply": "Draw connections and set each to permitted flow, denied path, or observation.",
      "evidence": "Connection register; denied paths rendered distinctly on the overlay.",
      "assessment": "Examine the register; test a sample of denied paths against firewall or policy configuration to confirm they are enforced.",
      "inherits": [
        "AC-4",
        "SC-7(5)",
        "CA-3"
      ],
      "csf": [
        "PR.IR-01",
        "ID.AM-03"
      ]
    },
    {
      "id": "TM-6",
      "family": "TM",
      "title": "Terrain Currency",
      "statement": "The terrain overlay shall be refreshed at a defined cadence and upon any material architectural change.",
      "discussion": "A stale overlay is worse than none, because it produces confident conclusions from wrong inputs. Currency is the control that keeps every downstream computation honest.",
      "apply": "Record each cycle in the Cycle tab; the history shows the refresh interval.",
      "evidence": "Cycle history with dates; snapshot series.",
      "assessment": "Examine cycle dates against the defined cadence; interview on the change-triggered refresh process.",
      "inherits": [
        "CM-8(1)",
        "CA-7"
      ],
      "csf": [
        "ID.AM-08",
        "ID.IM-03"
      ]
    },
    {
      "id": "TM-7",
      "family": "TM",
      "title": "Terrain Ownership",
      "statement": "Every element shall have a named accountable owner recorded against it.",
      "discussion": "Unowned assets are the ones that do not get patched, reviewed, or defended. Ownership is what converts a finding into an action with a name attached.",
      "apply": "Set the accountable owner in the Inspector; unowned elements raise a finding automatically.",
      "evidence": "Asset Register owner column; open findings list.",
      "assessment": "Examine the register for unowned elements; interview a sample of named owners to confirm they accept accountability.",
      "inherits": [
        "CM-8(4)",
        "PM-5"
      ],
      "csf": [
        "GV.RR-02"
      ]
    },
    {
      "id": "KT-1",
      "family": "KT",
      "title": "Decisive Point Identification",
      "statement": "The organisation shall identify and designate the elements whose compromise would unhinge the wider defence, and shall justify each designation.",
      "discussion": "Decisive points are not simply the highest-value assets. They are the elements whose control confers disproportionate advantage — typically the identity decision point, the build pipeline, and the primary data objective. Designation drives protection minimums.",
      "apply": "Flag decisive points in the Inspector; they render with a star on the overlay.",
      "evidence": "Key Terrain section of the Brief with justification per element.",
      "assessment": "Examine designations and justifications; interview the CISO on why non-designated high-weight assets were excluded.",
      "inherits": [
        "RA-9",
        "CP-2(8)",
        "PM-11"
      ],
      "csf": [
        "ID.AM-05",
        "ID.RA-04"
      ]
    },
    {
      "id": "KT-2",
      "family": "KT",
      "title": "Decisive Point Protection Floor",
      "statement": "Every designated decisive point shall have at least one defensive move assigned and operational, and shall meet a defined minimum effective coverage.",
      "discussion": "This is the single most enforceable control in the framework. It converts \"we protect what matters\" from an assertion into a testable condition with an automatic finding when breached.",
      "apply": "Assign maneuvers to each starred element; the review engine raises a finding where none exist.",
      "evidence": "Findings list; per-asset maneuver assignment in the Register.",
      "assessment": "Test each decisive point for assigned and operational moves; examine effective coverage against the defined floor.",
      "inherits": [
        "SC-7",
        "AC-6",
        "SI-4"
      ],
      "csf": [
        "PR.AA-05",
        "PR.PS-01"
      ]
    },
    {
      "id": "KT-3",
      "family": "KT",
      "title": "Avenue of Approach Analysis",
      "statement": "The routes by which an adversary could approach designated decisive points shall be enumerated and assessed.",
      "discussion": "Approach analysis shifts assessment from asset-by-asset control checking to path thinking, which is how intrusions actually unfold.",
      "apply": "Trace routes on the canvas; review the connection register for permitted paths into decisive points.",
      "evidence": "Adversary reach analysis; traced route figures.",
      "assessment": "Examine enumerated avenues; test that each has either a barrier or a compensating detection.",
      "inherits": [
        "RA-3",
        "CA-8",
        "RA-5"
      ],
      "csf": [
        "ID.RA-01"
      ]
    },
    {
      "id": "KT-4",
      "family": "KT",
      "title": "Adversary Reachability Assessment",
      "statement": "The organisation shall determine, on permitted paths only, whether any threat actor position can reach any designated decisive point, and shall record the result each cycle.",
      "discussion": "This is the framework's headline assurance statement. It is computed, not asserted, and it changes the moment the architecture changes — which is precisely what a point-in-time assessment cannot offer.",
      "apply": "Run the adversary route tracer; the result reports either a route or the denied paths holding the line.",
      "evidence": "Adversary Reach section of the Brief.",
      "assessment": "Test the reachability computation against the connection register; examine the result trend across cycles.",
      "inherits": [
        "RA-3(4)",
        "CA-8"
      ],
      "csf": [
        "ID.RA-05",
        "DE.AE-07"
      ]
    },
    {
      "id": "KT-5",
      "family": "KT",
      "title": "Barrier Sufficiency",
      "statement": "Where reachability is prevented by denied paths, those barriers shall be identified, enforced technically, and monitored for change.",
      "discussion": "A denied path that exists only on a diagram is a liability, because it produces false assurance. Barriers must be traceable to enforced configuration.",
      "apply": "The tracer highlights the barriers holding the line; record them as controls with owners.",
      "evidence": "Barrier list from route analysis; supporting configuration evidence.",
      "assessment": "Test each barrier against enforcing configuration; examine change-detection coverage on those barriers.",
      "inherits": [
        "SC-7(5)",
        "AC-4",
        "CM-3"
      ],
      "csf": [
        "PR.IR-01",
        "DE.CM-01"
      ]
    },
    {
      "id": "SM-1",
      "family": "SM",
      "title": "Maneuver Catalog Adoption",
      "statement": "The organisation shall adopt a defined catalogue of defensive moves expressed as intent and mechanism rather than as product names.",
      "discussion": "Products are replaced every few years; intent is durable. Expressing the catalogue as intent means the framework survives procurement cycles and lets leaders direct without technical fluency.",
      "apply": "Use the ten-move catalogue as issued, or extend it with locally defined moves in the same form.",
      "evidence": "Adopted catalogue with intent, mechanism, and effectiveness weighting per move.",
      "assessment": "Examine the adopted catalogue; interview leadership on their ability to direct using it.",
      "inherits": [
        "PL-2",
        "PM-7"
      ],
      "csf": [
        "GV.PO-01"
      ]
    },
    {
      "id": "SM-2",
      "family": "SM",
      "title": "Maneuver Assignment",
      "statement": "Defensive moves shall be assigned to specific elements of terrain rather than declared at programme level.",
      "discussion": "A programme-level statement that \"we perform deception\" is unassessable. Assignment to named terrain makes it verifiable and reveals the assets no move actually covers.",
      "apply": "Select an asset and assign moves in the Maneuvers tab; use bulk mode for common patterns.",
      "evidence": "Per-asset maneuver assignment; unprotected-asset report.",
      "assessment": "Examine assignments against the register; test that a sample of assigned moves is genuinely present on that element.",
      "inherits": [
        "PL-2",
        "CA-2"
      ],
      "csf": [
        "PR.PS-01",
        "ID.IM-01"
      ]
    },
    {
      "id": "SM-3",
      "family": "SM",
      "title": "Implementation State Tracking",
      "statement": "Each assigned move shall carry an implementation state of planned, partial, or operational, and only operational moves shall count in full toward risk reduction.",
      "discussion": "This control prevents the most common form of self-deception in security reporting: counting intent as capability. Partial credit for partial implementation keeps the posture number honest.",
      "apply": "Set the state chip on each assigned move; mitigation is weighted accordingly.",
      "evidence": "Implementation state per assignment; effective coverage computation.",
      "assessment": "Test a sample of moves recorded as operational to confirm they are in production and effective.",
      "inherits": [
        "CA-5",
        "PM-4"
      ],
      "csf": [
        "ID.IM-02"
      ]
    },
    {
      "id": "SM-4",
      "family": "SM",
      "title": "Main Effort Designation",
      "statement": "For each phase, the organisation shall designate where defensive priority is concentrated.",
      "discussion": "Everything cannot be the priority. Designating a main effort is what allows resources to be allocated deliberately and what makes trade-offs explicit and reviewable.",
      "apply": "Declare the campaign phase; the main-effort moves for that phase are marked across the canvas.",
      "evidence": "Phase declaration and main-effort statement in the Brief.",
      "assessment": "Examine the designation; interview on how resourcing followed it.",
      "inherits": [
        "PM-11",
        "RA-2"
      ],
      "csf": [
        "GV.RM-01"
      ]
    },
    {
      "id": "SM-5",
      "family": "SM",
      "title": "Branches and Sequels",
      "statement": "Pre-planned contingency maneuvers shall be defined for the most likely and most dangerous adversary courses of action.",
      "discussion": "Decisions made under contact are worse than decisions made in advance. Branches convert incident response from improvisation into selection from a prepared set.",
      "apply": "Record contingency moves against threat courses of action; link to response playbooks.",
      "evidence": "Branch and sequel register; linked response procedures.",
      "assessment": "Examine defined branches; test one through a tabletop exercise.",
      "inherits": [
        "IR-4",
        "CP-2"
      ],
      "csf": [
        "RS.MA-01",
        "ID.IM-02"
      ]
    },
    {
      "id": "SM-6",
      "family": "SM",
      "title": "Maneuver Effectiveness Validation",
      "statement": "The assumed effectiveness of each move shall be validated through exercise, testing, or observed incident performance, and adjusted where evidence contradicts assumption.",
      "discussion": "Effectiveness weightings are assumptions until tested. This control closes the loop between modelled posture and demonstrated posture.",
      "apply": "Adjust effectiveness weightings following exercise results; record the basis.",
      "evidence": "Validation results; adjusted weightings with justification.",
      "assessment": "Examine validation evidence; test that adjustments were reflected in the posture computation.",
      "inherits": [
        "CA-2",
        "CA-8",
        "IR-3"
      ],
      "csf": [
        "ID.IM-02",
        "ID.IM-03"
      ]
    },
    {
      "id": "TA-1",
      "family": "TA",
      "title": "Decision Loop Measurement",
      "statement": "The organisation shall measure the elapsed time from detection through decision to containment, and shall record it each cycle.",
      "discussion": "Tempo is the framework's decisive metric. It is measurable from existing incident records and is the number most predictive of loss, yet it appears in almost no compliance reporting.",
      "apply": "Record defender tempo in the Coverage tab; it feeds the temporal advantage computation.",
      "evidence": "Temporal advantage assessment; supporting incident timing records.",
      "assessment": "Examine the derivation from incident data; test against a sample of recorded incidents.",
      "inherits": [
        "IR-4",
        "SI-4",
        "AU-6"
      ],
      "csf": [
        "DE.AE-06",
        "RS.MA-01"
      ]
    },
    {
      "id": "TA-2",
      "family": "TA",
      "title": "Adversary Dwell Estimation",
      "statement": "The organisation shall maintain a documented estimate of adversary dwell time relevant to its threat profile, with a stated basis.",
      "discussion": "The comparator must be defensible. Estimates drawn from credible threat reporting for the relevant adversary class are sufficient; unsourced numbers are not.",
      "apply": "Record adversary dwell in the Coverage tab with its source.",
      "evidence": "Dwell estimate with cited basis.",
      "assessment": "Examine the source; interview the intelligence function on its applicability.",
      "inherits": [
        "RA-3",
        "PM-16"
      ],
      "csf": [
        "ID.RA-02",
        "ID.RA-03"
      ]
    },
    {
      "id": "TA-3",
      "family": "TA",
      "title": "Temporal Advantage Threshold",
      "statement": "The organisation shall define the minimum acceptable ratio of adversary dwell to defender decision loop, and shall treat a deficit as a reportable condition.",
      "discussion": "This converts tempo from an interesting statistic into a governed threshold with an escalation consequence, which is what distinguishes a metric from a control.",
      "apply": "Set the threshold; the scoreboard reports advantage or deficit against it.",
      "evidence": "Declared threshold; scoreboard result per cycle.",
      "assessment": "Examine the threshold and its approval; test the escalation path on a recorded deficit.",
      "inherits": [
        "IR-4",
        "PM-6"
      ],
      "csf": [
        "GV.RM-02",
        "GV.OV-03"
      ]
    },
    {
      "id": "TA-4",
      "family": "TA",
      "title": "Pre-authorised Response",
      "statement": "Defensive actions that may be executed without escalation shall be defined in advance and approved by the accountable authority.",
      "discussion": "Tempo is lost in approval queues more often than in technology. Pre-authorisation is the single highest-leverage intervention available to most organisations, and it requires governance rather than budget.",
      "apply": "Record pre-authorised actions as rules of engagement; link them to the moves they enable.",
      "evidence": "Approved rules of engagement; escalation matrix.",
      "assessment": "Examine the approval; test that operators executed within authority during a recorded incident.",
      "inherits": [
        "IR-4(2)",
        "AC-2(13)",
        "IR-9"
      ],
      "csf": [
        "RS.MA-01",
        "GV.RR-01"
      ]
    },
    {
      "id": "TA-5",
      "family": "TA",
      "title": "Tempo Degradation Trigger",
      "statement": "Conditions under which the defender decision loop is expected to degrade shall be identified, with compensating measures defined.",
      "discussion": "Analyst saturation, holiday coverage, and major change events predictably slow decision-making. Naming them in advance allows compensation rather than surprise.",
      "apply": "Record degradation conditions and their compensations alongside the tempo measurement.",
      "evidence": "Degradation register with compensating measures.",
      "assessment": "Examine the register; interview operations on a recent period of degraded capacity.",
      "inherits": [
        "IR-4",
        "CP-2",
        "PS-2"
      ],
      "csf": [
        "RS.MA-01",
        "ID.IM-01"
      ]
    },
    {
      "id": "CE-1",
      "family": "CE",
      "title": "Cycle Cadence",
      "statement": "The organisation shall execute the full analytic cycle at a defined cadence and shall not allow the interval to lapse without recorded justification.",
      "discussion": "Cadence is what converts the framework from a project into an operating rhythm, and it is what produces the time series that makes assurance continuous rather than periodic.",
      "apply": "Record each cycle; the history exposes any lapse in interval.",
      "evidence": "Cycle history with dates and phase.",
      "assessment": "Examine cycle records against the defined cadence.",
      "inherits": [
        "CA-7",
        "PM-31"
      ],
      "csf": [
        "ID.IM-03",
        "GV.OV-01"
      ]
    },
    {
      "id": "CE-2",
      "family": "CE",
      "title": "Priority Intelligence Requirements",
      "statement": "Each cycle shall begin with a defined set of priority intelligence requirements that drive collection and hunting.",
      "discussion": "Requirements convert monitoring from passive collection into directed enquiry. They are also the mechanism by which leadership steers the analytic effort.",
      "apply": "Record requirements in the Cycle tab and track each to open, watching, or answered.",
      "evidence": "Intelligence requirement register with status.",
      "assessment": "Examine the register; test that collection or hunting activity addressed a sample of open requirements.",
      "inherits": [
        "PM-16",
        "RA-10",
        "SI-5"
      ],
      "csf": [
        "ID.RA-02",
        "DE.AE-07"
      ]
    },
    {
      "id": "CE-3",
      "family": "CE",
      "title": "Fusion and Confidence",
      "statement": "Analytic conclusions shall be recorded with an explicit confidence level and the basis for that confidence.",
      "discussion": "Unqualified conclusions cannot be governed. Explicit confidence lets a decision-maker calibrate their response and lets a reviewer challenge the reasoning rather than the result.",
      "apply": "Record confidence alongside findings and notes carried into the Brief.",
      "evidence": "Findings with stated confidence.",
      "assessment": "Examine a sample of conclusions for stated confidence and basis; interview analysts on the scale used.",
      "inherits": [
        "RA-3",
        "SI-4(16)",
        "PM-16"
      ],
      "csf": [
        "DE.AE-02",
        "ID.RA-05"
      ]
    },
    {
      "id": "CE-4",
      "family": "CE",
      "title": "Coverage and Residual Risk Computation",
      "statement": "Defensive coverage and residual risk shall be computed from asset weighting, layer maturity, and operational move mitigation, using a documented method.",
      "discussion": "A documented method is what allows the number to be challenged, reproduced, and compared across cycles. An undocumented score is an opinion with a decimal point.",
      "apply": "Coverage and residual risk are computed automatically; the method is stated in this guide.",
      "evidence": "Posture computation in the Brief; documented method.",
      "assessment": "Examine the method; test the computation by recomputing from source inputs.",
      "inherits": [
        "RA-3",
        "CA-2",
        "PM-9"
      ],
      "csf": [
        "ID.RA-05",
        "GV.RM-02"
      ]
    },
    {
      "id": "CE-5",
      "family": "CE",
      "title": "Remediation Backlog Prioritisation",
      "statement": "Identified gaps shall be ranked by the residual risk they retire per unit of effort, and shall be assigned owners and target dates.",
      "discussion": "Ranking by risk retired rather than by ease or by finding count is what stops remediation programmes from optimising the wrong thing.",
      "apply": "The backlog is generated and ranked automatically; assign owners and dates.",
      "evidence": "Ranked backlog with owners and target dates.",
      "assessment": "Examine the ranking basis; test progress against target dates.",
      "inherits": [
        "CA-5",
        "RA-7",
        "PM-4"
      ],
      "csf": [
        "ID.RA-06",
        "ID.IM-02"
      ]
    },
    {
      "id": "CE-6",
      "family": "CE",
      "title": "Cycle Record and Trend",
      "statement": "Each cycle shall be recorded with its posture result, and the trend across cycles shall be reported.",
      "discussion": "A single posture figure says little. The trend is the assurance product, because it demonstrates whether the defence is improving, static, or eroding.",
      "apply": "Record the cycle; history shows coverage and the change since the prior cycle.",
      "evidence": "Cycle history table; movement-over-time section of the Brief.",
      "assessment": "Examine the series for completeness; test two entries against their source computations.",
      "inherits": [
        "CA-7(3)",
        "AU-6",
        "PM-31"
      ],
      "csf": [
        "ID.IM-03",
        "GV.OV-01"
      ]
    },
    {
      "id": "CE-7",
      "family": "CE",
      "title": "Brief Generation and Distribution",
      "statement": "Each cycle shall produce a brief recording terrain, decisive points, scheme of maneuver, posture, findings, and trend, distributed to the accountable authority.",
      "discussion": "The brief is the framework's output of record. Generating it from the live architecture rather than authoring it separately removes the drift between what is documented and what is true.",
      "apply": "Generate the Brief; distribute and retain it as the cycle record.",
      "evidence": "Generated Brief, dated and retained.",
      "assessment": "Examine retained briefs; interview recipients on receipt and use.",
      "inherits": [
        "CA-7",
        "PM-31",
        "PL-2"
      ],
      "csf": [
        "GV.OV-01",
        "ID.IM-03"
      ]
    },
    {
      "id": "CG-1",
      "family": "CG",
      "title": "Defensive Intent",
      "statement": "The accountable authority shall issue a defensive intent stating the end-state to be protected and the risk that is acceptable, expressed in plain language.",
      "discussion": "Intent is what allows subordinate decisions to be made correctly without referral. It is the shortest and most consequential artefact in the framework.",
      "apply": "Record intent; it heads every generated Brief.",
      "evidence": "Signed intent statement.",
      "assessment": "Examine the statement and its approval; interview operators on whether they can act on it unaided.",
      "inherits": [
        "PM-1",
        "PL-1",
        "PM-29"
      ],
      "csf": [
        "GV.OC-01",
        "GV.PO-01"
      ]
    },
    {
      "id": "CG-2",
      "family": "CG",
      "title": "Phase Declaration",
      "statement": "The organisation shall declare its current campaign phase, and shall align main effort and resourcing to it.",
      "discussion": "Phase declaration prevents the common failure of running every capability at constant intensity regardless of conditions, which exhausts teams and blunts response.",
      "apply": "Declare the phase; readiness is scored against the phase main effort.",
      "evidence": "Declared phase; phase readiness score.",
      "assessment": "Examine the declaration and readiness score; interview on resourcing alignment.",
      "inherits": [
        "PM-11",
        "IR-4",
        "CP-2"
      ],
      "csf": [
        "GV.RM-01",
        "ID.IM-01"
      ]
    },
    {
      "id": "CG-3",
      "family": "CG",
      "title": "Rules of Engagement",
      "statement": "The organisation shall maintain approved rules of engagement defining which defensive actions may be executed at which authority level.",
      "discussion": "Rules of engagement are the governance instrument that makes tempo achievable. Without them, pre-authorisation is informal and therefore unreliable under pressure.",
      "apply": "Record the rules and link them to the moves and pre-authorised actions they govern.",
      "evidence": "Approved rules of engagement.",
      "assessment": "Examine approval and currency; test adherence in a recorded incident.",
      "inherits": [
        "IR-4",
        "AC-2",
        "PM-1"
      ],
      "csf": [
        "GV.RR-01",
        "RS.MA-01"
      ]
    },
    {
      "id": "CG-4",
      "family": "CG",
      "title": "Findings Disposition",
      "statement": "Findings raised by architectural review shall be dispositioned as remediated, accepted with justification, or transferred, within a defined period.",
      "discussion": "Findings that accumulate without disposition are the clearest indicator of a governance failure. Explicit acceptance is a legitimate outcome; silence is not.",
      "apply": "Work the findings list; record disposition and rationale.",
      "evidence": "Findings register with disposition and dates.",
      "assessment": "Examine open findings against the defined period; test the justification recorded for accepted risks.",
      "inherits": [
        "CA-5",
        "CA-7",
        "RA-7"
      ],
      "csf": [
        "ID.IM-02",
        "GV.RM-03"
      ]
    },
    {
      "id": "CG-5",
      "family": "CG",
      "title": "Control Inheritance Mapping",
      "statement": "The organisation shall maintain the mapping between these controls and its existing control baseline, and shall assess inherited controls once rather than twice.",
      "discussion": "This control exists to prevent the framework from creating duplicate assessment burden. Where an existing control already satisfies a requirement, it is inherited and cited, not reassessed.",
      "apply": "Maintain the crosswalk in Section 7; cite existing assessment results as evidence where applicable.",
      "evidence": "Maintained crosswalk with inheritance decisions.",
      "assessment": "Examine the crosswalk; test two inherited controls to confirm the cited assessment covers the requirement.",
      "inherits": [
        "PM-10",
        "CA-2",
        "SA-4"
      ],
      "csf": [
        "GV.SC-07",
        "GV.OV-02"
      ]
    },
    {
      "id": "RC-1",
      "family": "RC",
      "title": "Recovery Objectives",
      "statement": "Every mission service shall have a declared recovery time objective and recovery point objective, approved by the service owner, recorded on the terrain overlay before an incident occurs.",
      "discussion": "An undeclared recovery objective is decided under pressure by whoever is loudest. Declaring it in advance converts recovery from an improvisation into a measurable commitment, and it is the number every other control in this family is assessed against. Objectives belong to the service owner, not to the security function, because they encode a mission judgement about how much interruption and how much data loss the mission can survive.",
      "apply": "Set the recovery time and recovery point objective on each mission service in the Inspector; services without one are flagged.",
      "evidence": "Recovery objectives table in the Brief; service owner approval record.",
      "assessment": "Examine the objectives table for completeness against the mission service list; interview service owners on whether the stated figures reflect a mission judgement they made.",
      "inherits": [
        "CP-2",
        "CP-2(3)",
        "PM-11"
      ],
      "csf": [
        "RC.RP-01",
        "ID.BE-05"
      ]
    },
    {
      "id": "RC-2",
      "family": "RC",
      "title": "Isolated Recovery Capability",
      "statement": "The means of recovery shall be held outside the trust boundary of the production identity plane, such that compromise of production credentials cannot reach, alter, or destroy them.",
      "discussion": "Backups reachable with production credentials are not a recovery capability; they are part of the objective. Modern intrusions target the recovery path first precisely because doing so removes the defender's alternative to paying. Isolation here means an independent authentication path and an independent authorisation decision, not merely a separate storage location.",
      "apply": "Place the recovery store in its own trust zone on the canvas; the review engine raises a finding where it shares an identity provider with production.",
      "evidence": "Terrain overlay showing the recovery zone and its trust boundary; credential separation record.",
      "assessment": "Test whether a production administrator credential can reach the recovery store; examine the authentication path for independence.",
      "inherits": [
        "CP-6",
        "CP-9(3)",
        "SC-28"
      ],
      "csf": [
        "RC.RP-01",
        "PR.DS-11"
      ]
    },
    {
      "id": "RC-3",
      "family": "RC",
      "title": "Trusted Rebuild Path",
      "statement": "For every decisive point, the organisation shall maintain a documented and tested path to rebuild the element from trusted media within its declared recovery time objective.",
      "discussion": "Restoring data onto an untrusted platform reinstates the intrusion. A rebuild path states where the trusted image comes from, who is authorised to invoke it, and what the element depends on to come back — which is why it is assessed at the decisive points first. The identity plane is the hardest case and the one most often left undocumented, because every other rebuild assumes it is already working.",
      "apply": "Attach the rebuild path to each starred element; the Brief lists decisive points with no path recorded.",
      "evidence": "Rebuild procedure per decisive point; record of the most recent rebuild test and its elapsed time.",
      "assessment": "Examine the procedures for currency; test one rebuild against its stated recovery time objective; verify the media source is independently trusted.",
      "inherits": [
        "CP-10",
        "SI-7",
        "CM-2"
      ],
      "csf": [
        "RC.RP-04",
        "PR.PS-02"
      ]
    },
    {
      "id": "RC-4",
      "family": "RC",
      "title": "Recovery Integrity Verification",
      "statement": "Restored data and rebuilt systems shall be verified against an integrity record maintained independently of the system being restored, before the service is returned to use.",
      "discussion": "Restoration without verification can reinstate the adversary's edits along with the organisation's records, and does so with the organisation's own authority behind them. The integrity record must be independent, because an adversary with sufficient dwell time will have had the opportunity to alter any record the compromised system controls.",
      "apply": "Record the integrity source for each recovery store; verification results appear in the Brief.",
      "evidence": "Integrity verification results for the most recent restoration or exercise.",
      "assessment": "Examine the verification method and its independence; test a restoration for verification before return to service.",
      "inherits": [
        "CP-9(1)",
        "SI-7(1)",
        "AU-9"
      ],
      "csf": [
        "RC.RP-05",
        "PR.DS-06"
      ]
    },
    {
      "id": "RC-5",
      "family": "RC",
      "title": "Reconstitution Exercise",
      "statement": "The organisation shall exercise reconstitution against a stated failure scenario on a defined cadence, and every declared recovery objective shall have been demonstrated within its stated period.",
      "discussion": "An untested recovery plan is a document, and the framework treats it as one. The exercise is what converts RC-1 through RC-4 from declarations into evidence, and it is where restoration sequencing — the order in which services come back — is discovered to be wrong while it is still cheap to fix. Findings from the exercise are dispositioned under CG-4 like any other.",
      "apply": "Record the exercise date, scenario, and measured elapsed time against each objective; overdue objectives are flagged.",
      "evidence": "Exercise record: scenario, participants, measured recovery times, findings raised.",
      "assessment": "Examine the exercise records for cadence and scenario realism; compare measured times against declared objectives; test that findings were dispositioned.",
      "inherits": [
        "CP-4",
        "CP-4(1)",
        "IR-3"
      ],
      "csf": [
        "RC.RP-06",
        "ID.IM-02"
      ]
    },
    {
      "id": "FO-1",
      "family": "FO",
      "title": "Privacy Terrain Identification",
      "statement": "Elements holding personally identifiable information shall be identified on the terrain overlay, with the authority under which the information is held recorded against each.",
      "discussion": "Privacy obligations are positional: what matters is where the information sits relative to a boundary and who can reach it from where. Recording the authority alongside the location is what distinguishes this from a data inventory — it is the authority that determines what may cross which boundary, and a system of records notice is a statement about terrain whether or not it is drawn as one.",
      "apply": "Mark elements as privacy terrain in the Inspector and record the governing authority; they are shaded on the overlay.",
      "evidence": "Terrain overlay with privacy elements marked; authority recorded per element.",
      "assessment": "Examine the overlay against the privacy impact assessments and system of records notices; test for elements holding such information that are unmarked.",
      "inherits": [
        "PT-2",
        "PT-3",
        "RA-8"
      ],
      "csf": [
        "GV.OC-03",
        "ID.AM-07"
      ]
    },
    {
      "id": "FO-2",
      "family": "FO",
      "title": "Controlled Unclassified Information Handling",
      "statement": "Elements processing, storing, or transmitting controlled unclassified information shall be identified on the terrain overlay, and the boundaries across which that information may move shall be declared.",
      "discussion": "The federal question is rarely whether the information is protected in place; it is which boundary it is permitted to cross and under whose authority. Declaring the permitted flows makes an unpermitted one a visible finding on the overlay rather than a matter for later discovery. This control is where the framework meets NIST SP 800-171 for the non-federal parts of the estate.",
      "apply": "Mark elements as carrying controlled unclassified information and declare permitted flows between zones; undeclared flows raise a finding.",
      "evidence": "Terrain overlay with marked elements and declared flows; the flow declaration itself.",
      "assessment": "Examine the marked elements against the categorisation record; test observed flows against the declared set.",
      "inherits": [
        "MP-4",
        "SC-28",
        "AC-21"
      ],
      "csf": [
        "PR.DS-01",
        "GV.OC-03"
      ]
    },
    {
      "id": "FO-3",
      "family": "FO",
      "title": "Tenancy and Inheritance Boundary",
      "statement": "For every element hosted in a shared or authorised service, the overlay shall record which controls are inherited from the provider and which remain the organisation's responsibility.",
      "discussion": "Inheritance is the most common source of undefended ground in a federal estate, because both parties reasonably believe the other holds it. An authorisation package states the division; the overlay is where that division becomes operational, and where a customer responsibility that no one has taken up becomes visible as terrain with no defensive move assigned to it.",
      "apply": "Set the hosting provider and inheritance split per element; unassigned customer responsibilities appear as gaps in the Brief.",
      "evidence": "Inheritance record per hosted element; customer responsibility matrix reconciled to assigned maneuvers.",
      "assessment": "Examine the inheritance record against the provider's authorisation package; test that each customer responsibility has an owner and an assigned move.",
      "inherits": [
        "SA-9",
        "SC-7(21)",
        "PM-10"
      ],
      "csf": [
        "GV.SC-07",
        "ID.AM-04"
      ]
    },
    {
      "id": "FO-4",
      "family": "FO",
      "title": "Operational Technology Terrain",
      "statement": "Operational technology, industrial control, and physical-effect systems shall be represented on the terrain overlay as a distinct defensive layer, with their connections to enterprise terrain declared.",
      "discussion": "Operational technology is contested ground in a way enterprise terrain is not: the consequence of loss is physical, the systems frequently cannot be patched or restarted on the defender's schedule, and the defensive moves available are correspondingly narrower. Representing it as its own layer prevents the common failure of scoring it as though it were a server estate. The connections are the point — an isolated plant is a claim, and the overlay is where that claim is tested.",
      "apply": "Classify elements to the operational technology layer; declare every connection to enterprise zones. Cross-layer connections are highlighted.",
      "evidence": "Terrain overlay showing the operational technology layer and its declared connections.",
      "assessment": "Examine the layer against the operational inventory; test the declared connections for completeness, including engineering workstations and remote access paths.",
      "inherits": [
        "PM-5",
        "SC-7(21)",
        "SI-4(20)"
      ],
      "csf": [
        "ID.AM-01",
        "PR.IR-01"
      ]
    },
    {
      "id": "FO-5",
      "family": "FO",
      "title": "Statutory Availability Floor",
      "statement": "Where statute, regulation, or an authorising instrument sets a deadline the mission must meet, the affected services shall be identified and their recovery objectives shall be set no weaker than that deadline requires.",
      "discussion": "Federal availability is frequently not a business preference but an externally fixed date: a benefit that must be paid, a filing window that must stay open, a report that must be delivered. Where such a floor exists, it constrains RC-1 rather than being negotiated against it. Naming the instrument is required, because an availability requirement without a citation tends to be revised downward when it becomes inconvenient.",
      "apply": "Record the governing instrument and its deadline against the affected services; recovery objectives weaker than the floor raise a finding.",
      "evidence": "Statutory availability register: service, instrument, deadline, resulting recovery objective.",
      "assessment": "Examine the register against the authorising instruments; test that each affected service's recovery objective satisfies its floor.",
      "inherits": [
        "CP-2(8)",
        "SC-5",
        "PM-11"
      ],
      "csf": [
        "GV.OC-04",
        "RC.RP-01"
      ]
    },
    {
      "id": "FO-6",
      "family": "FO",
      "title": "Supply Chain Terrain",
      "statement": "Suppliers, integrators, and software components with a path into the estate shall be represented on the terrain overlay as external actors, with the access each holds recorded.",
      "discussion": "A supplier with standing administrative access is terrain, whatever the contract calls it, and is defended — or not — on the same overlay as everything else. Recording the access rather than the relationship is what makes this assessable: the question is not whether a supplier is trusted but what they can reach, from where, and whether that path has a defensive move on it.",
      "apply": "Add suppliers as external actors with their access paths drawn; standing access to a decisive point raises a finding.",
      "evidence": "Terrain overlay showing supplier actors and access paths; access record per supplier.",
      "assessment": "Examine the supplier set against the acquisition record; test the drawn access paths against the access actually provisioned.",
      "inherits": [
        "SR-3",
        "SR-6",
        "SA-9"
      ],
      "csf": [
        "GV.SC-04",
        "ID.RA-09"
      ]
    },
    {
      "id": "WF-1",
      "family": "WF",
      "title": "Workforce Terrain Identification",
      "statement": "The organisation shall identify on the terrain overlay the roles whose compromise would materially advance an adversary, and record the population holding each.",
      "discussion": "A defence that maps every server and no person has left out the layer most intrusions actually start on. This control does not ask for an HR roster; it asks which roles are worth attacking — the ones holding privilege, approving payment, controlling the pipeline, or able to move information across a boundary. Naming them is what makes the rest of this family assessable.",
      "apply": "Mark roles as workforce terrain in the Inspector and record the holding population; unmarked privileged roles are flagged.",
      "evidence": "Workforce terrain section of the Brief; role-to-population record.",
      "assessment": "Examine the marked roles against the privileged-access record; interview the accountable owner on why unmarked roles were excluded.",
      "inherits": [
        "AT-2",
        "PS-2",
        "PM-12"
      ],
      "csf": [
        "GV.RR-04",
        "ID.AM-03"
      ]
    },
    {
      "id": "WF-2",
      "family": "WF",
      "title": "Privileged Human Register",
      "statement": "Every privileged account shall resolve to a named, currently employed, appropriately vetted individual, and the register shall be reconciled on a defined cadence.",
      "discussion": "An orphaned privileged account is an adversary's ideal position: it holds authority and nobody is watching it because nobody owns it. Reconciliation is the control, not the register — a register written once and never checked describes an estate that no longer exists. Vetting is included because a privileged account held by someone whose suitability has lapsed is a finding whether or not it has been misused.",
      "apply": "Bind privileged elements to a named holder; unbound privileged accounts raise a finding.",
      "evidence": "Privileged human register with reconciliation dates; exception list with justification.",
      "assessment": "Examine the register against the identity provider; test a sample of privileged accounts for a current, vetted holder.",
      "inherits": [
        "PS-3",
        "AC-2(7)",
        "IA-2(1)"
      ],
      "csf": [
        "PR.AA-05",
        "GV.RR-02"
      ]
    },
    {
      "id": "WF-3",
      "family": "WF",
      "title": "Role-Based Readiness",
      "statement": "Personnel in identified workforce terrain shall receive preparation specific to how their role is actually attacked, and their readiness shall be measured rather than attested.",
      "discussion": "Annual awareness training delivered identically to everyone measures completion, not readiness. The useful question is whether the finance team recognises a payment-diversion lure and whether the pipeline engineers recognise a dependency-confusion attempt. Measurement means an exercise result, not a signed acknowledgement — which is why M5.12 treats the reporting rate as the number that matters.",
      "apply": "Record role-specific preparation and its measured result against each workforce element.",
      "evidence": "Exercise results by role; content mapped to the campaigns it prepares for.",
      "assessment": "Examine content against current threat reporting for those roles; test measured results against the stated readiness threshold.",
      "inherits": [
        "AT-3",
        "AT-2(1)",
        "PS-7"
      ],
      "csf": [
        "PR.AT-01",
        "PR.AT-02"
      ]
    },
    {
      "id": "WF-4",
      "family": "WF",
      "title": "Insider Risk Position",
      "statement": "The organisation shall define, and be able to execute, a rights-respecting process for resolving an indication of insider risk, with a stated disposition period.",
      "discussion": "Insider indications are the findings organisations are least prepared to act on, because acting badly carries its own consequences — legal, employment, and to trust. Defining the process in advance is what allows it to be executed proportionately under pressure. This control deliberately requires a disposition period: an indication left open indefinitely is neither an investigation nor a dismissal, and it protects nobody.",
      "apply": "Record the process owner and disposition period; open indications past the period are flagged.",
      "evidence": "Documented process with legal and privacy review; disposition record for closed indications.",
      "assessment": "Examine the process for rights safeguards and approval; test that closed indications met the stated period.",
      "inherits": [
        "PM-12",
        "AU-6(9)",
        "PS-8"
      ],
      "csf": [
        "DE.CM-03",
        "GV.RR-04"
      ]
    },
    {
      "id": "WF-5",
      "family": "WF",
      "title": "Separation and Revocation Tempo",
      "statement": "All access held by a departing or suspended individual shall be removable in a single action, within a period measured against the tempo at which that access could be misused.",
      "discussion": "Offboarding is usually assessed as a checklist and should be assessed as a tempo. The question is not whether access is eventually removed but whether it is removed faster than a motivated leaver can use it, which for a privileged role is minutes rather than days. Requiring a single action is what makes the tempo achievable; a revocation spread across nine systems and three teams will not meet it.",
      "apply": "Record the measured revocation time; times exceeding the stated tempo raise a finding.",
      "evidence": "Measured revocation times from exercise or from real separations.",
      "assessment": "Test a revocation end to end against the stated tempo; examine for access surviving in systems outside the primary identity provider.",
      "inherits": [
        "PS-4",
        "PS-5",
        "AC-2(3)"
      ],
      "csf": [
        "PR.AA-01",
        "GV.RR-02"
      ]
    },
    {
      "id": "FC-1",
      "family": "FC",
      "title": "Facility Terrain Identification",
      "statement": "Facilities housing mission systems, data, or personnel in identified workforce terrain shall be represented on the terrain overlay, with the elements each contains recorded.",
      "discussion": "Physical ground drops off cyber terrain overlays because it feels like a different discipline, and adversaries exploit exactly that seam. A facility is terrain in the most literal sense: it has approaches, boundaries, and things inside worth reaching. Recording what each contains is what connects a physical event to its logical consequence — otherwise a badge anomaly and a server compromise are two unrelated tickets.",
      "apply": "Add facilities to the overlay and record their contents; mission elements in unrecorded facilities are flagged.",
      "evidence": "Terrain overlay showing facilities and their contents.",
      "assessment": "Examine the overlay against the real property record; test that decisive points resolve to a named facility.",
      "inherits": [
        "PE-2",
        "PE-3",
        "PM-8"
      ],
      "csf": [
        "ID.AM-01",
        "PR.IR-02"
      ]
    },
    {
      "id": "FC-2",
      "family": "FC",
      "title": "Physical Zone Boundary",
      "statement": "Facilities shall be divided into zones whose boundaries are enforced and logged, and the zone containing each decisive point shall be identified.",
      "discussion": "This is the physical counterpart of the trust zone, and it is assessed the same way: not whether a door exists but whether crossing it is enforced and recorded. Identifying the zone around each decisive point is the point of the control — it converts \"the data centre is secure\" into a statement about which boundary an adversary must cross to reach the thing that matters.",
      "apply": "Declare physical zones and the decisive points inside them; unzoned decisive points raise a finding.",
      "evidence": "Zone declaration with enforcement mechanism; access logs per boundary.",
      "assessment": "Examine zone boundaries and their enforcement; test that crossings are logged and reviewable.",
      "inherits": [
        "PE-3(1)",
        "PE-5",
        "SC-7"
      ],
      "csf": [
        "PR.AA-06",
        "PR.IR-02"
      ]
    },
    {
      "id": "FC-3",
      "family": "FC",
      "title": "Maintenance Access Control",
      "statement": "Vendor and remote maintenance shall occur only within an approved, time-boxed, supervised window, and no maintenance path shall exist outside one.",
      "discussion": "Standing maintenance access is a permanent avenue of approach that no one owns and few instrument. It is granted for a legitimate reason, outlives that reason, and is frequently the least-monitored route into the most-sensitive systems — a pattern that has produced federal intrusions repeatedly. Time-boxing is what turns it from terrain the adversary can use into terrain the defender opens deliberately.",
      "apply": "Record maintenance paths and their windows; standing paths raise a finding.",
      "evidence": "Maintenance window record with approver and supervision evidence.",
      "assessment": "Examine the maintenance path inventory for standing access; test that a path is unavailable outside its window.",
      "inherits": [
        "MA-4",
        "MA-5",
        "MA-3"
      ],
      "csf": [
        "PR.AA-05",
        "PR.PS-03"
      ]
    },
    {
      "id": "FC-4",
      "family": "FC",
      "title": "Environmental Continuity",
      "statement": "For each facility carrying a mission service, the environmental conditions the service depends on shall be identified, and the period the facility can sustain the service without them shall be stated.",
      "discussion": "Power, cooling and connectivity are the dependencies most likely to end a mission without any adversary involved, and the ones most often assumed rather than measured. Stating the sustainable period is what connects this family to RC-1: a recovery time objective that exceeds the facility’s ride-through is not an objective, it is a hope. Deliberate attack on these conditions is a recognised technique, which is why this is terrain and not facilities management.",
      "apply": "Record environmental dependencies and the stated ride-through per facility.",
      "evidence": "Environmental dependency record; ride-through test results.",
      "assessment": "Examine the stated periods against test evidence; compare against the recovery objectives of the services housed there.",
      "inherits": [
        "PE-11",
        "PE-13",
        "CP-2"
      ],
      "csf": [
        "PR.IR-04",
        "RC.RP-01"
      ]
    },
    {
      "id": "LC-1",
      "family": "LC",
      "title": "Supplier Terrain Register",
      "statement": "Suppliers, integrators and managed-service providers with a path into the estate shall be registered on the terrain overlay, with the access each holds and the elements it reaches recorded.",
      "discussion": "FO-6 requires suppliers to appear as external actors because they are a federal obligation; this control governs the register as operational terrain. What makes it assessable is recording the access and what it reaches, not the relationship: the defensive question is never whether a supplier is trusted but what they can touch, from where, and whether that path has a defensive move on it.",
      "apply": "Register suppliers with their access paths and reached elements; suppliers with unrecorded access raise a finding.",
      "evidence": "Supplier terrain register reconciled to the acquisition record.",
      "assessment": "Examine the register against contracts and against provisioned access; test for suppliers holding access not in the register.",
      "inherits": [
        "SR-2",
        "SA-9",
        "PM-30"
      ],
      "csf": [
        "GV.SC-04",
        "ID.AM-04"
      ]
    },
    {
      "id": "LC-2",
      "family": "LC",
      "title": "Component Provenance",
      "statement": "Software and hardware components deployed into the estate shall resolve to a verified origin, and the organisation shall maintain a current inventory of what those components contain.",
      "discussion": "You cannot defend ground you cannot inventory, and a modern deployment is mostly components someone else wrote. Provenance answers where it came from; the contents inventory answers what is inside it. Both are required: a signed artefact built from a compromised dependency is authentically signed and still hostile. This is the control that makes M7.16 possible, because hunting a supply-chain compromise requires knowing what you deployed.",
      "apply": "Record provenance and component inventory per deployed artefact; unverifiable artefacts raise a finding.",
      "evidence": "Component inventory per artefact; signature and origin verification results.",
      "assessment": "Examine the inventory for currency and completeness; test verification on a sample of deployed artefacts.",
      "inherits": [
        "SR-4",
        "SR-11",
        "SA-10"
      ],
      "csf": [
        "GV.SC-08",
        "ID.RA-09"
      ]
    },
    {
      "id": "LC-3",
      "family": "LC",
      "title": "Supplier Access Constraint",
      "statement": "Supplier access shall be brokered through the organisation’s own identity plane and constrained to the elements the engagement requires, with no standing access to a decisive point.",
      "discussion": "Standing supplier access to a decisive point is the single condition that turns a supplier compromise into an agency compromise, and it is usually granted for convenience during an implementation that ended years ago. Brokering through the agency identity plane is what makes the access revocable in one action rather than negotiated with the supplier — which is the difference between LC-5 being a capability and being a phone call.",
      "apply": "Route supplier access through the brokered path and scope it; standing access to a starred element raises a finding.",
      "evidence": "Supplier access records showing broker, scope and expiry.",
      "assessment": "Examine provisioned supplier access against the engagement scope; test that revocation is within the agency’s control.",
      "inherits": [
        "SR-5",
        "AC-20",
        "SA-9(2)"
      ],
      "csf": [
        "GV.SC-07",
        "PR.AA-05"
      ]
    },
    {
      "id": "LC-4",
      "family": "LC",
      "title": "Update Integrity and Staging",
      "statement": "Supplier-provided updates shall be integrity-verified before deployment and shall pass through a staging ring for a stated period before reaching the whole estate.",
      "discussion": "Patching quickly and patching safely are in genuine tension, and this control states the trade rather than pretending it away. A soak period costs a measurable amount of exposure and buys the ability to not deploy a compromised build everywhere at once. The stated period is the auditable artefact: an organisation that has thought about it can defend its number, and one that has not will not have one.",
      "apply": "Record the staging ring and soak period; updates bypassing the ring raise a finding.",
      "evidence": "Staging records with soak periods; integrity verification results per update.",
      "assessment": "Examine the declared soak period and its rationale; test that a sample of updates traversed the ring.",
      "inherits": [
        "SI-2",
        "SR-11(1)",
        "CM-3"
      ],
      "csf": [
        "ID.RA-01",
        "PR.PS-02"
      ]
    },
    {
      "id": "LC-5",
      "family": "LC",
      "title": "Supplier Severance Capability",
      "statement": "The organisation shall be able to sever a supplier’s access within a stated period and continue the mission, and shall have demonstrated it.",
      "discussion": "The moment a supplier compromise is confirmed, the defender needs an answer to \"can we cut them off today,\" and an organisation that has never tested it discovers the dependency and the intrusion simultaneously. Continuing the mission is the hard half: severance that halts operations will not be authorised, so it is not a capability. Demonstration is required for the same reason RC-5 requires it — an untested severance plan is a document.",
      "apply": "Record the severance procedure and its measured time; untested suppliers with decisive-point reach are flagged.",
      "evidence": "Severance exercise record: supplier, elapsed time, mission impact observed.",
      "assessment": "Examine the procedure and its authorisation; test severance for one supplier against the stated period.",
      "inherits": [
        "SR-8",
        "IR-4",
        "CP-2(7)"
      ],
      "csf": [
        "GV.SC-10",
        "RS.MA-01"
      ]
    }
  ]
}
