ComplianceOps

ComplianceOps runs compliance as a continuous operation instead of an annual project: one library of controls, each mapped to every requirement it satisfies across the frameworks in scope; evidence collected and tested on a schedule; exceptions with expiry dates; and audits served from records that already exist. The goal is to be audit-ready at any time, with one control satisfying many frameworks, while knowing where the frameworks stop short of what protects the organisation.

It is for the compliance lead who inherits a spreadsheet of 300 requirements, the engineer asked every quarter for “a screenshot of the MFA setting”, and the founder whose first enterprise customer wants a SOC 2 report.

Without an operating model, compliance is a periodic emergency: before the audit someone opens last year’s spreadsheet, asks engineers for screenshots and finds the access-review sign-off was never filed. Failed controls surface only when evidence is requested.

The worse cost is false assurance: a certificate says an assessor found the agreed controls in place on the days they looked, not that they were the right controls or that they worked in between. The best-known illustration is the written testimony of Target’s chief financial officer to a US House subcommittee in February 2014: “as recently as September 2013, our systems were certified as compliant with the Payment Card Industry Data Security Standards. But, the unfortunate reality is that we suffered a breach”; the same testimony dates the theft of card data at its US stores from November 27 through December 18.^[4] NIST makes the point from the other side: continuous monitoring “enables organizations to move from compliance-driven risk management to data-driven risk management”.^[5]

• Not security. Frameworks are floors written for many organisations at once. Security engineering lives in DevSecOps and CloudSecOps; ComplianceOps proves what they did.
• Not risk management. RiskOps decides which risks matter and how much to accept; ComplianceOps proves that the obligations which follow are met. Editorial distinction: this Atlas gives appetite, acceptance and quantification to RiskOps and control-to-evidence plumbing to ComplianceOps; no standard draws the line there.
• Not privacy operations or anti-money-laundering work. Rights requests and impact assessments are PrivacyOps; the fintech “Compliance Operations” team that screens customers is FinCrimeOps.

NIST SP 800-137 (September 2011) defined information security continuous monitoring as “Maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions”, with “continuous” meaning “at a frequency sufficient to support risk-based security decisions”, not real time. Its six-step loop, from strategy to review and update, still describes the operating model, and management and operational controls “must be regularly assessed for effectiveness, even if the monitoring of such controls cannot be automated”.^[5] SP 800-37 Rev. 2 (2018) made the loop the basis of ongoing authorization: the Risk Management Framework (RMF) “promotes near real-time risk management and ongoing information system and common control authorization”.^[6]

It became a product category once NIST published its controls in the Open Security Controls Assessment Language (OSCAL), “open, machine-readable formats available in XML, JSON, and YAML”,^[7] and cloud APIs made it cheap to ask whether a control is on; GRC platforms now export what one vendor calls “audit-ready proof that meets auditor requirements”.^[8]

The latest push comes from a government buyer: FedRAMP 20x piloted authorization on Key Security Indicators with automated validation, at Low (April–September 2025) and Moderate (November 2025 to March 2026). As of 2026-10-17 it is in Phase 3, “Wide-scale Adoption of FedRAMP 20x” (“The pilots are over. FedRAMP 20x is here to stay”), still marked active although that phase’s window (fiscal 2026 Q3–Q4) has closed; the page calls future dates estimates, so re-check it at each phase change. One of its stated principles: “Continuous evidence of what is happening is stronger than a policy saying it should happen”.^[9]

Mental model: obligations contain requirements, satisfied by controls, which produce evidence, which is tested; results and exceptions roll up into a state per framework. Every link has an owner and a timestamp: all inside their freshness rules means audit-ready, and any outside shows where the gap is.

flowchart LR
  R["RiskOps<br/>appetite, acceptance,<br/>what matters"]:::decision
  P["PrivacyOps<br/>rights requests,<br/>impact assessments"]:::neutral
  S["DevSecOps / CloudSecOps<br/>build and run<br/>technical controls"]:::neutral
  A["AccessOps / PatchOps /<br/>BackupOps<br/>operate controls"]:::neutral
  L["LegalOps<br/>contracts"]:::neutral
  C["ComplianceOps<br/>controls, mapping,<br/>evidence, exceptions,<br/>audits"]:::core
  F["FinCrimeOps<br/>KYC, AML, sanctions<br/>(the other<br/>'compliance ops')"]:::risk
  R -- "risk decisions" --> C
  C -- "evidence back" --> R
  P -- "privacy obligations" --> C
  S -- "config, logs, tests" --> C
  A -- "reviews, records" --> C
  L -- "contract clauses" --> C
  C -. "name collision<br/>only" .- F
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

This charter is this Atlas’s proposal, built on SP 800-137’s loop. Mission: meet every obligation in scope, continuously and demonstrably, at the least cost in engineers’ attention, and tell leadership where compliance and security diverge.

1. The control is the unit. Requirements map to controls; controls are owned, tested and evidenced. Nobody “owns SOC 2”.
2. Evidence is data: source, timestamp, collection method, test and freshness rule for every item.
3. Freshness beats volume. Evidence older than its control’s frequency counts as missing.
4. Failures are first-class. A failing test is fixed or covered by an expiring exception that names the failing resources, never re-run until green; an expired exception is a failure.
5. Map once, prove many; automate examine and test, keep interviews human. A new framework is a mapping exercise.
6. Own the library and say what compliance does not prove. Library, mapping and evidence index export in an open format; compliance state and security posture are two numbers, never one.

Non-goals. Deciding risk appetite, writing the technical controls, promising that a certificate prevents incidents.

Eight artefacts, each of which can start as a table: the obligation register (with jurisdiction, owner and review date); the control library (owner, frequency, evidence sources, tests; a JSON or YAML file before it is a platform); the mapping (with each floor and the parameter you run); the evidence store (immutable, retained for the longest obligation); the tests; the exception register; the policy set; and audit management (calendar, request tracker, findings).

The IIA’s Three Lines Model (2020) supplies the vocabulary: second-line roles provide “complementary expertise, support, monitoring, and challenge related to the management of risk”, and internal audit stays independent of management.^[17] Control owners are first line, compliance second, internal audit third; the external auditor sits outside. (The IIA has since superseded the 2020 paper with a Statement of Position.^[18])

Small organisations collapse the columns; whoever operates a control must not be the only person who checks it.

