Stop 3 of 10 · Weekly
Compliance mapping
The published control catalogue on one side, the design on the other, and a control-by-control table where every row states who implements it and which document says so.
The question every agency asks in the same week
Calverton County wants StateRAMP alignment for the records platform and CJIS for anything the sheriff's office touches. Rio Seco Unified wants to know what happens to student data. Every one of Fadi's accounts asks the same two questions two weeks before a board meeting: does this meet our frame, and what do we still have to do ourselves.
Answering by hand means holding a control catalogue and a design in your head at the same time, control by control, for several hundred controls. That is a reading job at a scale humans do badly and Claude does well, with one condition: it reads the catalogue you give it, not the one it remembers.
What goes in
The published control document at the assessed version. The architecture document and decision log from stop two. The vendor's own published responsibility documentation for the services in the design. Nothing else, and in particular nothing from the customer's environment: no configuration exports, no scan output, no audit findings. This mapping describes a proposed design, not a running system.
The three columns that make a row usable
| Column | What has to be in it |
|---|---|
| Implementation | The specific service feature or design element that satisfies the control |
| Responsibility | Platform inherited, customer implemented, or shared with the split named |
| Evidence | The document and section a reviewer opens to check the claim |
Attached: the CJIS Security Policy at the version Meridian County is assessed against, and my architecture document for their records workload. I am the cloud architect on the account. Build a control-by-control table covering every control in the attached policy that the design touches. Columns: control identifier, control requirement in your own words, how the design implements it, whether responsibility is platform inherited, customer implemented or shared, and the evidence a reviewer would open. Where responsibility is shared, write both halves as separate sentences. Where you cannot name evidence from the attached documents, write GAP in the evidence column rather than describing what evidence would probably exist. Do not mark a control compliant because it is usually satisfied by this kind of design.
From the Meridian County mapping, give me every row marked GAP as a work list. For each one: the control, what has to exist for it to close, who plausibly owns it between the county, the integrator and us, roughly how much work it is, and whether it blocks go-live or can follow. Separate the gaps that are genuinely open from the gaps that only exist because the attached documents do not cover that area. Those two need different conversations.
The second list is the one architects forget. Half of what looks like non-compliance is an information gap in your own inputs, and taking that to the county as a finding wastes their afternoon and your credibility.
Go back through the Meridian County mapping and verify every control identifier and every quoted requirement against the attached policy document only. List any identifier that does not appear in the document, any quotation that differs from the text, and any control you described from general knowledge rather than from the file. Do not correct them, just list them.