Audit readiness: how to be ready for any security or compliance audit

The auditor's request list lands on a Monday. It asks for the access reviews from the last two quarters, a list of every leaver this year and the evidence that each one lost access on time. Your team can find some of it and is rebuilding the rest from memory, while the customer waiting on the report asks when it will arrive. That is what a lack of audit readiness feels like.

This guide is for founders, heads of security and operations leads at UK B2B tech firms facing a first or repeat ISO 27001, SOC 2 or customer audit with a small team. It shows how to make audit readiness a standing state rather than a six-week scramble: owners, an evidence calendar, sample-ready populations, closed findings and a short mock audit.

What does audit readiness mean?

Audit readiness means you could hand an auditor the evidence for any in-scope control today. You get there by naming an owner for every control, collecting evidence on a fixed calendar, keeping populations ready for sampling, closing prior findings, and running a short mock audit first. It is a state you keep, not a project.

The test is simple. Pick any control in scope and ask for its evidence from three months ago. If someone can produce it in minutes, that control is ready. If it takes a meeting, it is not.

Audit readiness applies to any audit that tests controls against a defined set of criteria. That includes an ISO 27001 certification or surveillance audit run by a certification body, a SOC 2 examination, which the AICPA describes as one of a suite of services CPAs provide on a service organisation's system-level controls, and a customer's right-to-audit visit. The criteria change. The way you stay ready does not.

How is audit readiness different from a readiness assessment or a gap analysis?

A gap analysis and a readiness assessment are one-off exercises that measure how far you are from a standard. Audit readiness is the operating state those exercises point you towards. You run a gap analysis once, near the start; you stay audit ready every week, through owners, a calendar and evidence that keeps arriving without being chased.

The three terms are often used interchangeably, so it helps to pin them down:

• Gap analysis. Compares what you have with what a standard requires and lists the gaps. Our ISO 27001 gap analysis guide sets out the method for that standard.
• Readiness assessment. A later check, closer to the audit, that controls are designed and leave evidence an auditor can test. Our SOC 2 readiness assessment guide covers the SOC 2 version.
• Audit readiness. The day-to-day state in which evidence exists before anyone asks for it, whichever framework is next.

A firm can pass a gap analysis and still not be audit ready. The gap analysis says the controls exist. Audit readiness says they have left a record every time they ran.

How do you build audit readiness, step by step?

Build audit readiness in six steps: fix the scope and control list, name an owner for every control, set an evidence calendar, keep populations ready for sampling, close prior findings with proof, and run a short mock audit. Each step is small; together they turn the audit into a routine check of work already done.

Step 1: Fix the scope and the control list

Write down what the next audit covers: the services, locations, systems and teams in scope, and the controls that apply. For ISO 27001 that is your Statement of Applicability. For SOC 2 it is the set of controls mapped to the criteria in scope. For a customer audit it is the questionnaire or contract schedule the customer will test against.

One list matters more than three. If you face more than one audit, keep a single control list and note which audits rely on each control.

Step 2: Name an owner for every control

Every control on the list gets one named owner: a person, not a team. The owner runs the control, keeps its evidence and answers the auditor's questions about it. Where a control spans teams, such as joiners, movers and leavers, name the person who makes sure every step leaves a record.

A control everyone owns is a control nobody evidences.

Step 3: Set an evidence calendar

An evidence calendar lists each control, the evidence it produces, how often it runs and who owns it. Owners file the evidence when the control runs, not when the auditor asks. Store it in one place, named by control and date, so anyone can find last quarter's access review without asking its owner.

The example below shows the shape. The frequencies are our suggested starting points for a small firm, not requirements of ISO 27001, SOC 2 or any other framework. Set your own from your policies, your risk assessment and the criteria you are audited against.

Collecting this by hand works at small scale. As the control list grows, much of the calendar can be fed automatically from the systems that hold the records, which leaves owners to review rather than gather.

Step 4: Keep populations ready for sampling

Auditors rarely test every occurrence of a control; they draw a sample from the full population for the period. Readiness means you can produce that population quickly and completely, from a system of record, for any period the auditor names. The next section sets out how to prepare each one.

Step 5: Close prior findings with proof

Every finding from the last audit, internal or external, needs an owner, a fix and evidence that the fix worked. Auditors usually begin with what they found last time. An open finding with no update tells them nothing has changed. For ISO 27001, this is the corrective action process in Clause 10.2.

Step 6: Run a short mock audit

Before the real audit, test yourself as the auditor would: request populations, pick samples and ask owners for the evidence. The mock audit section below sets out how to run one in a few days.

What do auditors sample, and how do you prepare populations?

Auditors sample occurrences of a control from a complete population for the audit period: joiners, leavers, changes, incidents, access reviews or supplier assessments. They then ask for evidence for each sampled item. Prepare by knowing where each population lives, how to export it for any date range and how to show that the list is complete.