• Day 0 — scope and design. Decide which obligations apply (jurisdiction, customers, data types); choose the first framework; build the register and library; map; choose evidence sources and tooling. Output: a gap list.
• Day 1 — close gaps and start collecting. Implement missing controls (the engineering pages own this); connect collectors; write tests; publish policies; open the exception register; book the audit.
• Day 2 — operate and improve. Daily test triage; weekly freshness report; monthly review of failures and expiring exceptions; quarterly access reviews, restore tests, vendor-report reviews and break test; annual policy review and risk refresh with RiskOps.

Beyond the Day-2 cadences, three written rules suffice: who may approve an exception, at which tier and for how long; a control’s frequency or evidence source changes only through a recorded change; evidence is never edited, only superseded.

Each box can be a spreadsheet, a script, a cloud service or a GRC platform, as long as the data flows and trust boundaries exist.

flowchart TB
  subgraph SRC["Sources of truth"]
    direction LR
    I["Identity provider"]:::neutral
    K["Cloud accounts<br/>and clusters"]:::neutral
    G["Code hosting<br/>and CI"]:::neutral
    T["Ticketing, HR,<br/>LMS, vendors"]:::neutral
  end
  COL["Collectors<br/>APIs, policy engines, scripts,<br/>manual uploads with due dates"]:::core
  EV["Evidence store<br/>immutable, hashed, timestamped,<br/>access-controlled, retained"]:::core
  TEST["Tests<br/>expected vs actual,<br/>freshness rules"]:::core
  LIB["Control library and mapping<br/>owners, frequencies,<br/>requirements per framework"]:::decision
  EXC["Exception register<br/>scope, approver, expiry"]:::decision
  STATE["Compliance state<br/>per control, per framework"]:::core
  AUD["Audit package and<br/>auditor request tracker"]:::neutral
  LEAD["Leadership report:<br/>compliance state + security posture"]:::neutral
  SRC --> COL --> EV --> TEST
  LIB --> TEST
  EXC --> STATE
  TEST --> STATE
  STATE --> AUD
  STATE --> LEAD
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

• Collectors use read-only credentials scoped to what they collect.
• The evidence store is append-only apart from retention; artefacts carry hash, collector, run time and parameters. Retention follows the longest obligation (HIPAA: “6 years from the date of its creation or the date when it last was in effect, whichever is later”^[19]).
• Tests are code in version control, reviewed like any change.

Happy path: a new obligation arrives. A customer contract requires SOC 2 Type 2 with Availability. The compliance lead maps each criterion to existing controls, finds three gaps, names owners, adds collectors and tests, and sets the period start.

Exception path: a test fails mid-period. A daily test shows three accounts without MFA: two break-glass accounts covered by a CISO-approved exception until year end, and a contractor whose exception expired two weeks ago. The contractor is enrolled the same day; the lapse is recorded as a failure with its root cause (no expiry alert).

flowchart TB
  F["Test fails"]:::risk --> Q{"Live exception names<br/>every failing resource?"}:::decision
  Q -- "yes" --> E["Record as covered;<br/>check expiry date"]:::neutral
  Q -- "no" --> O["Notify control owner;<br/>open ticket with due date"]:::core
  O --> D{"Fix within<br/>control SLA?"}:::decision
  D -- "yes" --> X["Fix; test passes;<br/>failure stays in history"]:::core
  D -- "no" --> R["Request exception:<br/>scope, compensating control,<br/>approver, expiry"]:::decision
  R --> A{"Approved by<br/>risk owner?"}:::decision
  A -- "yes" --> E
  A -- "no" --> S["Escalate as open finding;<br/>report to leadership"]:::risk
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

A map, not legal advice; every row is time-sensitive (as of 2026-10-17) and jurisdiction matters.

Four more you may meet:

• SOX §404 (US public companies): management assesses internal control for financial reporting “as of the end of the most recent fiscal year of the issuer”, and the external auditor attests to that assessment, except at emerging growth companies and smaller issuers that are neither accelerated nor large accelerated filers.^[29]
• DORA (EU Regulation 2022/2554): applies from 2025-01-17 to “20 different types of financial entities and ICT third-party service providers”.^[30]
• NIS2 (EU directive): covers “18 critical sectors”; member states had to transpose it by 2024-10-17.^[31]
• 23 NYCRR 500 (entities regulated by New York’s Department of Financial Services): access reviewed “at a minimum annually”;^[32] each April 15, a certification of material compliance or an acknowledgment of noncompliance, signed by the highest-ranking executive and the CISO.^[33]

The HIPAA Security Rule is under revision: proposed 2025-01-06;^[34] as of 2026-10-17 the Unified Agenda projects final action for July 2027 (an earlier edition said May 2026).^[35] The clocks in the table differ, so one audit calendar merges them.

An audit is sampling with a conversation around it. The auditor reads your system and control description, samples per control (users, changes, tickets, days), asks for those items’ evidence and interviews owners: examine is “show me the record”, test “show me it works”, interview “explain how you do it”. US SOC 2 examinations follow the AICPA’s attestation standards (SSAE 18; AT-C 105 and 205);^[12] the international counterpart is ISAE 3000 (Revised), for “assurance engagements other than audits or reviews of historical financial information”.^[36]

sequenceDiagram
  autonumber
  participant O as Control owner
  participant A as Auditor
  participant L as Compliance lead
  participant S as Evidence store
  A->>L: Population for AC-01,<br/>then a sample of 25
  L->>S: Query exports and<br/>sign-offs for the period
  S-->>L: Artefacts with hash,<br/>run time, test history
  L-->>A: Package: population,<br/>samples, exceptions
  A->>O: Interview: how is<br/>the review done?
  O-->>A: Walk-through matches<br/>the control description
  A-->>L: Observations and<br/>findings, if any

The package holds the population (with evidence that it is complete), the sampled items’ evidence, test logic and run history, exceptions in force and change history; GRC platforms generate much of it (a locked export;^[8] a per-test PDF that “lists failed resources along with any exclusions for that test”^[37]). Keep one request tracker and never “clean up” evidence. Deviations found in testing are listed in the report; whether they change the opinion “depends on the number of exceptions, their scope, and severity”.^[11]

