Compliance coverage scoring

Resolve a named framework to its criteria list, score each criterion against the evidence that actually exists, and record every excluded criterion with the four fields that make an exclusion survivable under challenge.

This produces a readiness self-assessment only

The result is a readiness self-assessment: not certification, not an attestation, not an audit opinion, and not legal advice. Nothing produced here demonstrates compliance to a regulator, a customer, or a court. It is an internal gap list that tells a team what to fix before a qualified party looks, and only a qualified party can attest - none of them is you.

Write that framing into the artifact itself, at the top, every time. A readiness matrix that circulates without it gets mistaken for evidence of compliance. For who can attest per framework and for precise result wording, see references/frameworks.md.

What this owns, and what it does not

Owns: resolving a framework plus version to a criteria list, assigning one of four states per criterion, defining what evidence each state requires, recording scope exclusions, and emitting a coverage matrix with a readiness verdict.

Does not own: implementing controls, writing the tests, running scanners, collecting or storing evidence artifacts, and certifying anything. Those are separate jobs with separate outputs. This one reads what exists and scores it.

Step 1: resolve the framework to a versioned criteria list

A criteria list without a version is not scorable. Name the edition in the output header, and take the criterion identifiers from the source of record rather than from memory.

Per-framework notes that change how the list is built - GDPR chapters by controller/processor role, the CPRA amendments to score against, why SOC 2 criterion IDs must be pasted from the AICPA document rather than invented, keeping the HIPAA Security/Privacy/Breach subparts unmixed, the PCI DSS v4.0.1 version pin, and the ISO/IEC 27001:2022 full-reference rule - are in references/frameworks.md. Read the note for whichever framework is in play before building its list.

Required versus addressable (HIPAA specifically)

45 CFR §164.306(d) states that implementation specifications are either required or addressable, with the word "Required" or "Addressable" printed in parentheses after the title, and that for an addressable specification the entity must assess whether it is reasonable and appropriate, document the decision, and implement an equivalent alternative where reasonable and appropriate (§164.306). So "Encryption and decryption (Addressable)" at §164.312(a)(2)(iv) with a documented alternative is a documented deviation, not a gap, and is scored met with the deviation record as its evidence. "Unique user identification (Required)" at §164.312(a)(2)(i) has no such route.

Step 2: score each criterion

Four states. Each has an evidence bar, and a criterion that does not clear its bar drops to the state below.

Four scoring rules that decide most disputed cells:

1. One criterion, one dedicated verification. An artifact claimed to cover several criteria at once is scored partial for each of them until each criterion has its own verification, or the composite artifact names each criterion and shows a distinct result per criterion. Assessors sample per criterion, so a bundled artifact reads as a gap on whichever one gets sampled.
2. Evidence is window-bound. For a period-based engagement, an artifact dated before the period opened does not count toward that period. Score it not met for the current window even if it was met last cycle.
3. Design is not operation. A policy, a runbook, or a one-off screenshot evidences that a control was designed. For a period-based engagement, score design-only evidence partial until there is recurring evidence spanning the window.
4. A failing artifact is worse than a missing one. If the mapped test ran and failed inside the window, score not met and flag it separately: unremediated known failures are the finding an assessor writes up first.

Record, per criterion, the artifact path or identifier and its date. A matrix whose cells say met with nothing beside them cannot be re-checked by anyone, including you next quarter.

Step 3: record scope exclusions (four mandatory fields)

A criterion becomes not applicable only through a written exclusion carrying all four of these. Three out of four is not an exclusion.

Enforcement rules:

• An exclusion missing any field is not not applicable. Score the criterion not met and list the missing field as the action item.
• An exclusion past its re-review date is void on the day it expires. The criterion reverts to not met automatically.
• An exclusion is bound to the scope statement it was approved under. If the scope changes (new system, new data category, new processing purpose, new cardholder-data flow), every exclusion is void until re-approved.
• Exclusions are the first thing a qualified assessor challenges, and several are legal determinations rather than engineering ones. GDPR Art. 27 (representatives of controllers or processors not established in the Union) and Art. 37 (designation of a data protection officer) are routinely excluded on entity-specific grounds, and those grounds need the named approver's judgment recorded, not an engineer's inference.

Exclusion record shape:

- criterion: "164.504(e)"
  framework: "HIPAA Security Rule (45 CFR Part 164 Subpart C)"
  scope: "Business associate, ePHI processing for clinical-trial sponsor X"
  reason: >
    Single-purpose service under one executed BAA with no subcontractor
    handling ePHI; no downstream BAA chain exists to verify.
  approver: "J. Okonkwo, Compliance Officer"
  approved: "2026-04-15"
  re_review: "2026-10-15"

