Checklist

Audit-readiness checklist

The Framework > Control > Requirement > Test > Evidence graph is what an auditor actually reviews. Work through this before kickoff so nothing surfaces as a surprise.

Scope the audit

Pick the framework and, if applicable, the Trust Services Criteria or Annex A controls in scope.
Define the system boundary — which products, environments, and data are covered.
Confirm the audit period (Type I point-in-time, or Type II over a window) with your auditor.

Map controls to requirements

Make sure every in-scope control has at least one mapped requirement.
Check for requirements with no test attached — those are gaps, not evidence.
Where one requirement satisfies multiple frameworks, confirm the cross-mapping is actually linked, not just similar in wording.

Confirm tests are actually running

Review test results for the audit window, not just the most recent run — Type II needs a history.
Investigate any failing or stale (long-since-run) tests before the auditor does.
Confirm manual tests have a recorded owner and a completed attestation, not just a placeholder.

Check the evidence itself

Every passing test should have evidence attached — a timestamp, a source system, and (where applicable) a content hash.
Spot-check a sample of evidence the way an auditor would: does it actually show what the control claims?
Confirm evidence freshness matches your monitoring cadence — a config screenshot from six months ago won't hold up for a control reviewed quarterly.

Assign and confirm control owners

Every control should have a single named, current owner — not a departed employee or a shared inbox.
Owners should be able to explain their control and produce evidence on request, not just have their name on it.

Package the auditor handoff

Export the control list, mapped requirements, test results, and evidence in the structure your auditor expects.
Note any known gaps or exceptions up front — surprises found by the auditor are worse than ones you disclosed.
Confirm access for the auditor (or the evidence package) is ready before the engagement start date.

This is how compliance automation keeps that graph current between audits, not just before one.

See compliance automation Back to resources

Check the evidence itself

Every passing test should have evidence attached — a timestamp, a source system, and (where applicable) a content hash.

Spot-check a sample of evidence the way an auditor would: does it actually show what the control claims?

Confirm evidence freshness matches your monitoring cadence — a config screenshot from six months ago won't hold up for a control reviewed quarterly.

Package the auditor handoff

Export the control list, mapped requirements, test results, and evidence in the structure your auditor expects.

Note any known gaps or exceptions up front — surprises found by the auditor are worse than ones you disclosed.

Confirm access for the auditor (or the evidence package) is ready before the engagement start date.