Mapping lets one programme serve many frameworks, and it is lossy. Take the access review: ISO/IEC 27001 Annex A 5.18 asks for access rights to be reviewed under your own access-control policy, with no interval in the summary checked;^[21] PCI DSS 7.2.4 requires every user account and its privileges to be reviewed “At least once every six months”;^[27] 23 NYCRR 500.7 says “at a minimum annually”.^[32] A quarterly review meets all three, so the 90-day choice is internal policy stricter than every floor. A mapping that records only “AC-01 → three requirements” loses that: nobody knows the control may relax to annual if PCI leaves scope, or which parameter to tighten when a stricter obligation arrives.

NIST’s OLIR programme gives “a standardized expression of the relationships between concepts”,^[38] and CSF 2.0’s Informative References are “mappings that indicate relationships between the Core and various standards, guidelines, regulations, and other content”.^[39]

Rules. Map at requirement level; record each floor, the parameter you run and who imposed it. Map every framework to one hub (your library, CSF 2.0 or SP 800-53), not to each other. Treat published crosswalks as drafts (“related” is not “equivalent”) and review the mapping at every framework version change.

Four first-year jobs that no framework headline names:

Compliance as code keeps controls, tests and mappings as version-controlled files that run in pipelines; policy as code is the enforcement half, rules an engine evaluates before a change lands, whose decisions are evidence too. Open Policy Agent rules carry unit tests (opa test runs rules “prefixed with test_”^[43]); Prowler maps its checks to frameworks including CIS, PCI-DSS, HIPAA, SOC2 and ISO 27001;^[44] AWS Config conformance packs bundle rules per framework, though AWS says its sample packs “can neither replace your internal efforts nor guarantee that you will pass a compliance assessment”.^[45] OSCAL expresses catalogs, profiles, security plans and assessment results as documents,^[7] which compliance-trestle edits and validates^[46] and Lab 2 reads.

Automate collection and testing of anything a system can answer: identity state, configuration, log retention, branch protection, vulnerability SLAs, backup results. Keep judgement human: scoping, deciding whether an addressable HIPAA specification is “reasonable and appropriate” in your environment,^[19] approving exceptions, the auditor conversation. Language models can draft policies and questionnaire answers and propose mappings for review; as evidence generators they are dangerous, because a plausible model-written access-review summary is fiction with a timestamp. This Atlas’s rule: no model output stored as evidence that a control operated (PrivacyOps covers personal data in prompts).

The smallest real implementation is a control library in version control plus a checker. Each control carries owner, mappings and evidence items (type, source, frequency, date collected and, for a failing test, the failing resources); exceptions sit in the same file with scope and expiry. The checker applies the counting rules, reports unmapped requirements and exits non-zero, so it can run nightly in CI. The data is illustrative; check framework references against the framework text.

Example status: verified by execution (Python 3.8.10, 2026-10-17) together with the script below.

{
  "as_of": "2026-10-17",
  "controls": [
    {"id": "AC-01", "title": "Quarterly user access review for production systems",
     "owner": "platform-team",
     "maps_to": ["SOC2:CC6.2", "SOC2:CC6.3", "ISO27001:A.5.18", "PCI:7.2.4",
                 "NYCRR500:500.7(a)(4)"],
     "evidence": [
       {"id": "E-01", "type": "automated", "source": "idp-export", "frequency_days": 90,
        "last_collected": "2026-09-30", "result": "pass"},
       {"id": "E-02", "type": "manual", "source": "reviewer sign-off (ticket)",
        "frequency_days": 90, "last_collected": "2026-06-28", "result": "pass"}
     ]},
    {"id": "AC-02", "title": "MFA enforced for all workforce identities",
     "owner": "it-team",
     "maps_to": ["SOC2:CC6.1", "ISO27001:A.8.5", "PCI:8.4.2"],
     "evidence": [
       {"id": "E-03", "type": "automated", "source": "idp-api", "frequency_days": 1,
        "last_collected": "2026-10-17", "result": "fail",
        "failing": ["bg-01", "bg-02", "c-118"],
        "detail": "3 of 212 users without MFA"}
     ]},
    {"id": "CM-01", "title": "Production changes are peer-reviewed before merge",
     "owner": "engineering",
     "maps_to": ["SOC2:CC8.1", "ISO27001:A.8.32", "PCI:6.5.1"],
     "evidence": [
       {"id": "E-04", "type": "automated", "source": "git-branch-protection-api",
        "frequency_days": 1, "last_collected": "2026-10-17", "result": "pass"}
     ]},
    {"id": "LM-01", "title": "Audit logs retained 12 months and protected from change",
     "owner": "platform-team",
     "maps_to": ["SOC2:CC7.2", "ISO27001:A.8.15", "PCI:10.5.1"],
     "evidence": [
       {"id": "E-05", "type": "automated", "source": "cloud-config-rule",
        "frequency_days": 1, "last_collected": "2026-10-02", "result": "pass"}
     ]},
    {"id": "VM-01", "title": "Critical vulnerabilities remediated within 30 days",
     "owner": "security-team",
     "maps_to": ["SOC2:CC7.1", "ISO27001:A.8.8", "PCI:6.3.3", "PCI:11.3.1"],
     "evidence": [
       {"id": "E-06", "type": "automated", "source": "scanner-api", "frequency_days": 7,
        "last_collected": "2026-10-15", "result": "pass"}
     ]},
    {"id": "HR-01", "title": "Security awareness training completed annually",
     "owner": "people-team",
     "maps_to": ["SOC2:CC1.4", "ISO27001:A.6.3", "PCI:12.6.3"],
     "evidence": [
       {"id": "E-07", "type": "manual", "source": "lms-completion-report",
        "frequency_days": 365, "last_collected": "2025-09-10", "result": "pass"}
     ]},
    {"id": "BC-01", "title": "Backup restore tested quarterly", "owner": "platform-team",
     "maps_to": ["SOC2:A1.3", "ISO27001:A.8.13"],
     "evidence": []}
  ],
  "exceptions": [
    {"id": "X-01", "control": "AC-02", "scope": ["bg-01", "bg-02"],
     "approved_by": "ciso", "expires": "2026-12-31",
     "compensating": "vaulted; any use alerts the SOC"},
    {"id": "X-02", "control": "AC-02", "scope": ["c-118"],
     "approved_by": "it-manager", "expires": "2026-09-30",
     "compensating": "none recorded"}
  ],
  "frameworks_in_scope": {
    "SOC2": ["CC1.4", "CC6.1", "CC6.2", "CC6.3", "CC7.1", "CC7.2", "CC8.1", "A1.3"],
    "PCI": ["6.3.3", "6.5.1", "7.2.4", "8.4.2", "10.5.1", "11.3.1", "12.6.3", "12.10.1"]
  }
}

