Control Audit — Audit Readiness for Control Frameworks

Get a control set ready for an external auditor: decide what's in scope, list the controls, write the evidence request an auditor would send for each one, test what you can from the repo and exported configs, and record what's missing or failing. The result is a control matrix, an evidence-request list, and a findings.json of control gaps that rates each gap by the exposure it leaves, not by how an auditor might word the opinion.

This is the program-level layer. It doesn't re-run technical audits: when a control's evidence is a technical check (branch protection, MFA enforcement, encryption at rest), it hands the check to the skill that owns it and folds the result back in.

Cross-references: csf-mapping (crosswalk a control set to NIST CSF 2.0, and governance-level gap analysis), pci-audit and hipaa-audit (code-facing audits when the in-scope data is cardholder data or PHI), iam-audit (access reviews, MFA, joiner/mover/leaver evidence), cloud-audit (logging, encryption, network and backup settings), secrets-audit, dependency-audit and container-audit (vulnerability management evidence), siem-detection (monitoring and alerting evidence), incident-triage (incident response plan and test evidence), privacy-engineering (SOC 2 Privacy category), finding-triage (dispositions after the audit), security-comms (readiness updates for executives and the board).

When to use

• "We have a SOC 2 Type 2 in six months, where are we?" or "the auditor sent a PBC list, help us answer it"
• Building or reviewing a control matrix, and writing evidence requests per control
• "Our ISO 27001 Stage 2 is in May" or "is our Statement of Applicability defensible?"
• Writing or reviewing an SSP and POA&M against an 800-53 baseline, or getting ready for FedRAMP (Rev5 or 20x)
• Readiness review before fieldwork: which controls lack evidence, which failed in the period, which are only on paper
• Re-running after remediation, matched by fingerprint

Input: the framework and criteria in scope, the system description or boundary, the audit period, and whatever evidence the user can share (policies, ticket exports, config exports, the repo).

Not for: NIST CSF 2.0 tiers, profiles or a board roadmap → csf-mapping. Card-data code and scope review → pci-audit. PHI flows and Security Rule safeguards in code → hipaa-audit. AI governance against the NIST AI RMF → ai-risk-management. GDPR / CCPA implementation → privacy-engineering. Triage of one scanner finding → finding-triage. The technical checks themselves → the skill named in the handoff table below.

Authorization

• Work only on the user's own organization, or a client that engaged them for readiness work. If whose controls these are is unclear, ask.
• Fine by default: reading the repo and the evidence the user shares, and writing the audit folder (scope.md, control-matrix.md, evidence-requests.md, findings.json, evidence/).
• Needs a yes first: any query against a live system, even read-only (gh api for branch protection, an IdP or cloud CLI listing). Use the user's own credentials and read-only calls only. Never change a setting during the audit; a fix made mid-period is recorded as remediation with its date.
• Evidence often holds personal data (HR rosters, access lists, background-check status). Record user IDs or counts, not names, and never copy credential values, customer data or full HR records into evidence, findings or the report.
• Refuse to fabricate or backdate evidence, write a system description that claims controls that don't operate, or shape samples to hide exceptions from the auditor.

Step 1 — Scope the audit

Write scope.md before anything else. Most readiness work that goes wrong went wrong here.

Frameworks this skill carries a reference for:

For a crosswalk between frameworks, or to NIST CSF 2.0, map each control here to its CSF subcategory with csf-mapping and keep the mapping in a csf column of the control matrix. One control, evidenced once, can satisfy several frameworks; say which.

Step 2 — Build the control inventory

One row per control the organization operates, not per criterion. A criterion is usually met by several controls, and one control often serves several criteria.

A criterion with no mapped control is a design gap. Record it in Step 5.

Write each control as something a tester can check. "We follow least privilege" can't be tested; "Quarterly, the system owner reviews production database access against the HR roster and removes leavers within 2 business days" can.

Step 3 — Write the evidence requests

For each control, write the request the auditor will send, before they send it. Put them in evidence-requests.md, one row per request.

Test methods, weakest to strongest. Inquiry alone never evidences a control; pair it with at least one of the others.

Sample sizes for Type 2. Typical auditor practice (firms differ; ask yours):

The SOC 2 reference lists the usual artifacts per criterion.

Step 4 — Test from the repo and configs, hand off the rest

Test read-only, and only what the repo or a saved export actually shows. Everything you test becomes evidence under <audit dir>/evidence/, saved redacted and pretty-printed so line numbers stay put, with the command and time in the record's description.

What the repo can usually evidence directly:

Hand the technical depth to the owning skill and fold its verdict back into the control row. Don't redo its work here.

A handed-off finding keeps its own fingerprint and skill. In the control matrix, cite its fingerprint against the control it affects instead of writing a second record for the same root cause.

What the repo can't show (HR records, training completion, vendor reviews, board minutes, the access review itself) goes in the evidence-request list for the owner.

