/control-audit

name: control-audit
description: "Control-level audit readiness for SOC 2, ISO/IEC 27001:2022 and NIST SP 800-53 Rev. 5 / FedRAMP. Scope the audit (criteria or baseline, systems, period, Type 1 vs Type 2), build the control inventory, write an evidence request per control (artifact, owner, sample, test method), test what the repo and configs show (CC8.1 / A.8.32 / CM-3 change management via branch protection), hand technical checks to the owning skill, and record control gaps in the shared findings format with a control matrix. Use when the user mentions 'SOC 2,' 'SOC 2 Type 2,' 'Trust Services Criteria,' 'ISO 27001,' 'ISMS,' 'Statement of Applicability,' 'Annex A controls,' 'NIST 800-53,' 'FedRAMP,' 'FedRAMP 20x,' 'SSP,' 'POA&M,' 'control matrix,' 'evidence request list,' 'PBC list,' 'audit readiness,' 'control testing,' or is getting ready for an external auditor or assessor."
allowed-tools: Read, Grep, Glob, WebSearch

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.

| Decision | What to pin down | |---|---| | Framework and version | See the framework table below. Name the version in the report header | | Criteria or baseline | SOC 2: Security (the common criteria) is always in; add Availability, Confidentiality, Processing Integrity, Privacy only where customers or contracts need them. ISO 27001: all of clauses 4–10, plus the Annex A controls the Statement of Applicability includes. 800-53: the 800-53B baseline from the FIPS 199 categorization (Low / Moderate / High, plus privacy), tailored; FedRAMP: the Rev5 baseline or the 20x class being pursued | | System boundary | The service, its infrastructure, software, people, procedures and data. List every in-scope system by name | | Third parties | Subservice organizations (cloud host, IdP, payroll) and whether each is carved out or included; the complementary controls you rely on them for, and the ones your customers must run (CUECs) | | Audit period | SOC 2 Type 1: a single date (design only). Type 2: a period, commonly 3 to 12 months (design and operating effectiveness); a first Type 2 is often 3 to 6 months. ISO 27001: Stage 1 then Stage 2, with records showing the ISMS has run (an internal audit and a management revi