Step 4: emit the coverage matrix

## Compliance readiness self-assessment: <framework + version> (<commit or date>)

> Readiness self-assessment only. Not certification, not an audit opinion,
> not legal advice. Only a qualified assessor can attest to this framework.

**Framework:** HIPAA Security Rule, 45 CFR Part 164 Subpart C
**Scope:** Business associate handling ePHI for a clinical-trial sponsor
**Assessment window:** 2026-01-01 to 2026-06-30
**Criteria in scope:** 24 | **Artifacts mapped:** 47 | **Exclusions:** 1

### Per-criterion coverage

| Criterion | Name | State | Evidence | Action |
|---|---|---|---|---|
| §164.308(a)(1)(ii)(A) | Risk analysis (Required) | met | risk-analysis-2026-02.pdf, 2026-02-11 | none |
| §164.308(a)(3)(ii)(C) | Termination procedures (Addressable) | partial | tests/test_offboarding.py, runs since 2026-04 only | Extend evidence to cover Jan to Mar or restate the window |
| §164.310(d)(2)(i) | Disposal (Required) | partial | tests/test_device_wipe.py asserts wipe occurred, not the method | Assert the sanitization method against a named standard |
| §164.312(a)(2)(i) | Unique user identification (Required) | met | tests/test_unique_user_id.py, green all 6 months | none |
| §164.312(a)(2)(iv) | Encryption and decryption (Addressable) | met | deviation memo 2026-01-08 plus compensating-control record | Re-review at window close |
| §164.312(b) | Audit controls | not met | none mapped | Emit and retain access records for ePHI reads and writes |
| §164.312(e)(1) | Transmission security | partial | tests/test_https_required.py covers redirect only | Add a cipher-strength assertion |
| §164.504(e) | Organizational requirements (BAA) | n/a | Exclusion approved 2026-04-15 by J. Okonkwo, re-review 2026-10-15 | none |

### Summary

met 4 | partial 3 | not met 1 | n/a 1 (1 valid exclusion, 0 invalid)

### Verdict

NOT READY. One in-scope criterion is `not met` (§164.312(b) audit controls) and
three are `partial`.

### Action items, highest severity first

1. §164.312(b): no access-record evidence exists for the window. Closing this
   after the window ends does not retroactively cover the window.
2. §164.310(d)(2)(i): the disposal test asserts that a wipe happened but not
   which method was used. Assert against a named sanitization standard such as
   NIST SP 800-88 Rev. 1 (https://csrc.nist.gov/pubs/sp/800/88/r1/final).
3. §164.312(e)(1): extend the TLS test past redirect behaviour to negotiated
   cipher strength.

Verdict bands. These are a practitioner convention for internal triage, not a threshold defined by any of the frameworks, and no band is a compliance claim:

Step 5: the pre-audit dry run

For any framework assessed over a period rather than at a point in time, one scoring pass at the end is too late: evidence that was never collected in month two cannot be created in month six.

1. Before the window opens. Score the full criteria list while gaps are still fixable. This run is the point of the whole exercise.
2. Monthly during the window. Re-score to catch evidence-collection breakage: a job that stopped writing artifacts in month three turns a met criterion into partial without anyone noticing. Monthly is a convention, not a requirement of any framework; pick a cadence shorter than the time it would take to notice a broken collector.
3. At window close. Final pass before the assessor engages. Anything still partial should be disclosed rather than discovered.
4. After the assessment. Re-baseline the matrix against the actual findings. Where the assessor scored a criterion differently than you did, the difference is the calibration signal: fix the scoring rule, not just the criterion.
5. On any framework version change. A version change invalidates the mapping, not just the content. Rebuild the list from the new source of record and re-score from zero.

Anti-patterns

Naming precision in the output

Precise result wording (never "SOC 2 certified", the ISO/IEC 27001:2022 full-reference rule, stating PCI DSS results with the version and QSA, and why "GDPR compliant" / "CCPA compliant" are not attestable states) is in references/frameworks.md.

Limitations

• Criteria lists here are pointers to sources of record, not copies. Regulatory, AICPA, and ISO texts change on their own schedules; re-read the source each cycle.
• SOC 2 criterion IDs are deliberately absent; the authoritative numbering lives in the AICPA document. Paste the real IDs from there.
• Applying a framework to a specific business, and deciding what is out of scope, are legal determinations. Scoring surfaces the question; a qualified adviser answers it.