Example status: verified by execution (Python 3.8.10, 2026-10-17); the output shown is the actual output.

"""Check a control library: coverage, stale evidence, failing tests, exceptions.

Usage: python3 evidence_check.py controls.json
Standard library only (Python 3.8+). A control is UNTESTED if it has no evidence or
any item is stale; FAIL if a fresh test fails for a resource outside every live
exception's scope; COVERED if all failing resources are inside live exceptions;
otherwise PASS. Exit code 1 on any FAIL, stale or missing evidence, expired
exception or unmapped in-scope requirement.
"""
import json
import sys
from collections import Counter, defaultdict
from datetime import date


def d(s):
    return date.fromisoformat(s)


def main(path):
    lib = json.load(open(path, encoding="utf-8"))
    today = d(lib["as_of"])
    problems = 0
    mapped = defaultdict(set)
    n_ev = n_auto = n_fresh = 0
    states = Counter()
    live = defaultdict(dict)  # control id -> {exception id: set of resources}
    print(f"Control library check as of {today}")
    print("EXCEPTIONS")
    for x in lib.get("exceptions", []):
        if x.get("closed"):
            status = "closed"
        elif d(x["expires"]) >= today:
            status = "live"
            live[x["control"]][x["id"]] = set(x["scope"])
        else:
            status = "EXPIRED"
            problems += 1
        print(f"  {x['id']:<5} {x['control']:<6} expires {x['expires']} {status:<8}"
              f" scope: {', '.join(x['scope'])}")
    print("CONTROLS")
    for c in lib["controls"]:
        for ref in c["maps_to"]:
            fw, req = ref.split(":", 1)
            mapped[fw].add(req)
        flags, stale, uncovered, covered_by = [], False, set(), set()
        if not c["evidence"]:
            flags.append("NO-EVIDENCE")
            problems += 1
        for e in c["evidence"]:
            n_ev += 1
            n_auto += e["type"] == "automated"
            age = (today - d(e["last_collected"])).days
            if age > e["frequency_days"]:
                stale = True
                flags.append(f"STALE:{e['id']}({age}d>{e['frequency_days']}d)")
                problems += 1
                continue
            n_fresh += 1
            if e["result"] == "fail":
                failing = set(e.get("failing", [e["id"]]))
                for xid, scope in live[c["id"]].items():
                    if failing & scope:
                        covered_by.add(xid)
                    failing -= scope
                uncovered |= failing
        if covered_by:
            flags.append(f"covered-by:{','.join(sorted(covered_by))}")
        if uncovered:
            state = "FAIL"
            flags.append(f"FAILING:{','.join(sorted(uncovered))}")
            problems += 1
        elif stale or not c["evidence"]:
            state = "UNTESTED"
        else:
            state = "COVERED" if covered_by else "PASS"
        states[state] += 1
        print(f"  {c['id']:<6} {c['owner']:<14} {state:<9} {' '.join(flags)}".rstrip())
    print("COVERAGE")
    for fw, reqs in lib["frameworks_in_scope"].items():
        missing = sorted(set(reqs) - mapped[fw])
        n_ok = len(reqs) - len(missing)
        line = f"  {fw:<9} {n_ok}/{len(reqs)} requirements mapped"
        if missing:
            line += f"  unmapped: {', '.join(missing)}"
        print(line)
        problems += len(missing)
    tested = states["PASS"] + states["COVERED"] + states["FAIL"]
    ok = states["PASS"] + states["COVERED"]
    print("SUMMARY")
    print("  " + "  ".join(f"{s} {states[s]}" for s in
                           ("PASS", "COVERED", "FAIL", "UNTESTED")))
    if tested:
        print(f"  pass rate on tested controls: {ok}/{tested}"
              f" = {100 * ok / tested:.0f}%")
    print(f"  fresh evidence: {n_fresh}/{n_ev}   automated: {n_auto}/{n_ev}")
    print(f"RESULT: {problems} problem(s)")
    return 1 if problems else 0


if __name__ == "__main__":
    if len(sys.argv) != 2:
        sys.exit("usage: python3 evidence_check.py controls.json")
    sys.exit(main(sys.argv[1]))

$ python3 evidence_check.py controls.json
Control library check as of 2026-10-17
EXCEPTIONS
  X-01  AC-02  expires 2026-12-31 live     scope: bg-01, bg-02
  X-02  AC-02  expires 2026-09-30 EXPIRED  scope: c-118
CONTROLS
  AC-01  platform-team  UNTESTED  STALE:E-02(111d>90d)
  AC-02  it-team        FAIL      covered-by:X-01 FAILING:c-118
  CM-01  engineering    PASS
  LM-01  platform-team  UNTESTED  STALE:E-05(15d>1d)
  VM-01  security-team  PASS
  HR-01  people-team    UNTESTED  STALE:E-07(402d>365d)
  BC-01  platform-team  UNTESTED  NO-EVIDENCE
COVERAGE
  SOC2      8/8 requirements mapped
  PCI       7/8 requirements mapped  unmapped: 12.10.1
SUMMARY
  PASS 2  COVERED 0  FAIL 1  UNTESTED 4
  pass rate on tested controls: 2/3 = 67%
  fresh evidence: 4/7   automated: 5/7
RESULT: 7 problem(s)

How to read it. AC-02 fails: X-01 covers the break-glass accounts, but contractor c-118 sits outside every live exception because X-02 expired. AC-01 is untested although its export is fresh: the reviewer sign-off, the record that the review happened, is 111 days old.

Objective: a control library with freshness rules, scope-aware exceptions and an honest pass rate, run locally and in CI. Prerequisites: Python 3.8+; no cloud account, cost or risk; about an hour.

1. Save controls.json and evidence_check.py in an empty directory; run python3 evidence_check.py controls.json.
2. Fix the problems honestly: enrol the contractor in MFA (remove c-118 from E-03’s failing list) and close X-02 by adding "closed": "2026-10-17" rather than deleting it; give BC-01 an evidence item; refresh the stale items’ last_collected; add an incident-response control with evidence, mapped to PCI 12.10.1.
3. Add a control from your own environment with a real evidence source, such as your identity provider’s MFA report.
4. Commit the directory and add a nightly CI job that fails on exit code 1.

