---
title: "ComplianceOps"
slug: complianceops
category: security
term_status: emerging
evidence_status: verified
summary: "ComplianceOps runs regulatory and contractual compliance as a continuous operation: one library of controls mapped to every framework in scope, evidence collected and tested on a schedule, exceptions with expiry dates, and audits served from records that already exist."
audience: [GRC and compliance managers, Engineers who supply evidence, Start-up founders facing SOC 2 or ISO 27001, Architects and platform teams, Security leaders and auditors, Beginners]
last_verified: 2026-10-17
key_takeaways:
- "\"ComplianceOps\" is an emerging label used by GRC vendors; no standard defines it. The practice it names is older: NIST described information security continuous monitoring in 2011 and ongoing authorization in 2018."
- "The unit of work is the control, not the framework. One well-run control with tested evidence can satisfy requirements in SOC 2, ISO/IEC 27001, PCI DSS and HIPAA at once; mapping is how you avoid running four programmes."
- "Evidence is data with a timestamp, a source and a test. Evidence older than its control's frequency counts as missing, and a failure counts as covered only for the resources an unexpired exception names."
- "Being compliant is not being secure: Target's systems were certified PCI DSS compliant in September 2013, and payment card data was stolen from its US stores from late November. Compliance proves that agreed controls operated, not that they were the right ones."
- "Audits differ in kind: ISO/IEC 27001 is a certification on a three-year cycle, SOC 2 an accountant's (CPA) attestation, Type 2 over a period, PCI DSS an annual validation against a prescriptive standard with quarterly external scans, HIPAA a regulation enforced after the fact. Plan the calendar around these shapes."
- "Automate the evidence a system can answer (configuration, identities, logs); keep humans for scoping, exceptions, policy and the auditor conversation."
- "Tools carry their own disclaimers (AWS says its sample conformance packs cannot guarantee you will pass an assessment) and their own lifespans. Own your control library in a format you can export, and treat tools as collectors."
related: [riskops, privacyops, devsecops, cloudsecops, accessops, patchops, legalops, fincrimeops, iamops, secops]
---
## What ComplianceOps is
### In 30 seconds
**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.
::: note Term status: emerging, and a word about the name
"ComplianceOps" has no standards-body definition. The compound appears in a few vendor explainers (a 2025 article: "the
comprehensive system that organizations implement to manage obligations across multiple domains"[^opsio]); "compliance
operations" is one governance, risk and compliance (GRC) vendor's operating-model label[^hyperproof] and a job title that, in the
bank and fintech postings found, means customer screening and transaction monitoring ([FinCrimeOps](../fincrimeops/)). Vendors sell
the practice as **continuous controls monitoring** or "continuous compliance".[^ccm] The practice itself is older than any label
([origins](#origins-and-evolution)). Uncited statements are this Atlas's synthesis.
:::
### At a glance
| | |
|---|---|
| **Goal** | Meet every obligation in scope, demonstrably and continuously, at the lowest sustainable cost in attention |
| **Users** | Compliance and GRC managers, control owners who supply evidence, internal audit, executives who sign attestations |
| **Scope** | Obligation inventory, control library and mapping, evidence collection and testing, exceptions, policies, audits, GRC tooling |
| **Out of scope** | How much risk to accept ([RiskOps](../riskops/)); personal-data rights ([PrivacyOps](../privacyops/)); building the technical controls ([DevSecOps](../devsecops/), [CloudSecOps](../cloudsecops/)); financial-crime regulation ([FinCrimeOps](../fincrimeops/)); legal advice ([LegalOps](../legalops/)) |
| **Key outputs** | Obligation register, control library with cross-framework map, evidence store with tests, exception register, policy set, audit calendar |
### The problem it solves
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.[^mulligan] NIST makes the point
from the other side: continuous monitoring "enables organizations to move from compliance-driven risk management to data-driven risk
management".[^sp800137]
### What ComplianceOps is not
- **Not security.** Frameworks are floors written for many organisations at once. Security engineering lives in
[DevSecOps](../devsecops/) and [CloudSecOps](../cloudsecops/); ComplianceOps proves what they did.
- **Not risk management.** [RiskOps](../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](../privacyops/);
the fintech "Compliance Operations" team that screens customers is [FinCrimeOps](../fincrimeops/).
## Where it comes from and where it sits
### Origins and evolution
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".[^sp800137] 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".[^sp80037]
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",[^oscal] 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".[^vanta]
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".[^fedramp20x]
### Glossary and mental model
| Term | Meaning on this page |
|---|---|
| **Obligation** | A rule you must meet: law, regulation, contract clause, standard, internal policy |
| **Requirement** | One testable statement inside an obligation (an Annex A control, a SOC 2 criterion) |
| **Control** | Something a named team does that satisfies one or more requirements: the unit of work |
| **Evidence** | A record that a control operated, with source, timestamp, collection method and freshness rule |
| **Assessment methods** | NIST's *examine* ("checking, inspecting, reviewing, observing, studying, or analyzing one or more assessment objects"), *interview*, and *test* (exercising objects to compare actual with expected behaviour).[^nistglossary] Automation reaches examine and test |
| **Exception (two senses)** | In your register: an approved, time-boxed deviation with scope and expiry. In a SOC report: an instance of "a deficiency in the design or operating effectiveness of a control".[^barr] Describe your exception process in the control itself, or approved exceptions may be reported as deviations |
| **Certification vs attestation** | A certification comes from an accredited body (ISO/IEC 27001); an attestation is a certified public accountant's (CPA's) opinion (SOC 2), not a certification[^soc2standards] |
| **Statement of Applicability (SoA)** | ISO/IEC 27001's list (Clause 6.1.3 d) of the controls you apply (from risk treatment, or law and contract), why each is in or out, and whether it is implemented. Certification auditors work from it: Annex A is a reference list, not a checklist[^soa] |
| **SOC 2 Type 1 / Type 2** | Type 1 reports whether controls are suitably designed and implemented on one date; Type 2 covers their design and operating effectiveness over a period[^soctypes] |
| **QSA / ASV / SAQ** | PCI DSS: a Qualified Security Assessor assesses, an Approved Scanning Vendor scans externally,[^pcidss] and a Self-Assessment Questionnaire is the form for eligible merchants and service providers[^pcisaq] |
**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.
::: figure Where ComplianceOps sits among its neighbours
```mermaid
flowchart LR
R["RiskOps
appetite, acceptance,
what matters"]:::decision
P["PrivacyOps
rights requests,
impact assessments"]:::neutral
S["DevSecOps / CloudSecOps
build and run
technical controls"]:::neutral
A["AccessOps / PatchOps /
BackupOps
operate controls"]:::neutral
L["LegalOps
contracts"]:::neutral
C["ComplianceOps
controls, mapping,
evidence, exceptions,
audits"]:::core
F["FinCrimeOps
KYC, AML, sanctions
(the other
'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
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
```
Text equivalent: ComplianceOps in the centre. RiskOps sends risk decisions and gets evidence back; PrivacyOps sends privacy
obligations; DevSecOps and CloudSecOps send configuration, logs and tests; AccessOps, PatchOps and BackupOps send reviews and
records; LegalOps sends contract clauses. FinCrimeOps (know-your-customer checks, anti-money laundering, sanctions) is joined only
by a dotted line: a name collision.
:::
### How ComplianceOps relates to other Ops
| Neighbour | Shared scope | Neighbour's focus | Handoff |
|---|---|---|---|
| [RiskOps](../riskops/) | GRC tools, control selection, exceptions | Appetite, acceptance, quantification | RiskOps accepts the risk; ComplianceOps records exception and expiry |
| [PrivacyOps](../privacyops/) | Privacy law as obligations | Rights requests, records of processing | ComplianceOps keeps the privacy programme's evidence audit-ready |
| [DevSecOps](../devsecops/) · [CloudSecOps](../cloudsecops/) | Policy as code, configuration checks | Engineering the controls | They make the control true; ComplianceOps proves it stayed true |
| [AccessOps](../accessops/) · [IAMOps](../iamops/) | Access reviews, privileged access | Running reviews and the identity platform | Review evidence for rules such as 23 NYCRR 500.7 |
| [PatchOps](../patchops/) · [VulnerabilityOps](../vulnerabilityops/) · [SecOps](../secops/) | Remediation deadlines, logging | Rollout, detection and response | SLA, log-retention and alerting evidence |
| [LegalOps](../legalops/) · [ProcurementOps](../procurementops/) | Contract clauses, vendor assurance | Contract lifecycle, buying | Customer clauses become obligations; vendor SOC reports become evidence |
| [FinCrimeOps](../fincrimeops/) | The phrase "compliance operations" | Anti-money laundering, customer checks | Name only; link both ways |
## Principles and operating model
### A proposed charter and principles
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.
### Building blocks
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).
### Roles, ownership and RACI
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.[^iia]
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.[^iiapage])
| Activity | Control owner (1st line) | Compliance lead (2nd line) | Security engineering | Internal audit (3rd line) | Executive sponsor |
|---|---|---|---|---|---|
| Define and map controls | **R** | **A** | C | I | I |
| Operate the control | **A/R** | I | C | I | I |
| Collect and test evidence | R | **A** | **R** | I | I |
| Triage failing tests | **R** | A | C | I | I |
| Approve exceptions | C | R | C | I | **A** (with RiskOps's risk owner) |
| Run the audit | C | **A/R** | R | C | I |
Small organisations collapse the columns; whoever operates a control must not be the only person who checks it.
### Lifecycle
- **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.
### Operating model and governance
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.
## Architecture and workflow
### Reference architecture: the control-to-evidence pipeline
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.
::: figure Reference architecture: from systems of record to the audit package
```mermaid
flowchart TB
subgraph SRC["Sources of truth"]
direction LR
I["Identity provider"]:::neutral
K["Cloud accounts
and clusters"]:::neutral
G["Code hosting
and CI"]:::neutral
T["Ticketing, HR,
LMS, vendors"]:::neutral
end
COL["Collectors
APIs, policy engines, scripts,
manual uploads with due dates"]:::core
EV["Evidence store
immutable, hashed, timestamped,
access-controlled, retained"]:::core
TEST["Tests
expected vs actual,
freshness rules"]:::core
LIB["Control library and mapping
owners, frequencies,
requirements per framework"]:::decision
EXC["Exception register
scope, approver, expiry"]:::decision
STATE["Compliance state
per control, per framework"]:::core
AUD["Audit package and
auditor request tracker"]:::neutral
LEAD["Leadership report:
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
```
Text equivalent: Four sources of truth (identity provider; cloud accounts and clusters; code hosting and CI; ticketing, HR, LMS and
vendor systems) feed collectors, which write to an immutable, hashed, timestamped evidence store. Tests read the evidence and the
control library; with the exception register they set a compliance state per control and framework, which feeds the audit package
and a leadership report that puts compliance state next to security posture.
:::
- **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"[^hipaa]).
- **Tests** are code in version control, reviewed like any change.
### End-to-end workflow
**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).
::: figure Daily loop: what happens when a control test fails
```mermaid
flowchart TB
F["Test fails"]:::risk --> Q{"Live exception names
every failing resource?"}:::decision
Q -- "yes" --> E["Record as covered;
check expiry date"]:::neutral
Q -- "no" --> O["Notify control owner;
open ticket with due date"]:::core
O --> D{"Fix within
control SLA?"}:::decision
D -- "yes" --> X["Fix; test passes;
failure stays in history"]:::core
D -- "no" --> R["Request exception:
scope, compensating control,
approver, expiry"]:::decision
R --> A{"Approved by
risk owner?"}:::decision
A -- "yes" --> E
A -- "no" --> S["Escalate as open finding;
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
```
Text equivalent: A failure is recorded as covered, with its expiry checked, only if a live exception names every failing
resource. Otherwise the owner gets a ticket. A fix within the control's SLA makes the test pass, the failure kept in history; if
not, an exception is requested with scope, compensating control, approver and expiry, and is either approved by the risk owner
(covered) or escalated to leadership as an open finding.
:::
## Frameworks, audits and the mapping problem
### The frameworks you will meet
A map, not legal advice; every row is time-sensitive (as of 2026-10-17) and jurisdiction matters.
| Framework | What it is | Who checks, how often | Evidence shape |
|---|---|---|---|
| **ISO/IEC 27001:2022** | Information security management system (ISMS) standard; certification needs Clauses 4–10,[^bsi27001] including risk assessment and treatment; Annex A lists 93 controls[^iso518] | Accredited body; Stage 1 and 2; certificate valid three years with annual surveillance[^alignisms] | Risk assessment and treatment, SoA, internal audit, management review |
| **SOC 2** | Attestation by a CPA firm on the AICPA Trust Services Criteria[^aicpa] | Type 2 period "generally 6, 9, or 12 months"; Security always in scope, four categories optional[^linford] | System description, control matrix, sampled evidence across the period |
| **PCI DSS v4.0.1** | Prescriptive "baseline of technical and operational requirements designed to protect payment account data";[^pcidss] sole version since 2025-01-01[^pci401] | Annual validation, by a QSA's Report on Compliance or a self-assessment questionnaire as the acquirer or payment brand requires;[^pcisaq][^pciscope] external ASV scans "At least once every three months" (11.3.2)[^pcireq] | Configuration, scans, segmentation tests, policies, training, logs |
| **HIPAA Security Rule** | US regulation; specifications "required or addressable", the latter implemented or documented as not reasonable and appropriate[^hipaa] | HHS Office for Civil Rights after complaints, breaches or audits; no certificate | Risk analysis, periodic evaluation, six-year documentation[^hipaa] |
| **SP 800-53 Rev. 5 / FedRAMP** | Controls in 20 families (Release 5.2.0, 2025-08-27), published in OSCAL, with assessment procedures in SP 800-53A[^sp80053] | Authorizing officials and assessors under the RMF; FedRAMP 20x adds machine-validated indicators ([advanced topics](#advanced-topics-and-emerging-direction)) | System security plan, assessment results, plan of action and milestones |
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.[^sox404]
- **DORA** (EU Regulation 2022/2554): applies from 2025-01-17 to "20 different types of financial entities and ICT third-party
service providers".[^dora]
- **NIS2** (EU directive): covers "18 critical sectors"; member states had to transpose it by 2024-10-17.[^nis2]
- **23 NYCRR 500** (entities regulated by New York's Department of Financial Services): access reviewed "at a minimum
annually";[^nycrr500] each April 15, a certification of material compliance or an acknowledgment of noncompliance, signed by
the highest-ranking executive and the CISO.[^nycrr50017]
The HIPAA Security Rule is under revision: proposed 2025-01-06;[^hipaanprm] as of 2026-10-17 the Unified Agenda projects final
action for July 2027 (an earlier edition said May 2026).[^hipaaagenda] The clocks in the
table differ, so one audit calendar merges them.
### How audits actually work
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);[^soc2standards] the international counterpart is ISAE 3000 (Revised), for "assurance engagements other than audits or
reviews of historical financial information".[^isae3000]
::: figure How a sampled control is audited from a continuous evidence store
```mermaid
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,
then a sample of 25
L->>S: Query exports and
sign-offs for the period
S-->>L: Artefacts with hash,
run time, test history
L-->>A: Package: population,
samples, exceptions
A->>O: Interview: how is
the review done?
O-->>A: Walk-through matches
the control description
A-->>L: Observations and
findings, if any
```
Text equivalent: The auditor asks the compliance lead for the population behind AC-01, then a sample of 25. The lead queries the
evidence store for artefacts with hash, run time and test history and returns population, samples and exceptions. The auditor
interviews the control owner, whose walk-through matches the description, and returns observations and 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;[^vanta] a per-test PDF that "lists
failed resources along with any exclusions for that test"[^drata]). 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".[^barr]
### Control mapping across frameworks
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;[^iso518] PCI DSS 7.2.4
requires every user account and its privileges to be reviewed "At least once every six months";[^pcireq] 23 NYCRR 500.7 says "at a
minimum annually".[^nycrr500] 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",[^olir] and
CSF 2.0's Informative References are "mappings that indicate relationships between the Core and various standards, guidelines,
regulations, and other content".[^csf20]
**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.
## Practices, compliance as code and tools
### Core practices and playbooks
| Practice | Goal | Trigger | Owner | Output | Verification |
|---|---|---|---|---|---|
| Obligation intake | Nothing in scope is unknown | New contract, market, product, regulation | Compliance lead with LegalOps | Register entry, mapped requirements, gap list | Quarterly reconciliation with contracts |
| Evidence as data | Machine-collected evidence with provenance | Control record approved | Security engineering | Collector, store path, test | Run history; spot checks |
| Failure triage | Failures fixed or covered within SLA | Test fails | Control owner | Ticket, fix or exception | Monthly time-to-resolve review |
| Exception management | Deviations honest and time-boxed | Fix impossible in SLA | Risk owner approves | Register entry with scope and expiry | Expiry alerts; expired = failure |
| Audit service | Audit answered from existing records | Audit scheduled | Compliance lead | Request tracker, package | Requests answered without new collection |
#### Vendor reports, questionnaires and PCI scope
Four first-year jobs that no framework headline names:
| Job | What it involves | What the library holds |
|---|---|---|
| Vendors' SOC reports | Cloud and SaaS providers are *subservice organisations*, excluded from your report (*carve-out*) or tested with you (*inclusive*) and monitored by you either way; their reports list **complementary user entity controls (CUECs)** you must operate[^linfordsub] | A review control: period, opinion, deficiencies, CUECs mapped to your controls |
| Gaps between reports | A **bridge letter**: management's statement that nothing significant changed since the last report, "not prepared, signed, or validated by service auditors"[^bridge] | Dated letters; never a substitute for the next report |
| Security questionnaires | The daily consumer of your evidence; publishing answers (CAIQ) in the Cloud Security Alliance's STAR Registry "helps alleviate the need to fill out multiple customer questionnaires"[^csastar] | Answers citing control and evidence ids, so they age with the evidence |
| PCI DSS scope | Start "with the assumption that everything is in scope until verified otherwise"; segmentation, outsourcing and P2PE solutions shrink scope, and tokenization can "reduce the applicability of some PCI DSS requirements"; nothing removes them all[^pciscope] | Data-flow diagram, segmentation tests, the validation route the acquirer requires |
### Compliance as code and policy as code
**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_`"[^opa]); Prowler maps its checks to frameworks including CIS,
PCI-DSS, HIPAA, SOC2 and ISO 27001;[^prowler] 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".[^awscp] OSCAL
expresses catalogs, profiles, security plans and assessment results as documents,[^oscal]
which compliance-trestle edits and validates[^trestle] and
[Lab 2](#lab-2-intermediate-a-control-ownership-skeleton-from-nists-oscal-files) reads.
::: caution Policy as code enforces; it does not by itself prove
A deny rule in CI proves that non-compliant changes were blocked *when the rule ran*, not that every change went through CI or that
nobody bypassed it. Evidence therefore includes the rule's version history, who can bypass the pipeline, and the population of
changes (see [DevSecOps](../devsecops/)).
:::
### Tooling landscape
| Category | Job | Representative verified options (2026-10-17) | Limits and selection criteria |
|---|---|---|---|
| GRC / compliance automation platforms | Library, mappings, tests, evidence store, auditor portal | Vanta, Drata, Hyperproof; many others | Library lock-in; integration coverage for *your* stack; export quality |
| Cloud-native compliance services | Rule packs per framework inside one cloud | AWS Config conformance packs,[^awscp] Azure Policy regulatory compliance (marked Preview on the page read),[^azurerc] AWS Audit Manager (maintenance mode; no new accounts since 2026-04-30) | One cloud, technical controls only: AWS's packs "contain only the technical Core Controls that can be evaluated as Config Rules"[^auditmanager] |
| Open-source scanners | Configuration checks mapped to benchmarks | Prowler (Apache-2.0),[^prowler] CISA ScubaGear / ScubaGoggles for Microsoft 365 and Google Workspace[^scuba] | You own scheduling, storage and mapping |
| Policy as code engines | Enforce rules in CI and at admission | OPA,[^opa] Conftest,[^conftest] Chef InSpec (Apache-2.0 source; packaged versions "require accepting the EULA to use")[^inspec] | Rules need tests and owners; enforcement settings must be evidenced |
| Open standards | Tool-independent documents | OSCAL,[^oscal] compliance-trestle[^trestle] | More engineering; fewer turnkey integrations |
### Automation and AI
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,[^hipaa] 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](../privacyops/) covers personal data in prompts).
## ComplianceOps in practice
### Reference implementation
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](#metrics-and-kpis), 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._
```json
{
"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._
```python
"""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]))
```
```text
$ 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.
### Hands-on labs
#### Lab 1 (beginner): run and extend the control library checker
**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.
#### Lab 2 (intermediate): a control-ownership skeleton from NIST's OSCAL files
**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:
```bash
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._
```python
"""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]))
```
```text
$ 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.
#### Lab 3 (advanced): a cloud conformance pack as a detective control with evidence
**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[^awscpprereq]); 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.[^awscli] AWS recommends removing rules not available in your Region
first.[^awscp] **Costs and risks:** AWS Config charges per configuration item recorded and per conformance pack
evaluation;[^awsconfigprice] 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)._
```bash
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).[^awscli] **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.
### Use cases and scenarios
**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[^fedramp20x]).** *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.
## Measure, govern, pay
### Metrics and KPIs
**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.
::: figure Evidence and exception states, and how each one counts
```mermaid
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
}
```
Text equivalent: An evidence item is Fresh when collected (counts as tested) and turns Stale when its age passes the control's
frequency (counts as missing) until collected again; the old item is kept. An exception goes from Requested to Live when approved
with scope and expiry (covering only the resources it names), to Expired when its date passes (a failure), and to Closed when the
control is fixed, its history kept.
:::
| KPI | Formula | Source | Pitfall | Cadence |
|---|---|---|---|---|
| Requirement coverage | mapped requirements ÷ requirements in scope, per framework | Library | 100 % with weak controls | Monthly |
| Evidence freshness | items within their frequency ÷ all items | Store | Long frequencies hide decay | Weekly |
| Automated-evidence ratio | automated items ÷ all items | Store | Automating only the easy controls | Quarterly |
| Control pass rate | (passing + covered) ÷ controls tested | Tests | Re-runs until green; count first runs | Daily |
| Untested controls | controls with any stale item or no evidence | Store | Hidden behind the pass rate | Daily |
| Time to resolve a failing control | fix date − first failure date (mean and oldest open) | Tickets | Means hide the tail | Monthly |
| Self-found ratio | failures your tests found ÷ (yours + auditor's + incidents) | Tests, audit file, incidents | Few tests, few finds | Quarterly |
**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.
### Quality, security and privacy of the compliance system itself
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).
### Cost, capacity and sustainability
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.
### Assurance of the operating model
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.[^iia]
## When things go wrong
### Common failures and troubleshooting
| Symptom | Likely cause | Diagnosis | Remediation | Prevention |
|---|---|---|---|---|
| Daily evidence stale for a week | Collector credential expired or API changed | Collector logs; last successful run | Rotate; re-run; record the gap | Alert on missed runs, not only failures |
| Passes in the tool, fails in reality | Test narrower than the requirement (policy exists ≠ enforced) | Read the test against the requirement | Rewrite; evidence the enforcement settings | Peer-review tests; break tests |
| Audit finds an unknown system | Scope drift; inventory not a control | Reconcile cloud inventory with the system description | Add the system and disclose | Asset inventory as a control with evidence |
| Exceptions pile up | No expiry enforcement; junior approvers | Age distribution | Expire, re-approve or close with the risk owner | Automatic expiry; approver tiers |
### Worked runbook: an evidence gap discovered mid-period
*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](#reference-implementation)).
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 ", 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.[^barr]
6. **Prevent (week 1).** Missed-run alerts for every collector; protect the cloud role; add the scenario to the break test.
### Anti-patterns and myths
- **"We are SOC 2 certified."** SOC 2 is a CPA's attestation report, not a certification;[^soc2standards] 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.
## Deciding and adopting
### When to use and when not to use
**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](../devsecops/) and [CloudSecOps](../cloudsecops/).
### Decision framework
::: figure Decision tree: how much ComplianceOps, and where to keep the library
```mermaid
flowchart TB
S["How many obligations with
overlapping controls?"]:::decision
S -- "one, point in time" --> C1["Checklist + calendar;
revisit in a year"]:::neutral
S -- "two or more, or any
period-based audit" --> O["Who can own the
control library?"]:::decision
O -- "nobody yet" --> C2["Name an owner first;
no tool fixes this"]:::risk
O -- "named owner" --> T["Stack and audience?"]:::decision
T -- "SaaS on major cloud,
commercial audits" --> G["GRC platform;
export library quarterly"]:::core
T -- "one cloud, technical
controls dominate" --> N["Cloud-native rules +
scanner + Lab 1 library"]:::core
T -- "government / multi-tool /
long-lived estate" --> X["OSCAL library +
trestle; tools as collectors"]:::core
G --> E["Any choice: evidence store
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
```
Text equivalent: One point-in-time obligation: a checklist and calendar. Two or more, or a period-based audit: without an owner
for the library, name one first. Then the stack decides: SaaS on a major cloud with commercial audits, a GRC platform exported
quarterly; one cloud with mostly technical controls, cloud-native rules, a scanner and the Lab 1 library; government or
long-lived estates, an OSCAL library with trestle. Every branch needs an evidence store and an exception register.
:::
#### Weighted comparison: where the library lives
Scores 1–3 (higher is better) and weights are this Atlas's judgement; a total sums weight × score, out of 45.
| Criterion (weight) | GRC platform | Cloud-native + scripts | OSCAL + trestle |
|---|---|---|---|
| Speed to first audit (3) | 3 | 2 | 1 |
| Coverage of people and process controls (3) | 3 | 1 | 2 |
| Exportability and durability of the library (3) | 2 (verify the export) | 2 | 3 |
| Low engineering effort to run (2) | 3 | 2 | 1 |
| Low licence and usage fees (2; staff time counts above) | 1 (subscription) | 2 (usage charges) | 3 (open source) |
| Fit for government work (2) | 2 (varies by vendor) | 2 | 3 |
| **Weighted total** | **36** | **27** | **32** |
A weak export (score 1) cuts the platform to 33, one point above the open library: the
[judgement call](#a-judgement-call-rent-a-grc-platform-now-or-build-on-cloud-native-tooling-and-an) turns on that row.
### Maturity model
**This Atlas's model**, not an industry standard.
| Level | Observable behaviour | Evidence | Exit criteria |
|---|---|---|---|
| 1 Reactive | Annual project; evidence on request; a spreadsheet per framework | Audit files only | Register and named owner exist |
| 2 Organised | One mapped library; manual evidence with due dates; exception register | Library in version control or a platform | Every requirement maps to an owned control |
| 3 Continuous | Automated tests for technical controls; freshness rules; daily triage | Test history; freshness report | Automated ratio above half; nothing stale at period start |
| 4 Integrated | Policy as code in pipelines; audits served from the store; posture reported alongside | Requests answered without new collection | Self-found ratio above the auditor's share |
| 5 Machine-verifiable | Library and results in open formats; assessors review validation code | OSCAL documents, validation code | Worth it only where a programme (such as FedRAMP 20x) rewards it |
### Adoption roadmap: 30/60/90 days
- **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](#lab-1-beginner-run-and-extend-the-control-library-checker) 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.
## Toolkit
### Checklists
**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
### Templates
**Control record** (JSON form in the reference implementation). The floors are those cited in the
[mapping section](#control-mapping-across-frameworks); the 90-day value is a fictional internal policy stricter than all three.
```yaml
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**
```yaml
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.
### FAQ
**Is "ComplianceOps" a recognised discipline?** No; it is an emerging, vendor-led label for continuous monitoring and ongoing
authorization ([origins](#origins-and-evolution)).
**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.[^nistglossary]
**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,[^csastar] with a bridge letter if the report period ended months ago.[^bridge]
**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.[^auditmanager] Own the library; treat tools as collectors.
## Going further
### Advanced topics and emerging direction
- **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.[^fedramp20x] This Atlas expects other programmes to copy the shape.
- **OSCAL as lingua franca.** NIST publishes SP 800-53 in OSCAL;[^sp80053] 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),[^pci401] the proposed HIPAA
update and AI regulation ([ModelOps](../modelops/)) all land on one library; the obligation register needs a change feed.
### Learning path
- **Prerequisites:** none. [RiskOps](../riskops/) shows how controls are chosen, [AccessOps](../accessops/) the most audited one.
- **One day:** this page; SP 800-137's first chapter;[^sp800137] 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.
## Wrap-up
### Executive recap and cheat sheet
- **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.
### A judgement call: rent a GRC platform now, or build on cloud-native tooling and an open library?
*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.
### Learning objectives and mastery check
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?**
::: answer Show answer
The test was narrower than the requirement: it checked that an MFA policy existed, not that it covered every identity type. An
export of all identities with their MFA state would have shown it; add it as evidence and record a self-found failure.
:::
**2. On 20 April, mid-period, you find the cloud configuration collector has failed since 10 April. Can you back-fill?**
::: answer Show answer
Never by back-dating. Reconstruct from configuration history, labelled retrospective and dated when collected; assess whether the
control operated; disclose. If it did not, it is an exception in the report however it was found.
:::
**3. Why record each framework's floor and who imposed the parameter you run?**
::: answer Show answer
Because mapping is lossy. `AC-01` runs quarterly under internal policy; its floors are six months (PCI DSS 7.2.4) and annual (23
NYCRR 500.7). The record shows how far the control may relax, and that the floor becomes annual if PCI leaves scope.
:::
**4. May a language model draft the quarterly access-review summary from the raw export?**
::: answer Show answer
Drafting a summary for the reviewer, yes; storing it as evidence, no. The evidence is the reviewer's dated decision on the
population: the raw export, the sign-off and the removals ticket.
:::
**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?**
::: answer Show answer
Fix the account: enrol it in MFA and close X-02, history kept. Extend only if a fix is impossible within the SLA, with a
compensating control and approval at the right tier; a new date alone turns the check green without reducing risk.
:::
### Conclusion
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.
## Sources and further reading
[^opsio]: [ComplianceOps Explained for Risk Management](https://opsiocloud.com/knowledge-base/what-is-complianceops/) — Opsio, 2025-08-21 (updated 2025-10-02). Checked 2026-10-17.
[^hyperproof]: [Compliance Operations](https://hyperproof.io/compliance-operations) — Hyperproof, undated. Checked 2026-10-17.
[^ccm]: [Continuous Controls Monitoring: Definition and Best Practices](https://hyperproof.io/resource/what-is-continuous-controls-monitoring/) — Hyperproof (GRC vendor), updated 2026-07-07. Checked 2026-10-17.
[^sp800137]: [Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations, SP 800-137](https://csrc.nist.gov/pubs/sp/800/137/final) — NIST, 2011-09-30 ([PDF](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-137.pdf)). Checked 2026-10-17.
[^sp80037]: [Risk Management Framework for Information Systems and Organizations, SP 800-37 Rev. 2](https://csrc.nist.gov/pubs/sp/800/37/r2/final) — NIST, 2018-12-20. Checked 2026-10-17.
[^fedramp20x]: [FedRAMP 20x](https://www.fedramp.gov/20x/) — FedRAMP (GSA), living page; Phase 3 marked active when checked. Checked 2026-10-17.
[^mulligan]: [Written testimony of John J. Mulligan (Target), House Energy and Commerce subcommittee hearing](https://docs.house.gov/meetings/IF/IF17/20140205/101714/HMTG-113-IF17-Wstate-MulliganJ-20140205.pdf) — U.S. House of Representatives, 2014-02-05. Checked 2026-10-17.
[^oscal]: [OSCAL](https://pages.nist.gov/OSCAL/) (updated 2026-06-02) and [OSCAL Layers and Models](https://pages.nist.gov/OSCAL/learn/concepts/layer/) — NIST. Checked 2026-10-17.
[^vanta]: [Automated Test Evidence](https://help.vanta.com/en/articles/11345529-automated-test-evidence) — Vanta Help Center, 2026-06-29. Checked 2026-10-17.
[^drata]: [Evidence Overview](https://help.drata.com/en/articles/8288579-evidence-library-overview) — Drata Help Center, 2026-05-21. Checked 2026-10-17.
[^nistglossary]: [NIST CSRC Glossary: examine](https://csrc.nist.gov/glossary/term/examine), [interview](https://csrc.nist.gov/glossary/term/interview), [test](https://csrc.nist.gov/glossary/term/test) — NIST (from SP 800-53A Rev. 5). Checked 2026-10-17.
[^barr]: [Common SOC Report Exceptions and How To Mitigate Them](https://www.barradvisory.com/resource/common-soc-report-exceptions/) — BARR Advisory, 2022-07-05. Checked 2026-10-17.
[^soc2standards]: [SOC Certifications: Are SOC 1 & SOC 2 Audits Actually Certifications?](https://linfordco.com/blog/soc-certification/) — Nicole Hemmer, Linford & Company (CPA firm), 2019-03-27. Checked 2026-10-17.
[^linford]: [SOC 2 Type 2 Reports – A Comprehensive Guide](https://linfordco.com/blog/soc-2-type-2-report/) — Kevin Anderson, Linford & Company, 2024-05-22. Checked 2026-10-17.
[^soctypes]: [What Is SOC 2 Compliance? Requirements, Reports & Audits Explained by a Veteran IT Auditor](https://linfordco.com/blog/what-is-soc-2/) — Rob Pierce, Linford & Company, 2026-10-14. Checked 2026-10-17.
[^pcidss]: [PCI DSS](https://www.pcisecuritystandards.org/standards/pci-dss/) — PCI Security Standards Council, undated. Checked 2026-10-17.
[^pcisaq]: [What is a PCI DSS Self-Assessment Questionnaire?](https://www.pcisecuritystandards.org/faq/articles/Frequently_Asked_Question/what-is-a-pci-dss-self-assessment-questionnaire/) — PCI Security Standards Council FAQ. Checked 2026-10-17.
[^nycrr500]: [23 NYCRR 500.7 — Access privileges and management](https://www.law.cornell.edu/regulations/new-york/23-NYCRR-500.7) — Cornell LII, amended effective 2023-11-01. Checked 2026-10-17.
[^iiapage]: [The IIA's Three Lines Model: An update of the Three Lines of Defense (web page)](https://www.theiia.org/en/content/position-papers/2020/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense/) — The Institute of Internal Auditors, 2020-09-08 (updated 2024-09), marked "superseded". Checked 2026-10-17.
[^iia]: [The IIA's Three Lines Model: An update of the Three Lines of Defense (PDF)](https://www.theiia.org/globalassets/documents/resources/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense-july-2020/three-lines-model-updated-english.pdf) — The Institute of Internal Auditors, 2020-07. Checked 2026-10-17.
[^hipaa]: [45 CFR § 164.306](https://www.law.cornell.edu/cfr/text/45/164.306) (general rules), [§ 164.308](https://www.law.cornell.edu/cfr/text/45/164.308) (administrative safeguards) and [§ 164.316](https://www.law.cornell.edu/cfr/text/45/164.316) (documentation) — Cornell LII. Checked 2026-10-17.
[^bsi27001]: [ISO/IEC 27001 Information Security Management](https://www.bsigroup.com/en-GB/products-and-services/standards/iso-iec-27001-information-security-management-system/) — BSI Group, undated. Checked 2026-10-17.
[^alignisms]: [Explaining the ISO 27001 Certification Process](https://www.a-lign.com/articles/iso-27001-certification-process) — A-LIGN, undated. Checked 2026-10-17.
[^aicpa]: [SOC 2](https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2) and [2017 Trust Services Criteria (With Revised Points of Focus – 2022)](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022) — AICPA & CIMA. Checked 2026-10-17.
[^pci401]: [Just Published: PCI DSS v4.0.1](https://blog.pcisecuritystandards.org/just-published-pci-dss-v4-0-1) — PCI Security Standards Council, 2024-06-11. Checked 2026-10-17.
[^pciscope]: [Guidance for PCI DSS Scoping and Network Segmentation](https://listings.pcisecuritystandards.org/documents/Guidance-PCI-DSS-Scoping-and-Segmentation_v1_1.pdf) — PCI Security Standards Council, information supplement v1.1, 2017-05 (written against PCI DSS v3.2). Checked 2026-10-17.
[^iso518]: [ISO 27001 Control 5.18 – Access rights](https://advisera.com/iso27001/control-5-18-access-rights/) — Advisera (ISO consultancy; secondary summary; its contents list Clauses 4–10 and all 93 Annex A controls), undated. Checked 2026-10-17.
[^soa]: [Statement of Applicability in ISO 27001 – What is it and why does it matter?](https://advisera.com/27001academy/knowledgebase/the-importance-of-statement-of-applicability-for-iso-27001/) — Dejan Kosutic, Advisera (secondary summary of Clause 6.1.3 d), undated. Checked 2026-10-17.
[^pcireq]: [PCI DSS v4.0.1 Requirement 7.2.4](https://ce.prod.cloudaware.com/frameworks/pci-dss-v4.0.1/07/02/04) and [Requirement 11.3.2](https://ce.prod.cloudaware.com/frameworks/pci-dss-v4.0.1/11/03/02) — Cloudaware (secondary reproduction; the PCI SSC PDF is licence-gated). Checked 2026-10-17.
[^sp80053]: [SP 800-53 Rev. 5](https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) (Release 5.2.0, 2025-08-27) and [SP 800-53A Rev. 5](https://csrc.nist.gov/pubs/sp/800/53/a/r5/final) (2022-01-25) — NIST. Checked 2026-10-17.
[^sox404]: [15 U.S. Code § 7262 — Management assessment of internal controls](https://www.law.cornell.edu/uscode/text/15/7262) — Cornell LII. Checked 2026-10-17.
[^dora]: [Digital Operational Resilience Act (DORA)](https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en) — EIOPA. Checked 2026-10-17.
[^nis2]: [NIS2 Directive](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive) — European Commission. Checked 2026-10-17.
[^nycrr50017]: [23 NYCRR 500.17 — Notices to superintendent](https://www.law.cornell.edu/regulations/new-york/23-NYCRR-500.17) — Cornell LII, subsection (b), amended effective 2023-11-01. Checked 2026-10-17.
[^hipaanprm]: [HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (proposed rule, 90 FR 898)](https://www.govinfo.gov/content/pkg/FR-2025-01-06/pdf/2024-30983.pdf) — HHS Office for Civil Rights via GovInfo, 2025-01-06. Checked 2026-10-17.
[^hipaaagenda]: [Unified Agenda entry, RIN 0945-AA22](https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=202510&RIN=0945-AA22) — OIRA, reginfo.gov (Long-Term Actions, final action 07/00/2027; the Spring 2025 edition listed 05/00/2026). Checked 2026-10-17.
[^isae3000]: [ISAE 3000 (Revised), Assurance Engagements Other than Audits or Reviews of Historical Financial Information](https://www.iaasb.org/publications/international-standard-assurance-engagements-isae-3000-revised-assurance-engagements-other-audits-or) — IAASB, effective 2015-12-15. Checked 2026-10-17.
[^olir]: [National Online Informative References (OLIR) Program, NIST IR 8278 Rev. 1](https://csrc.nist.gov/pubs/ir/8278/r1/final) — NIST, 2024-02-26. Checked 2026-10-17.
[^csf20]: [The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final) — NIST, 2024-02-26 ([PDF](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf)). Checked 2026-10-17.
[^linfordsub]: [Monitoring Controls at Subservice Organizations](https://linfordco.com/blog/monitoring-subservice-organization-controls-soc-reports/) (Kevin Anderson, 2023-07-19) and [Carve-Out vs Inclusive Method](https://linfordco.com/blog/subservice-carve-out-inclusive-audits/) (Isaac Clarke, 2025-06-25) — Linford & Company. Checked 2026-10-17.
[^bridge]: [How bridge letters help mind the gap between audit periods](https://www.grantthornton.co.uk/insights/how-bridge-letters-help-mind-the-gap-between-audit-periods/) — Tim Foster-Key and Pooja Behl, Grant Thornton UK, 2025-09-17. Checked 2026-10-17.
[^csastar]: [Security, Trust, Assurance and Risk (STAR)](https://cloudsecurityalliance.org/star/) — Cloud Security Alliance. Checked 2026-10-17.
[^opa]: [Policy Testing](https://www.openpolicyagent.org/docs/policy-testing) and [documentation](https://www.openpolicyagent.org/docs/latest/) — Open Policy Agent. Checked 2026-10-17.
[^prowler]: [Prowler README](https://github.com/prowler-cloud/prowler) — prowler-cloud on GitHub (Apache-2.0). Checked 2026-10-17.
[^awscp]: [Conformance Packs for AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html) and [Conformance Pack Sample Templates](https://docs.aws.amazon.com/config/latest/developerguide/conformancepack-sample-templates.html) — AWS, living docs. Checked 2026-10-17.
[^trestle]: [compliance-trestle documentation](https://oscal-compass.dev/compliance-trestle/latest/) — OSCAL Compass (CNCF sandbox). Checked 2026-10-17.
[^azurerc]: [Regulatory Compliance in initiative definitions](https://learn.microsoft.com/en-us/azure/governance/policy/concepts/regulatory-compliance) — Microsoft Learn, updated 2025-12-01. Checked 2026-10-17.
[^auditmanager]: [AWS Audit Manager availability change](https://docs.aws.amazon.com/audit-manager/latest/userguide/audit-manager-availability-change.html) — AWS, living doc. Checked 2026-10-17.
[^scuba]: [Secure Cloud Business Applications (SCuBA) Project](https://www.cisa.gov/resources-tools/services/secure-cloud-business-applications-scuba-project) — CISA. Checked 2026-10-17.
[^conftest]: [Conftest](https://www.conftest.dev/) — Conftest project. Checked 2026-10-17.
[^inspec]: [Chef InSpec README](https://github.com/inspec/inspec) — inspec/inspec on GitHub. Checked 2026-10-17.
[^awscpprereq]: [Prerequisite for Conformance Packs for AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/cpack-prerequisites.html) — AWS, living doc. Checked 2026-10-17.
[^awscli]: AWS CLI reference: [put-conformance-pack](https://docs.aws.amazon.com/cli/latest/reference/configservice/put-conformance-pack.html), [describe-conformance-pack-status](https://docs.aws.amazon.com/cli/latest/reference/configservice/describe-conformance-pack-status.html), [describe-conformance-pack-compliance](https://docs.aws.amazon.com/cli/latest/reference/configservice/describe-conformance-pack-compliance.html), [get-conformance-pack-compliance-details](https://docs.aws.amazon.com/cli/latest/reference/configservice/get-conformance-pack-compliance-details.html); API reference: [PutConformancePack](https://docs.aws.amazon.com/config/latest/APIReference/API_PutConformancePack.html); IAM User Guide: [Create a service-linked role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create-service-linked-role.html) — AWS. Checked 2026-10-17.
[^awsconfigprice]: [AWS Config Pricing](https://aws.amazon.com/config/pricing/) — AWS. Checked 2026-10-17.
**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`).