A readiness checklist tells you whether things exist. It does not tell you whether you can produce them when someone else chooses what to look at, a clock is running, and the answers come from the people who will give them in the real audit. That is a different test, and most teams first take it during fieldwork.
A mock audit moves that test earlier. Someone plays the auditor, issues requests, selects samples, runs walkthroughs, and writes down what they find. Done properly, it surfaces the problems a real auditor would find while you still have time to fix them.
This article covers what a mock audit is, who should run it, how to scope and conduct it, and how to turn what it finds into changes that hold.
What a mock audit is, and what it is not
A mock audit simulates fieldwork. It has a request list, populations, samples chosen by someone other than the control owners, walkthroughs, and written results. Its question is operational: did the controls run, and can you prove it?
It is not the same as a readiness assessment. A readiness assessment mostly examines design: whether your controls, as described, meet the criteria. A mock audit takes the design as given and tests operation and retrieval. You can run both, and the checklist in an audit readiness checklist is a good input to either.
The framework matters here:
ISO 27001 requires an internal audit under clause 9.2. A mock audit can serve as that internal audit if it meets the clause: a planned program, defined criteria and scope, auditors who are objective and impartial, results reported to management, and records kept. The details are in running the ISO 27001 internal audit.
SOC 2 has no requirement for one. It is optional, and it is most useful before your first Type II or after a period with significant change.
Who should play the auditor
The person running the mock audit needs two qualities. They must not have designed or operated the controls they test, and they must be willing to write down what they find, including findings that embarrass a colleague.
There are three usual options.
Someone from another team. Cheap, and they understand your systems. The risk is leniency: it is hard to write up a peer.
An outside advisor or consultant. More expensive, more experienced at sampling, and easier to accept criticism from.
Your audit firm's readiness service. Some firms offer readiness work and then perform the audit. Others keep the two apart for independence reasons. Practice varies, so ask your firm what it will and will not do before you plan around it.
In a small company, full independence may be out of reach. What matters is that nobody audits their own work. A security engineer can test the people operations controls; a people operations lead can follow a script to test change management.
Scoping the exercise
Do not try to test everything. A mock audit that covers every control in two weeks becomes a document review, and you lose the point of it.
Pick the controls most likely to fail under sampling:
Controls with large populations: production changes, access provisioning, onboarding and offboarding.
Any control whose process or system changed during the period.
Any control that failed or produced exceptions last time.
Controls whose owners are new to them.
Controls that depend on a manual step someone has to remember.
Time-box the exercise to one or two weeks. If you have your auditor's real request list, use it, so owners practice against the requests they will actually receive.
Running it
Run the mock audit the way a real one runs. The value comes from realism, so resist the urge to help.
Issue requests in writing, in the auditor's format, with deadlines. Route them through the coordinator who will handle the real audit.
Ask for populations first. The mock auditor should check that each list is complete before sampling from it.
Let the mock auditor select samples without input from owners or the coordinator. The methods auditors use are covered in how auditors sample controls.
Request full evidence for each sampled item, and record how long each one takes to produce.
Run walkthroughs with the real owners, who explain and demonstrate the process as described in what happens in an audit walkthrough.
Log every issue as it arises, tied to the request and sample it relates to.
Close with a meeting where the mock auditor presents findings and owners respond.
Classifying what you find
Not every issue means the same thing. Sorting findings by type tells you what kind of fix each needs.
| Finding | What it means | Typical response |
|---|---|---|
| Control did not operate | A sampled occurrence did not happen | Document it as a deviation, find the cause, fix the process |
| Operated, no evidence | The work was done but left no record | Change the process so the record is created as the work is done |
| Evidence exists, slow to find | The record is there, scattered or unlabeled | Agree where evidence lives and how it is named |
| Description does not match practice | The written control says one thing, people do another | Change the description or the practice, and date the change |
| Population incomplete | The list omitted items | Fix the query or source, then reconcile |
The second row is the most common and the most frustrating. The control is working, and you still cannot prove it. It is also the easiest to fix, because the fix is to the record rather than to the behavior.
Turning findings into fixes
Prioritize by what would appear in a report. A control that did not operate, or a population that turns out incomplete, is a potential exception. Slow retrieval is an efficiency problem. Fix the first group first.
Fix forward. If an occurrence did not happen, do not create the evidence after the fact. Record the deviation, its cause, and the date the process was corrected. A real auditor may find the same gap, and a documented account of it is far better than a reconstructed record.
When a description does not match practice, decide which one is right. Often the practice is better than the description, and the description should change. Record the date, because the auditor will test the old description for the part of the period before it.
Then retest. Pick a fresh sample of the fixed controls a few weeks later and check the fix held. A fix that has not been tested is a plan, not a result.
When to run it
For a SOC 2 Type II, a mock audit partway through the observation period gives you time to fix problems and still show the control operating afterward. A shorter pass a few weeks before fieldwork catches retrieval problems.
For ISO 27001, the internal audit has to be complete before the stage 2 audit, and certification bodies generally want to see that its findings are being addressed. Leave enough time between the two for that to be true.
How TrustLynce helps
If you want an outside view, TrustLynce's services include a dedicated advisor and audit readiness support. The auditor portal handles mock and real requests the same way, so owners practice in the place they will work during fieldwork.