Safeguard
Compliance•

How to run a SOC 2 mock audit before the real one

A step by step plan for a SOC 2 dry run: pick a reviewer, sample like an auditor, log the gaps and fix them before the real examination starts.

Safeguard Security Team
3 min read

A mock audit is a rehearsal where someone who did not build the controls tests them the way an auditor will. Pick a reviewer, write a request list from your control matrix, sample real evidence, record gaps and fix them before the examination period or the fieldwork starts.

Choose who plays auditor

The best reviewer knows the criteria but did not set up the controls. That might be a colleague from another team, an outside advisor or a part time compliance lead. Be aware of independence rules if the same firm will later be your auditor. Ask that firm how it handles readiness work.

Build the request list from your controls

Take your control matrix and write one request per control, with the period and population. For a Type 2 rehearsal, choose a past window of at least a few weeks so there is something to sample.

Sample the way an auditor would

Do not hand over the best example. Ask for a population, such as every production change in the last quarter, and have the reviewer pick the items. Then ask for the approval, the test result and the deployment record for each.

Typical populations to test:

  • New hires and their background checks, training and access.
  • Terminated users and the time to remove access.
  • Production changes and their reviews.
  • Vulnerabilities and their remediation dates.
  • Incidents and their follow up.

Record findings in the audit format

For each gap, write the control, what was expected, what was found, the cause and the fix. Use the same structure you would use for a real exception. It builds a habit and makes the final audit less surprising.

Fix, then retest the fix

Some gaps are paper problems, such as a missing approval record. Others are real, such as a leaver who kept access for weeks. Fix the process, then run the sample again on newer data to show the change works.

Timebox it

A mock audit that drags on becomes a project of its own. Give it a couple of weeks and a clear end date.

What a good mock audit report looks like

Keep it to a few pages. List each control tested, the sample size, the result and the gaps, grouped by severity. Add a short list of quick wins that can be fixed in a week and a longer list of structural fixes. Give each item an owner and date.

Share the report with leadership. It makes the case for fixes that need budget or time from other teams, such as automating offboarding.

Avoid these traps

Do not coach the control owners on what to say. The point is to see how things really work. Do not fix evidence quietly before the reviewer sees it. And do not treat a clean mock audit as proof of a clean real one. Auditors may sample differently, and your environment changes.

Quick check

How many controls should the mock cover?

All of them at a light level, and the riskiest ones in depth. Access, change management and monitoring usually deserve the most attention.

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.