The population is where an audit can stall. If the leaver list comes from a spreadsheet someone maintains by hand, the auditor may ask how you know it is complete. If it comes from your HR system with a dated export, the question rarely arises.

For each population, prepare three things:

1. The source. The system of record for the population, such as the HR system for joiners and leavers or the ticketing system for changes.
2. The export. A repeatable way to produce the list for any date range, with the date and the person who ran it.
3. The link to evidence. For each item, where its evidence sits: the ticket, the approval, the log entry.

When the auditor picks 25 leavers, you should be able to send 25 tickets, not 25 apologies.

How do you run a mock audit?

Run a mock audit by choosing four to six high-risk controls, requesting the populations as an auditor would, picking samples yourself and asking owners for the evidence within a set time. Record every miss as a finding with an owner and a date. A mock audit takes days, not weeks, and shows where the real one would stall.

Keep the mock audit honest:

• Pick controls that fail quietly. Access reviews, leaver removals and change approvals are common choices, because they depend on people remembering to leave a record.
• Choose the samples yourself. If owners pick their own examples, they will pick the good ones.
• Time the response. Note how long each piece of evidence takes to produce. Anything that takes more than a day is a readiness gap, even if the evidence exists.
• Use someone who did not run the control. An internal auditor, a colleague from another team or an independent adviser will ask the questions an owner would skip.

If you hold ISO 27001, the internal audit required by Clause 9.2 can do this job, as long as it tests evidence rather than interviews.

How should you prepare for audit week?

Prepare for audit week by agreeing the request list and schedule in advance, setting up the auditor's access to evidence, naming one point of contact, and booking control owners' time for their interviews. Audit week should be a series of short, planned conversations about evidence that already exists, not a search for it.

The logistics that save the most time:

• Request list. Ask the auditor for the full request list before fieldwork, and map each item to an owner and a location.
• Access. Decide how the auditor will see evidence: a shared folder, screen-share sessions or read-only access. Remove anything out of scope.
• Point of contact. One person tracks every request, chases owners and logs what was sent and when.
• Owner availability. Block interview slots in owners' diaries and brief them on what the auditor will ask about their controls.
• Daily check-in. A short call at the end of each day to confirm open requests and early observations.

For an ISO 27001 certification, the certification process guide explains what each audit stage tests.

What happens after the audit?

After the audit, log every finding and observation with an owner and a deadline, agree the corrective action plan the auditor or customer expects, and feed the lessons back into the evidence calendar. The best time to fix a readiness gap is the week the audit exposes it, while the cause is still clear to everyone involved.

Three habits keep you ready for the next one:

1. Treat observations as early warnings. An observation or opportunity for improvement is not a failure, but it is often next year's finding.
2. Fix the process, not just the evidence. If a leaver ticket was missing, find out why the process allowed it, then change the process.
3. Update the calendar. Add any control, evidence type or frequency the audit showed you were missing.

What should an audit readiness checklist include?

Use this short audit readiness checklist to test where you stand today. Every "no" is a readiness gap, and each gap maps to one of the six steps above. We suggest working through it quarterly, and again a month before any audit, so that nothing on the list is a surprise to the auditor or to you.

• The scope and control list for the next audit are written down and current.
• Every control has one named owner.
• An evidence calendar exists, and evidence is filed when the control runs.
• Each population can be exported for any date range from a system of record.
• Every prior finding has an owner, a fix and evidence that the fix worked.
• A mock audit has been run in the last six months.
• The request list, access route and point of contact for audit week are agreed.

For Cyber Essentials, readiness also means being able to show the five technical controls working. The NCSC describes Cyber Essentials as a combination of self-assessment and independent audit, and Cyber Essentials Plus as adding independent technical testing of your systems. Our Cyber Essentials overview covers the scheme.

What are the most common audit readiness mistakes?

The most common audit readiness mistakes are preparing only in the weeks before the audit, treating policies as evidence, letting control ownership sit with teams rather than people, and leaving populations to be rebuilt by hand. Each one turns a routine check into a scramble, and each one is cheaper to fix months before the auditor arrives.

1. The six-week sprint. Evidence created just before an audit covers a moment, not a period. Auditors testing a period will notice.
2. Policies as proof. A policy shows what should happen. Only records show what did.
3. Team ownership. "IT owns it" means nobody does. One person per control.
4. Hand-built populations. If a list cannot be shown to be complete, every sample drawn from it is in doubt.
5. Open findings. Last year's finding, still open, is the first thing the auditor will see.

A policy nobody follows is a finding waiting for a date.

Fix these and the audit becomes what it should be: an independent check of work you were already doing.

Frequently asked questions