How to Prepare for a Security Audit

• Start from the evidence the auditor will ask for and work backwards. Starting from the controls produces documentation nobody asked for.
• The two failure points are scope creep and the observation window - a SOC 2 Type II needs your controls to have been RUNNING for months.
• A gap assessment before the audit is cheaper than a finding during it, by a wide margin.
• Do the work first and document it second. The reverse order is how audits become expensive.

Preparing for a security audit means assembling evidence that your controls existed and operated, over a defined period, in a form a third party can verify. Most of the effort is not in fixing security - it is in proving what was already true. Teams that understand that finish early; teams that treat it as a security project finish late and over budget.

What follows is ordered by when you should do it, not by how it appears in a framework.

Work backwards from the evidence request

Every auditor sends an evidence request list. Get it, or a sample one, before you plan anything. It is the actual specification, and it is far more concrete than the framework text.

The instinct is the opposite: read the standard, interpret the controls, write policies, then hope the evidence follows. That produces a lot of documentation nobody asked for and gaps in the things they did.

The evidence auditors actually ask for

This is the security audit checklist that matters, in the sense that these are the artefacts you will be asked to produce. The wording differs by framework; the substance rarely does.

• Access control. A current user list per system, evidence of periodic access reviews, and proof that leavers were removed - with dates.
• Onboarding and offboarding records. Tickets or logs showing access granted and revoked, matched against HR dates.
• Change management. Pull requests with reviews, deployment records, and evidence that changes were approved by someone other than the author.
• Vulnerability management. Scan output over time, a remediation record with dates, and your prioritisation rationale.
• Penetration test report. Recent, scoped to the systems in the audit, with the retest that confirms fixes landed.
• Risk assessment. A register with owners, ratings, treatment decisions and review dates.
• Incident response. The plan, evidence of a test or a real incident handled, and the post-incident record.
• Vendor management. A list of third parties with data access, plus their own reports or certificates.
• Training. Completion records with dates, not a slide deck.
• Monitoring and logging. Evidence that logs exist, are retained for the required period, and that someone reviews alerts.
• Backups. Configuration, plus evidence of a restore having been TESTED.

The order of work

1. Pick the framework and the scope. Which systems, which environments, which entity. Write it down and get it agreed, because everything downstream is priced against it.
2. Get the evidence request list. From your chosen auditor or a readiness partner.
3. Run a gap assessment. Walk the list and mark each item as have-it, partial, or missing. This is the single highest-value step and it is routinely skipped.
4. Close the gaps. Do the actual work. Enforce the access reviews, run the pentest, test the restore.
5. Let the observation window run. For anything attesting to operating effectiveness, controls must have been running for a period - typically several months. This is why starting late cannot be bought out with budget.
6. Collect and organise the evidence. Named, dated, mapped to the control it supports.
7. Then the audit. Fieldwork, questions, follow-ups, report.

Where preparation actually fails

Scope creep. A scope agreed loosely in an early call expands as the auditor asks questions. Every added system is more evidence, more remediation and more time. Write the scope down and treat changes as changes.

The observation window. The most common expensive surprise. If your controls only started operating a month before fieldwork, an attestation covering operating effectiveness has almost nothing to observe. No amount of urgency compresses elapsed time.

The teams that finish audits cheaply are the ones that did the security work months earlier for its own reasons, and then spent the audit period collecting evidence of it. Documentation-first is the expensive order.

Where a penetration test fits

Nearly every framework wants some form of technical testing, and they differ sharply in how prescriptive they are - PCI DSS requires it outright, others treat it as expected evidence, and a couple name human-led exercises specifically. We map that position framework by framework rather than giving one answer.

Two practical points. First, the test must cover the systems in your audit scope; a report for a different application is not evidence. Second, budget for the retest - a report full of open findings raises more questions than it settles.

If you want the specifics for the framework you are pursuing, the leaf pages answer them directly: does SOC 2 require a penetration test, does ISO 27001 require one, what PCI DSS Requirement 11.4 actually says, and for data-protection regimes, whether GDPR Article 32 requires testing and what the HIPAA Security Rule expects.