Expected output (checked by execution): step 1 prints the reference output and exits 1; after step 2 every control is PASS except AC-02 (COVERED by X-01), RESULT: 0 problem(s), exit 0. Validation: move as_of 100 days later; quarterly items go stale and X-01 expires. Troubleshooting: JSONDecodeError usually means a trailing comma; Invalid isoformat string, a date not in YYYY-MM-DD. Teardown: delete the directory, or keep it as your library’s start.

Objective: turn NIST’s catalog and baseline into a CSV your team fills in with owners and evidence sources. Prerequisites: Python 3.8+, curl, about 10.5 MB of downloads; no cost or risk; under an hour. Status: verified by execution on 2026-10-17 against that day’s files (counts change with NIST updates).

1. Download the catalog and the Moderate baseline profile:

REPO=https://raw.githubusercontent.com/usnistgov/oscal-content/main
BASE="$REPO/nist.gov/SP800-53/rev5/json"
curl -sSLO "$BASE/NIST_SP-800-53_rev5_catalog.json"
curl -sSLO "$BASE/NIST_SP-800-53_rev5_MODERATE-baseline_profile.json"
ls -la NIST_SP-800-53_rev5_*.json

2. Save the script as oscal_baseline.py and run it.

Example status: verified by execution (Python 3.8.10, 2026-10-17); the output below is the actual output.

"""Turn an OSCAL catalog + profile into a control-ownership skeleton (CSV).

Usage: python3 oscal_baseline.py catalog.json profile.json out.csv
Standard library only (Python 3.8+). Reads the control ids selected by the profile's
imports (with-ids), looks each one up in the catalog, skips withdrawn entries, and
writes one row per control with empty owner / evidence columns for your team.
"""
import csv
import json
import sys
import textwrap
from collections import Counter

COLUMNS = ["control_id", "family", "title", "owner", "evidence_source",
           "evidence_type", "frequency_days", "maps_to_other"]


def walk(groups, found):
    """Index every control (and nested enhancement) in the catalog by id."""
    for g in groups:
        for c in g.get("controls", []):
            index_control(c, g.get("id", ""), found)


def index_control(c, family, found):
    status = {p.get("value") for p in c.get("props", []) if p.get("name") == "status"}
    found[c["id"]] = (family, c["title"], "withdrawn" in status)
    for sub in c.get("controls", []):
        index_control(sub, family, found)


def show(label, meta):
    """Print a document's title and version, wrapped to fit an 88-column terminal."""
    text = f"{meta['title']} (version {meta['version']})"
    print(textwrap.fill(text, 88, initial_indent=f"{label}: ",
                        subsequent_indent=" " * 10))


def main(cat_path, prof_path, out_path):
    cat = json.load(open(cat_path, encoding="utf-8"))["catalog"]
    prof = json.load(open(prof_path, encoding="utf-8"))["profile"]
    controls = {}
    walk(cat.get("groups", []), controls)
    selected = []
    for imp in prof["imports"]:
        for sel in imp.get("include-controls", []):
            selected.extend(sel.get("with-ids", []))
    show("catalog ", cat["metadata"])
    show("profile ", prof["metadata"])
    n_wd = sum(1 for v in controls.values() if v[2])
    print(f"catalog entries: {len(controls)} (withdrawn {n_wd},"
          f" active {len(controls) - n_wd})   selected by profile: {len(selected)}")
    bad = [cid for cid in selected if cid not in controls or controls[cid][2]]
    if bad:
        print(f"WARNING: {len(bad)} selected ids missing or withdrawn: {bad[:5]} ...")
    keep = [cid for cid in selected if cid not in bad]
    fam = Counter(controls[cid][0] for cid in keep)
    print("per family (base controls + enhancements):")
    for family, n in sorted(fam.items()):
        print(f"  {family:<4} {n:>3}")
    with open(out_path, "w", newline="", encoding="utf-8") as fh:
        w = csv.writer(fh)
        w.writerow(COLUMNS)
        for cid in keep:
            family, title, _ = controls[cid]
            w.writerow([cid, family, title, "", "", "", "", ""])
    print(f"wrote {out_path} ({len(keep)} rows)")
    return 1 if bad else 0


if __name__ == "__main__":
    if len(sys.argv) != 4:
        sys.exit("usage: python3 oscal_baseline.py catalog.json profile.json out.csv")
    sys.exit(main(*sys.argv[1:4]))

$ python3 oscal_baseline.py NIST_SP-800-53_rev5_catalog.json \
    NIST_SP-800-53_rev5_MODERATE-baseline_profile.json moderate-skeleton.csv
catalog : Electronic (OSCAL) Version of NIST SP 800-53 Rev 5.2.0 Controls and SP 800-53A
          Rev 5.2.0 Assessment Procedures (version 5.2.0)
profile : Electronic (OSCAL) Version of NIST Special Publication 800-53 Revision 5.2.0
          MODERATE IMPACT BASELINE (version 5.2.0)
catalog entries: 1196 (withdrawn 182, active 1014)   selected by profile: 287
per family (base controls + enhancements):
  ac    39
  at     6
  au    16
  ca    10
  cm    24
  cp    23
  ia    24
  ir    13
  ma     9
  mp     7
  pe    18
  pl     7
  ps     9
  ra    10
  sa    17
  sc    25
  si    18
  sr    12
wrote moderate-skeleton.csv (287 rows)

3. Fill in owner and evidence columns for the ac family first; put the SOC 2 or ISO/IEC 27001 references you use in maps_to_other.
4. Swap in the LOW or HIGH baseline profile and compare counts.

Expected output: as shown: 1,196 catalog entries, 182 of them withdrawn (1,014 active); 287 selected, none withdrawn. Validation: grep -c '^ac-' moderate-skeleton.csv prints 39. Troubleshooting: HTML instead of JSON means the path moved (browse the repository’s nist.gov/SP800-53/rev5/json directory); KeyError: 'imports' means a catalog was passed as profile. Teardown: delete the JSON files; keep the CSV.

Objective: deploy AWS’s sample PCI DSS 4.0 conformance pack and keep its results as dated evidence for a control. Prerequisites: a sandbox AWS account with AWS Config recording on in one Region (required for every pack^[52]); AWS CLI v2 and jq; permissions config:PutConformancePack, config:DescribeConformancePackStatus, config:DescribeConformancePackCompliance, config:GetConformancePackComplianceDetails, config:DeleteConformancePack, and iam:CreateServiceLinkedRole the first time, because the API creates the service-linked role AWSServiceRoleForConfigConforms. That role can create Config rules and remediation actions “even if your account IAM policies explicitly deny these actions”, so grant config:PutConformancePack only to deployers.^[53] AWS recommends removing rules not available in your Region first.^[45] Costs and risks: AWS Config charges per configuration item recorded and per conformance pack evaluation;^[54] the pack declared 127 rules on 2026-10-17.