Step 5 — Verify, then record

Close every candidate gap with one verdict, as defined in references/findings-format.md, and run the refutation pass in references/verification.md before anything is confirmed.

A control that's missing or failing is a finding; the control is the intended control. Rate severity by the exposure the gap leaves, using references/severity-calibration.md, not by audit-opinion risk. "This would be a qualified opinion" is not a severity. A leaver with live production database access 40 days after termination is High because of what that access reaches. A quarterly review that ran 10 days late, with nothing wrong found when it did run, is not an exposure.

Documentation gaps are not findings. A policy that's missing, unsigned or a year past review, an overdue training record, a vendor review not filed, a control description that doesn't match practice: list them in the report's "Documentation gaps (not findings)" section with the criterion, owner and the evidence expected. No severity, no findings.json record. They still matter to the auditor, and the report says so. Defense-in-depth gaps where another control already covers the exposure are hardening notes.

Design gaps vs operating exceptions: a control that doesn't exist (design) and a control that exists but failed in a sample (operating) are both findings if they leave an exposure. Put which one in ext.gap_type.

What each verdict looks like here:

• confirmed: evidence you read shows the control missing or failing, and what that exposes.
  • Change management (CC8.1): the saved branch protection export for main on the production repo shows no required reviews and enforce_admins: false, and the deploy workflow ships every push to main to production. Trace: push access (entrypoint) → unprotected main (propagation) → production deploy job (sink), all pointing at the evidence file and the workflow file. Medium or High depending on who holds push access and what production holds.
  • Logical access (CC6.2): the IdP export and the HR termination list (both saved, redacted to IDs) show 3 accounts active 30+ days after termination, one with production admin. Reperformance is the test; record test_method: reperformance.
• needs_validation: the evidence that decides it lives with a person or a system you can't read. The blocker is that fact, and the validation plan is the evidence request.
  • Access review (CC6.3): the policy says quarterly reviews, and the ticket export has Q1 and Q2 but nothing for Q3. Blocker: whether the Q3 review was done outside the ticketing system. Plan: request ER-IAM-03-1, the Q3 review record with reviewer, date and the removals it led to; if none exists, it becomes confirmed (operating exception), rated by what unreviewed access reaches.
  • Backups (A1.2): IaC enables snapshots, but restore testing happens in a runbook the team runs by hand. Blocker: whether a restore was tested in the period. Plan: request the last restore-test record and its date.
• rejected: evidence shows the control designed and operating, so the gap claim is ruled out. ruled_out_by.location points at that evidence.
  • "No MFA on the admin console": the IdP sign-on policy export (saved) requires phishing-resistant MFA for the admin group, and the authentication log sample shows MFA on every admin sign-in in the period.
  • "Production deploys bypass review": the branch protection export requires one approval with enforce_admins: true, and a sample of 25 merged PRs from the period all show an approver other than the author.

Location. Every record needs a location. Point it at the strongest artifact you read: the repo file, or the saved evidence file and the line of the decisive field. When nothing is readable yet (a needs_validation that waits on a person), point it at that request's line in <audit dir>/evidence-requests.md.

Fingerprints are control-audit/<framework>/<control id>/<system or scope>, slash-separated, lowercase framework slug, no line numbers. Use the framework's own ID for the control; write enhancement or sub-item parentheses with a dot (AC-2(1) → AC-2.1), since parentheses aren't allowed in fingerprints. Name the system or scope so the same control on two systems gets two records:

control-audit/soc2/CC6.2/okta-workforce
control-audit/soc2/CC8.1/github/acme/api
control-audit/soc2/A1.2/aws/123456789012/prod-db
control-audit/iso27001/A.5.18/okta-workforce
control-audit/fedramp/SC-28.1/aws/123456789012/prod-db

Framework slugs: soc2, iso27001, nist80053, fedramp.

