Implementation Statements That Survive Assessment

The part that stays human

Everything in Lesson 2.1 was structure — and here is the field’s honest counterweight: in the reference shops running the most automated compliance machinery this training draws on, the implementation statements themselves are written by humans. ISSOs and analysts author them; tools assemble and validate them; nothing generates them on the authoritative path. That’s a deliberate design decision, and it has a reason you should be able to recite: the statement is a claim of fact about your system offered to a stranger whose job is professional skepticism. An LLM-drafted narrative that’s 95% right is 5% confidently wrong in front of the one audience trained to find it. (The same shops prototype LLM-assisted drafting off the authoritative path — the boundary is where the signature goes, not whether AI is useful.)

So this lesson teaches the human workflow the strong shops actually use — and where your AI CLI genuinely helps around its edges.

Adapt-from-predecessor, with an evolution matrix

Nobody writes statements from a blank page. The working method: start from the predecessor system’s statement for the same control — previous authorization, sibling system, or the platform’s provided template — and adapt it. The discipline that keeps this honest is the evolution matrix: a before/after table, per control, showing exactly what changed from the predecessor’s language and why.

| Control | Predecessor said            | We say                      | Why it changed              |
|---------|-----------------------------|-----------------------------|-----------------------------|
| AC-2    | quarterly access review     | monthly, automated diff     | new IdP made monthly cheap  |
|         | by system owner             | + quarterly ISSO signoff    | (evidence: ac-2 collector)  |
| SC-7    | boundary = on-prem firewall | boundary = cloud perimeter  | architecture change; scope  |
|         |                             | + private endpoints         | re-drawn (see EX-002)       |

The matrix looks like bookkeeping. It’s actually the document that shortens your assessment most — because the assessor’s fastest workflow is differential too: they’ve likely assessed the predecessor, and the matrix tells them where to spend scarce hours (Lesson 1.3’s arithmetic, working in your favor for once). A statement set with an evolution matrix says “we know exactly how we differ from the last thing you approved.” That’s what surviving assessment looks like. For the people funding this: it is assessor-hours spent on your real changes instead of on re-reading what was already approved — calendar time off the authorization.

Where the AI CLI helps at the edges — the review, not the authorship:

Diff our draft statements against the predecessor set. For each control:
1) changes in MEANING (coverage, frequency, responsible role, boundary) -
   these need an evolution-matrix row and a human reason;
2) changes in wording only - list for style review, no matrix row;
3) UNCHANGED statements where our catalog data (Lesson 2.1 YAML) says the
   implementation DID change - these are the dangerous ones: the narrative
   no longer matches the machine truth. Flag each with the YAML field that
   contradicts it.

Class 3 is the killer finding. A statement that still describes last year’s architecture, sitting beside catalog data that describes this year’s, is the package arguing with itself — Lesson 1.2’s version-drift failure, at the narrative layer.

The customer-responsibility split

Every statement in a cloud-inheriting world answers for a shared system, so strong statements declare three lanes explicitly:

INHERITED   the provider/platform implements it; we cite their package
            and IMPLEMENT NOTHING (but must not break their assumptions)
SHARED      split responsibility - the statement says which half is ours
            and where the seam is
CUSTOMER    entirely ours - and everything Meridian ships in this
            training's fiction lives here

The classic failure is silent inheritance: a statement that reads as if the provider’s encryption, logging, or physical security were the author’s own work. Assessors catch it instantly (they’ve read the provider’s package too), and it poisons trust in every neighboring claim. The split also generates a deliverable you’ll meet again in Lesson 3.3: the customer responsibility matrix — the document your downstream consumers need from you, listing what remains theirs. Commercial readers have written part of this before: the CUECs section of a SOC 2 report (complementary user-entity controls) is the customer-side half of the same idea, generalized here into a full three-lane allocation.

Traceability to code

The strongest pattern in the reference material, and the cheapest to adopt: implementation statements that cite the code implementing the claim — in the reference shop, down to file and line range. A compliance statement for an infrastructure module that says, per control, “implemented in standards.tf lines 41-58” turns assessment from archaeology into code review. Line ranges are the reference shop’s idiom and the most brittle rung of a ladder; the mainstream form is a stable-reference hierarchy: cite the evidence or test ID first, then the module / resource / policy ID, then the repository and commit, and only then an optional line range. CI then fails on a missing target or on evidence drift — never on a line number moving, because a moved line alone is not a security finding. Traceability that can’t rot is traceability that gets trusted.

Practice status — among mature regulated delivery programs, commercial and federal

(a few rows carry a more specific status - principle, canon, suspended - where one of the five would mislead)

Scale: required | common baseline | strong optional | reference-shop (seen only at organizations that publish their own practice) | emerging

Key takeaway

Statements stay human-authored — they’re the one asserted claim everything else is checked against — but the workflow is engineered: adapt from a predecessor with an evolution matrix (your assessor works differentially, same as you), declare the inherited/shared/customer split in every statement, and cite code by stable reference — evidence ID, module, commit, line range last — with CI failing on a missing target rather than a moved line. Use the AI CLI to find where narrative and catalog contradict each other — the finding that matters most. Next: the two machine-readable worlds your finished package must speak to.

LEADERSHIP DECISION   keep statements human-owned (the ISSO's signature means
                      something) and fund the assessor-facing apparatus:
                      evolution matrix, responsibility split, traceability
PRACTITIONER ACTION   adapt from the predecessor, build the evolution matrix,
                      split every statement into inherited / shared /
                      customer, cite code by stable reference
SUCCESS MEASURE       assessor hours spent only on the documented deltas; zero
                      silent-inheritance findings; every statement claim
                      resolves to a citable target