Example status: syntax-checked; control flow (polling, paging, hashing) dry-run on 2026-10-17 against a mocked aws; not executed against AWS (no AWS account in the authoring environment).

set -euo pipefail
REGION=ap-south-1
PACK=pci-dss-v4-evidence
REPO=https://raw.githubusercontent.com/awslabs/aws-config-rules/master
FILE=Operational-Best-Practices-for-PCI-DSS-v4.0-including-global-resourcetypes.yaml
curl -sSLo pack.yaml "$REPO/aws-config-conformance-packs/$FILE"
# Remove rules not available in $REGION before deploying (see AWS's Region list).
# --template-body accepts at most 51,200 bytes; larger templates go to S3.
aws configservice put-conformance-pack --region "$REGION" \
  --conformance-pack-name "$PACK" --template-body "file://pack.yaml"
# Wait for deployment; the rules then run their first evaluations.
while :; do
  STATE=$(aws configservice describe-conformance-pack-status --region "$REGION" \
    --conformance-pack-names "$PACK" \
    --query 'ConformancePackStatusDetails[0].ConformancePackState' --output text)
  echo "pack state: $STATE"
  case "$STATE" in
    CREATE_COMPLETE) break ;;
    CREATE_FAILED) exit 1 ;;
  esac
  sleep 30
done
# Collect rule-level and per-resource results as dated, hashed, read-only files.
STAMP=$(date -u +%Y%m%dT%H%M%SZ)
mkdir -p evidence
aws configservice describe-conformance-pack-compliance --region "$REGION" \
  --conformance-pack-name "$PACK" --filters ComplianceType=NON_COMPLIANT \
  --output json > "evidence/${PACK}-rules-${STAMP}.json"
# Per-resource results come at most 100 per call: follow NextToken.
TOKEN=""
PAGE=0
while :; do
  PAGE=$((PAGE + 1))
  OUT="evidence/${PACK}-resources-${STAMP}-p${PAGE}.json"
  aws configservice get-conformance-pack-compliance-details --region "$REGION" \
    --conformance-pack-name "$PACK" --filters ComplianceType=NON_COMPLIANT \
    --limit 100 ${TOKEN:+--next-token "$TOKEN"} --output json > "$OUT"
  TOKEN=$(jq -r '.NextToken // empty' "$OUT")
  if [ -z "$TOKEN" ]; then break; fi