ext fields (flat, snake_case; don't repeat anything that already has a field):

Then:

1. Write findings.json sorted by fingerprint, with skill: "control-audit". Validate it and fix every error: node references/validate-findings.mjs findings.json (references/validate-findings.mjs). Optionally export SARIF: node references/to-sarif.mjs findings.json -o findings.sarif (references/to-sarif.mjs).
2. Keep documentation gaps and hardening notes in notes.md next to the JSON. They are not records.
3. On a re-run, load the previous findings.json and match by fingerprint. A rejected record stays rejected unless the evidence behind it is from an earlier period; a new period means new samples.

Dispositions (set later, usually by finding-triage): Fixed / Deferred / Accepted Risk / Mitigated (platform/config) / Requires major migration. For an audit, "Fixed" needs the date: a fix late in a Type 2 period still leaves the exception in the period.

Output Format

Write findings.json first. Render the report from it; the prose never changes a verdict, severity or blocker the JSON doesn't already say.

# [Framework] Audit Readiness Review
## Organization: [name]   ## System: [name / boundary]   ## Framework: [name + version]
## Criteria or baseline: [e.g. Security + Availability]   ## Report type: [Type 1 as of date | Type 2, period start–end]
## Date: [date]   ## Reviewer: [name]   ## Scope: [full | partial, what was left out]
## findings.json: [path], validated: [yes]   ## Evidence folder: [path]

### Summary
- Controls in scope: [N]   Evidenced: [n]   Gaps (findings): [n]   Awaiting evidence: [n]   Documentation gaps: [n]
- Confirmed: [N] (Critical [n] | High [n] | Medium [n] | Low [n])   Needs validation: [N]   Rejected: [N]
- Readiness call: [ready for fieldwork | ready after the items below | not ready], one line on why

### Control matrix
| Org control | Framework refs | Owner | Frequency | Test method | Evidence request | Status | Record / note | CSF |
|---|---|---|---|---|---|---|---|---|
| CHG-02 | CC8.1 | Eng manager | Per PR | Inspection, 25 samples | ER-CHG-02-1 | Gap | `control-audit/soc2/CC8.1/github/acme/api` | PR.PS-01 |

Status: Evidenced / Gap / Awaiting evidence / Documentation gap / Not applicable (with reason).

### Evidence-request list
| Request | Control | Artifact | From | Population and period | Sample | Test method | Pass condition | Status |
|---|---|---|---|---|---|---|---|---|

### Confirmed findings
#### [SEVERITY] [Title]  `fingerprint`
**Control:** [ext.control_id] / [ext.org_control_id]   **Gap type:** [design | operating]   **Sample:** [ext.sample]
**Location:** `path:line` (repo or evidence file)   **Confidence:** [medium | high (reproduced)]   **Test:** [ext.test_method]
**What and why it matters:** [the evidence and the exposure it leaves]
**Fix:** [concrete change, and the evidence that will show it operating]
**Verify the fix:** [the test the auditor will run]

### Needs validation
| Finding | Control | Blocker | Evidence request (validation plan) |
|---|---|---|---|

### Documentation gaps (not findings)
| Criterion | What's missing | Owner | Evidence expected | Due before |
|---|---|---|---|---|

### Hardening notes (not findings)
- [gap] — [why it isn't a finding] — [effort]

### Rejected (do not re-raise)
| Fingerprint | Ruled out by | Location |
|---|---|---|

### Handed off
| Control | Skill | Record or status |
|---|---|---|

### Third parties and complementary controls
| Subservice org | Carve-out / inclusive | Their report on file (type, period) | Complementary controls we run |
|---|---|---|---|

### Prioritized remediation plan
1. [highest exposure first; then anything that must operate for the whole period, since it has to start now]

The control matrix counts records from findings.json and entries from the documentation-gap list. It is not a separate judgement.

Boundaries

• This is readiness, not an audit opinion or a certificate. A SOC 2 report is issued by an independent CPA firm, an ISO/IEC 27001 certificate by an accredited certification body, and a FedRAMP assessment by a recognized independent assessor (3PAO), with the ATO decided by the agency. The readiness review prepares for those and does not replace them
• Severity is not a POA&M risk rating either; keep the assessor's rating in the POA&M and ext.poam_id
• Severity is not a nonconformity grade. A major nonconformity for a missing management review is still a documentation gap here, and the report says it will block certification
• Severity reflects exposure. Don't inflate a paperwork gap to High to get budget, and don't call a live exposure a documentation gap because the auditor might not sample it
• Never fabricate, backdate or edit evidence, and never pick samples to avoid known exceptions. The auditor picks samples. If evidence doesn't exist, the row says so
• Technical findings belong to the skill that found them. Cite their fingerprints here; don't duplicate records
• An active exposure found during readiness (live credentials, a leaver with production access) goes to the owner now, not into the report next month. Use incident-triage if it looks used
• Policy and legal sign-off (management's assertion, the system description) stays with management and counsel

References

• AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with Revised Points of Focus, 2022) — aicpa-cima.com
• AICPA, SOC 2 Reporting on an Examination of Controls at a Service Organization (Guide, 2022 edition)
• COSO, Internal Control — Integrated Framework (2013): the 17 principles behind CC1–CC5
• ISO/IEC 27001:2022 and Amendment 1:2024, ISO/IEC 27002:2022 — iso.org (copyrighted; the reference file paraphrases control titles)
• NIST SP 800-53 Rev. 5 (Release 5.2.0), SP 800-53A, SP 800-53B, and OSCAL — csrc.nist.gov, pages.nist.gov/OSCAL
• FedRAMP Consolidated Rules for 2026, Rev5 baselines and FedRAMP 20x Key Security Indicators — fedramp.gov
• Framework detail: references/soc2.md, references/iso27001.md, references/nist-800-53.md
• Shared references (copied into references/ at build time): references/findings-format.md, references/verification.md, references/severity-calibration.md, references/findings.schema.json