Understand what is being tested

Most audits assess whether controls exist, are documented, and are demonstrably operating. That last part surprises people: a control you genuinely perform but never record is, from an auditor's position, indistinguishable from one you do not perform.

So preparation is partly about security and substantially about evidence.

Start with access

Access control is where audits most commonly find problems, and it is also where real breaches most commonly begin. The two overlap more here than anywhere else, which makes it the highest-value place to start.

  • A current list of every system and who can reach it
  • Multi-factor authentication on everything that matters, including admin consoles
  • Offboarding that provably removes access, with a record of when
  • Periodic access reviews, signed off and dated
  • Shared accounts eliminated, or documented with a compensating control

Write policies you actually follow

A borrowed policy set describing practices you do not perform is worse than a short, honest one. Auditors test policy against reality, and a gap between them is a finding in itself.

Write what you genuinely do, then improve the practice and update the document. Short and true beats comprehensive and aspirational.

Collect evidence continuously

Assembling a year of evidence in the fortnight before an audit is miserable and usually incomplete. Automate what you can — access logs, change approvals, deployment records, scan results — so evidence accumulates as a by-product of working.

Where a control is genuinely manual, put a recurring calendar entry against it and record the outcome each time.

Fix the technical basics

Dependency scanning in the pipeline, encryption in transit and at rest, secrets in a manager rather than in configuration files, logging that captures who did what, and a tested restore. None of this is exotic and all of it comes up.

Run an internal review against the standard first. Finding your own gaps is considerably cheaper than an auditor finding them.

Do not optimise for the certificate

It is entirely possible to pass an audit and remain insecure, by treating each control as a document to produce rather than a practice to adopt. Organisations that do this get the certificate and the breach.

Use the framework as a checklist for things worth doing anyway. The certificate is then a by-product rather than the objective.

Written by the Global IT Solutions engineering team. Working through this decision right now?

Start a conversation