done
chmod a-w evidence/*"-${STAMP}"*.json
sha256sum evidence/*"-${STAMP}"*.json

Expected output: a ConformancePackArn; pack states until CREATE_COMPLETE; a rules file (ConformancePackRuleComplianceList: ConfigRuleName, ComplianceType, mapped Controls) and one or more resources files (ConformancePackRuleEvaluationResults: each non-compliant resource’s type and id, which is what an auditor samples).^[53] Validation: every file is dated, hashed and read-only, ready for the immutable store. Troubleshooting: a template over 51,200 bytes needs S3; an old CLI (1.18) demands --delivery-s3-bucket, so upgrade; CREATE_FAILED, missing permissions or a rule unavailable in the Region; INSUFFICIENT_DATA, a rule still evaluating or an unrecorded resource type. Teardown: aws configservice delete-conformance-pack --region "$REGION" --conformance-pack-name "$PACK"; stop the recorder if it was enabled only for the lab, since recording keeps billing.

1. First SOC 2 Type 2 for a 40-person SaaS company (illustrative). Context: an enterprise prospect requires Security and Availability. Method: a GRC platform connected to identity provider, cloud and code host; about 60 controls; the cloud provider’s SOC report reviewed and its CUECs mapped; a 6-month first period. Trade-off: speed now, a 12-month report next year. Success: an unqualified (“clean”) opinion with no exceptions noted in testing; under 20 engineer-hours on evidence requests. Pitfall: a period started before collectors are connected leaves a gap that cannot be back-filled.

2. Consolidating ISO/IEC 27001, SOC 2 and PCI DSS in a 2,000-person company (illustrative). Context: three programmes, three spreadsheets. Method: one library, each parameter tagged with its source; SoA and SOC 2 control matrix generated from it. Trade-off: a quarter of mapping, and three auditors must accept a shared package. Success: evidence requests per control per year fall from three to one. Pitfall: a parameter relaxed for one framework silently weakens another.

3. Machine-validated authorization for a cloud service sold to government (illustrative; modelled on FedRAMP 20x^[9]). Method: library, security plan and test results in OSCAL; validation code shared with the assessor. Trade-off: heavy up-front engineering while the programme formalises its rules (as of October 2026). Success: the assessor reviews validations and their trend, not screenshots. Pitfall: hard-coding today’s indicator definitions instead of keeping them as data.

Counting rules (principles 3 and 4 as numbers): a control is tested only when every evidence item it lists is fresh, so a fresh input with a stale sign-off is untested; a failing resource counts as covered only while a live exception names it. Report pass rate and untested count together or not at all.

stateDiagram-v2
  direction LR
  state "Evidence item" as EV {
    direction TB
    state "Fresh: counts as tested" as Fresh
    state "Stale: counts as missing" as Stale
    [*] --> Fresh: collected with source, time, result
    Fresh --> Stale: age passes the frequency
    Stale --> Fresh: collected again, old item kept
  }
  state "Exception" as EX {
    direction TB
    state "Live: covers named resources only" as Live
    state "Expired: counts as a failure" as Expired
    [*] --> Requested: fix impossible within SLA
    Requested --> Live: approved with scope and expiry
    Live --> Expired: expiry date passes
    Live --> Closed: control fixed, record kept
    Expired --> Closed: fixed late, failure kept
  }

Worked calculation (the reference SUMMARY). Coverage: SOC 2 8 ÷ 8 = 100 %, PCI 7 ÷ 8 = 87.5 %. Freshness 4 ÷ 7 = 57 %; automated 5 ÷ 7 = 71 %. Three controls are testable (AC-02, CM-01, VM-01) and two pass: 2 ÷ 3 = 67 %, with four of seven untested, so say “2 pass, 1 fails, 4 untested”. A laxer checker that let any live exception cover AC-02 and judged AC-01 on its fresh export would report 4 ÷ 4 = 100 % from the same data. A pass rate that rises only in the month before the audit is the periodic emergency returning.

The evidence store is a target: it describes your controls, lists your administrators and often holds personal data. Apply your own controls to it: read-only collector credentials, immutable retention, access logging, and data minimisation (an access-review export needs identifiers, not HR records).

Four cost lines: audit fees per framework; tooling (subscriptions or usage charges); engineering time for collectors and tests; owners’ recurring attention. The main lever is fewer, better-mapped controls with automated evidence. Track engineer-hours per audit and the evidence tax, the share of an owner’s time spent proving rather than doing, which must not rise as frameworks are added. Environmental impact is immaterial here.

Test the tests: each quarter, break a control in a sandbox (remove branch protection on a test repository, create a test user without MFA) and confirm the failure appears in time; internal audit samples the store independently.^[17]

Illustrative scenario. Eight weeks into a 12-month SOC 2 period, the weekly review shows daily cloud configuration evidence last collected 15 days ago (LM-01 in the reference output).

1. Confirm the gap (hour 0). The collector has failed since an unrelated migration changed the cloud role’s trust policy. The control may have operated; the evidence did not.
2. Restore collection (hour 1). Fix the role, run the collector, confirm a fresh artefact.
3. Reconstruct (day 1). Query configuration history for the missing days; store it as a separate artefact labelled “retrospective, collected on <date>”, never back-dated.
4. Assess the control (day 1). No resource non-compliant during the gap: an evidence-process failure. Some: control failures with their own tickets.
5. Record and disclose (day 2). Record dates, cause and reconstruction on the control; tell the auditor at the next check-in. If the control held, the auditor can usually test the reconstruction; if not, it is an exception in the report however it was found, with your management response beside it.^[11]
6. Prevent (week 1). Missed-run alerts for every collector; protect the cloud role; add the scenario to the break test.

• “We are SOC 2 certified.” SOC 2 is a CPA’s attestation report, not a certification;^[12] the phrase signals a programme that has not read its own report.
• Audit-driven clean-up. Controls fixed the month before the audit and lapsing after.
• Framework teams. A SOC 2 team, an ISO team and a PCI team each asking engineering the same question.
• Renew to green. Extending an exception to clear a failing check, with no compensating control and a junior approver.

Adopt ComplianceOps when you hold two or more obligations with overlapping controls, a period-based audit needs evidence for every day, engineers lose measurable time to evidence requests, or a regulator can ask for evidence at any time.

Do not build a continuous programme when you face one point-in-time obligation with no plan to repeat it; when nobody can own the library (a checklist and calendar are more honest); or when the controls do not exist yet, which is engineering work for DevSecOps and CloudSecOps.

flowchart TB
  S["How many obligations with<br/>overlapping controls?"]:::decision
  S -- "one, point in time" --> C1["Checklist + calendar;<br/>revisit in a year"]:::neutral
  S -- "two or more, or any<br/>period-based audit" --> O["Who can own the<br/>control library?"]:::decision
  O -- "nobody yet" --> C2["Name an owner first;<br/>no tool fixes this"]:::risk
  O -- "named owner" --> T["Stack and audience?"]:::decision
  T -- "SaaS on major cloud,<br/>commercial audits" --> G["GRC platform;<br/>export library quarterly"]:::core
  T -- "one cloud, technical<br/>controls dominate" --> N["Cloud-native rules +<br/>scanner + Lab 1 library"]:::core
  T -- "government / multi-tool /<br/>long-lived estate" --> X["OSCAL library +<br/>trestle; tools as collectors"]:::core
  G --> E["Any choice: evidence store<br/>and exception register"]:::neutral
  N --> E
  X --> E
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029

Scores 1–3 (higher is better) and weights are this Atlas’s judgement; a total sums weight × score, out of 45.

A weak export (score 1) cuts the platform to 33, one point above the open library: the judgement call turns on that row.

This Atlas’s model, not an industry standard.

• Days 1–30. Name the owner. Build the obligation register (laws, standards, the top ten customer contracts). Choose the first framework and the mapping hub; draft the library from what exists and run Lab 1 on it.
• Days 31–60. Connect collectors for identity, cloud and code hosting; write tests for the ten controls with the most requirements mapped. Open the exception register; expire everything undocumented. Agree evidence format and period with the auditor.
• Days 61–90. Start the period only when freshness is 100 % and no exception has expired. Run the first break test; report the first metrics. Map the second framework and count the new controls it needed: that number shows whether the mapping works.

Programme preflight

• Obligation register with jurisdiction, owner and review date per entry
• Every requirement maps to a control with owner, frequency, evidence source, test, floor and parameter
• Evidence store immutable, retained to the longest obligation, access-logged
• Exception register with scope and automatic expiry; policies versioned and acknowledged

Before an audit period starts

• Freshness 100 %; no expired exceptions; no untested controls
• Period, scope and evidence format agreed with the auditor in writing; vendor reports and CUECs reviewed
• Auditor access scoped and time-limited; request tracker open; owners briefed

Quarterly review

• Break test run and failure observed in time
• Mapping checked for framework version changes; exceptions older than 90 days reviewed with the risk owner
• Metrics reported

Control record (JSON form in the reference implementation). The floors are those cited in the mapping section; the 90-day value is a fictional internal policy stricter than all three.

id: AC-01
title: Quarterly user access review for production systems
owner: platform-team
description: >
  Managers review and sign off every account with production access each quarter;
  removals are actioned within 5 working days.
frequency_days: 90
strictest_parameter: {value: "90 days", imposed_by: "POLICY:IS-07"}
framework_floors:
  "ISO27001:A.5.18": "process; no interval stated"
  "PCI:7.2.4": "at least once every six months"
  "NYCRR500:500.7(a)(4)": "at a minimum annually"
maps_to:
  ["SOC2:CC6.2", "SOC2:CC6.3", "ISO27001:A.5.18", "PCI:7.2.4", "NYCRR500:500.7(a)(4)"]
evidence:
  - {id: E-01, type: automated, source: idp-export,
     test: "all prod accounts appear in a review"}
  - {id: E-02, type: manual, source: "reviewer sign-off ticket",
     due: "quarter end + 10 days"}
changed:
  - {date: 2026-10-17, by: compliance-lead,
     note: "frequency 180 -> 90 under policy IS-07; strictest framework floor: PCI 7.2.4"}

Exception record

id: X-01
control: AC-02
scope: [bg-01, bg-02]
reason: "emergency access must work when the identity provider is down"
compensating_control: "credentials vaulted; any use alerts the SOC within 5 minutes"
risk_owner: ciso
approved: 2026-10-01
expires: 2026-12-31
review_note: "re-approve only with evidence that no use went unalerted this quarter"

Auditor request tracker (columns): request id · control · auditor’s question · sample items · evidence artefact ids · owner · due · status (open / supplied / accepted / follow-up). Artefact ids point into the store, so one artefact serves every audit.

Policy lifecycle SOP (one page): owner and approver per policy; annual review date; change triggers; approval record; acknowledgement within 30 days of publication and at onboarding; retired policies kept for the retention period.

Is “ComplianceOps” a recognised discipline? No; it is an emerging, vendor-led label for continuous monitoring and ongoing authorization (origins).

Which framework first? The one a paying customer asks for (often SOC 2 in North America, ISO/IEC 27001 elsewhere). Build the library first; the second framework is then a mapping.

Can automated evidence replace the auditor’s sampling? No; it changes what is sampled. Auditors still pick items and interview owners; evidence with provenance makes examining and testing faster.^[10]

A customer sent a 300-question security questionnaire. Where do the answers come from? From the library: each answer cites control and evidence ids, so it is as fresh as the evidence. Offer your SOC 2 report or a published CAIQ first where the customer accepts them,^[42] with a bridge letter if the report period ended months ago.^[41]

What if a compliance tool we rely on is withdrawn? You keep what you exported: AWS Audit Manager stopped accepting new accounts on 2026-04-30.^[48] Own the library; treat tools as collectors.

• Machine-readable assurance. FedRAMP 20x estimates a High pilot in fiscal 2027 and plans to stop accepting new Rev5 certifications on 2027-06-11; its Phase 2 lessons include assessor review of validation code and trending validation data over time.^[9] This Atlas expects other programmes to copy the shape.
• OSCAL as lingua franca. NIST publishes SP 800-53 in OSCAL;^[28] will commercial platforms import and export it faithfully?
• Regulation keeps arriving with dates. PCI DSS 4.0.1’s future-dated requirements (2025-03-31),^[25] the proposed HIPAA update and AI regulation (ModelOps) all land on one library; the obligation register needs a change feed.

• Prerequisites: none. RiskOps shows how controls are chosen, AccessOps the most audited one.
• One day: this page; SP 800-137’s first chapter;^[5] one framework’s requirement list; Lab 1.
• One week: Lab 2; map ten of your controls to two frameworks; write three control records.
• 30 days: build the register and library; connect one collector; run a mock audit on five controls.
• Specialisation: OSCAL and trestle for federal work; OPA and Conftest for engineering-led programmes; SP 800-53A for assessors.
• Portfolio idea: an open control library mapped to two frameworks, with a CI checker.

• Decide: one library, one owner, one mapping hub, and where the library lives.
• Operate: evidence as data; daily tests; freshness rules; scoped, expiring exceptions; audits from the store.
• Measure: coverage, freshness, automated ratio, pass rate with untested count, time to resolve, self-found ratio.
• Next: build the obligation register; run Lab 1 on your controls; agree evidence format with your auditor.

Illustrative scenario. A 120-person company on one cloud needs SOC 2 Type 2 in nine months and expects ISO/IEC 27001, and possibly a government programme, within two years.

Option A: GRC platform now. Fastest first report and workflows for people controls, if its integrations cover your stack. Risk: the mapping lives in the vendor’s model; exit cost depends on export quality.

Option B: cloud-native rules, a scanner and an OSCAL/JSON library in version control. Needs two engineers a day a week for a quarter and an auditor who accepts machine-collected evidence. The library is yours, and a later government programme is a mapping, not a migration. Risk: a slower first audit and collectors to maintain.

How this Atlas would decide. The deciding variables are the nine-month deadline and the two-year horizon. If the platform’s export is verified complete and structured, A wins year one, with the library moved to the open format in year two. If the export is weak, B is cheaper over three years, because the migration would otherwise arrive at the worst moment. The attractive-but-wrong choice is A without checking the export: it feels fast and defers the real decision. The open library is insurance, not a guarantee.

After this page you should be able to explain why the control is the unit of work, design a control record with freshness rules, map one control to several frameworks with each floor recorded, distinguish the audit shapes of ISO/IEC 27001, SOC 2, PCI DSS and HIPAA, count pass rate and untested controls honestly, and choose where to keep the library.

1. An MFA control passes daily in the GRC platform, yet the auditor finds MFA was not enforced for contractors. What went wrong, and what evidence would have shown it?

2. On 20 April, mid-period, you find the cloud configuration collector has failed since 10 April. Can you back-fill?

3. Why record each framework’s floor and who imposed the parameter you run?

4. May a language model draft the quarterly access-review summary from the raw export?

5. A manager proposes extending the expired exception X-02 by six months so the nightly check passes before the audit. What do you do?

ComplianceOps is an emerging name for a settled idea: compliance is proven by records that exist because the organisation runs well, not by a quarter of archaeology before the auditor arrives. Frameworks differ in shape and cadence; the library does not, and a library you can export is the asset.

The honest limit is the one Target’s chief financial officer put to Congress: systems certified compliant in September 2013, card data stolen from late November. A programme that reports only its pass rate has built a mirror. Report what you proved, what you could not test and what you found first, and, on a separate line, how secure the organisation actually is.

Changelog. 2026-10-17 — first edition (ledger research/complianceops-ledger.md; two labs executed, one not). Round 2 — cut to 9,989 words; audit sequence diagram; 15 sources re-verified. Round 3 (superseded r1 review) — PCI DSS 7.2.4, KPI calculation, SSAE 18, SOX, HIPAA agenda status, Lab 3 permissions. Round 4 (reviews/complianceops-r1-response.md) — PCI validation and ASV scans; FedRAMP 20x Phase 3; exception scope and freshness in checker and KPIs; NYDFS, SOX, vendor reports and PCI scoping added; state diagram; Labs 1 and 2 re-run; under 9,000 words. 2026-10-17, post-score polish: Figure 5 state names; scored comparison; SoA, Annex A count, SOC 2 types and IIA supersession cited; FedRAMP 20x re-check note (reviews/complianceops-polish.md).