Audits and Evidence · 25 min read
How to Prepare for a Compliance Audit: A Guide for Small and Growing Businesses
To prepare for a compliance audit, settle the scope in writing, list what the auditor is likely to sample, gather the policy, approval and acknowledgment records behind each item, test yourself with a mock audit, and brief the people who will be interviewed. The companies that find audits painful are rarely the ones with the weakest compliance, they are the ones whose evidence is scattered, so most of the work is making the proof easy to find.
I have been through ISO 9001 audits more than ten times, ISO 27001 twice, and SOC 2 and HIPAA audits as well, and I have seen the same pattern in every one of them: the auditor asks for a record, and the time it takes to produce decides how the rest of the day goes. This guide is written for the operations, HR or quality lead at a company of roughly 20 to 200 people who has been handed an audit and has no compliance team, and it follows the order you would work in, from what auditors do, through a 90-day plan and a two-week emergency plan, to what to do when they find something.
Key takeaways
- An auditor tests a sample, so what matters is whether you can prove the rule for the one record they pick, not whether you can prove it for everything.
- The evidence an auditor asks for is mostly about policies and procedures: that they exist, who approved them, which version is in force, who read them, and when they were last reviewed.
- A mock audit, where you pull ten records and time how long each takes to find, tells you more in a day than a month of reading the standard.
- Findings are normal and are graded; what matters is a corrective action plan that fixes the cause, which most small companies write too narrowly.
What a compliance audit is, and who is auditing you
A compliance audit is an independent check of whether your organization is doing what it has said it will do, measured against a set of criteria such as a law, a standard, a customer’s requirements or your own policies. The word “independent” carries the weight, because a check is only worth something to the person relying on it if the checker has no stake in the answer, and that is why the same company can be audited by its own staff, by a customer and by an outside body for the same policy and get three different experiences.
It helps to know which of the four kinds of audit you are facing, because they feel similar but differ in what is at stake and in how much you can negotiate.
| Audit | Who asks | Why | What is at stake |
|---|---|---|---|
| First party (internal) | Your own staff or a consultant you hire | To find gaps before anyone else does | Nothing external, which makes it the cheapest place to learn |
| Second party | A customer, or a buyer reviewing a supplier | To decide whether to start or keep a contract | The account, and sometimes the whole relationship |
| Third party (external) | A certification body, accreditor or an independent assessor such as a CPA firm | To award or renew a certificate, accreditation or report | The certificate, which customers may require |
| Regulator | A government agency | To check the law rather than a voluntary standard | Fines, orders and, in some sectors, the license to operate |
A third-party audit, the kind a certification body or an independent assessor performs, is the one most guides mean when they say “external audit”, and it is also the one with the most predictable shape: it has a plan, a schedule, an opening meeting, sampling, a closing meeting and a report. A second-party audit by a customer is usually less formal and more unpredictable, because the customer sets the agenda, and our guide to security questionnaires covers the questionnaire that so often comes first. A regulator’s audit is the one where the law, rather than a standard you chose, sets the requirements.
Whichever you face, the work underneath is the same: you need written rules, you need to show they were followed, and you need to show that someone checks. Companies that build for that rather than for a particular auditor find that each new audit costs them less than the one before.
What auditors actually do
An auditor cannot check everything, so every audit works by sampling. They read the criteria, choose a sample of people, records or processes, ask for the evidence that each item meets the criteria, interview the people involved to see whether practice matches paper, and write down whatever doesn’t match as a finding. That cycle repeats for each area in the audit plan, and a day on site is usually many small repetitions of it.
Sampling is why preparing for the audit by checking everything is a poor use of a month. What helps is knowing which items an auditor tends to choose, because they choose with a purpose: recent joiners, recent changes, records near the end of the period, and anything connected to something that went wrong, since those are the places where a system is most likely to slip.
I learned this the hard way in an audit where the sample came from the people who had joined most recently. The auditor chose an employee who had not signed the NDA yet, not because we had ignored the requirement but because they had joined while the NDA was being rewritten, and the new version wasn’t ready to send. The rule was written, the old copies were signed and the new one was nearly done, but the one record the auditor asked for did not exist. Nothing in that situation was careless, it was a gap between a policy changing and everyone being covered by the new one, which is exactly the kind of gap a sample is built to find.
That story is the reason this guide spends so much time on policies and records rather than on technology. The most common findings at small companies come from the space between a rule changing and the evidence catching up with it: a policy rewritten but not sent, a review that came due and slid, a joiner who started the week the new version was published.
Sources: ISO 19011:2018, Guidelines for auditing management systems, on audit sampling and evidence, ISO/IEC 17021-1:2015, requirements for bodies providing audit and certification of management systems
Fix the scope and the criteria first
Before anything else, find out exactly what is being audited and against what. The scope names the sites, processes, systems and period the audit covers, and the criteria name the standard, law or customer requirement the auditor will measure you against, and getting both in writing early saves you from preparing for the wrong audit.
Ask the auditor for four things as soon as the date is set: the audit plan, which says what will be covered on which day and who they want to talk to; the list of documents and records they expect to see, often called the request list; any findings from the previous audit that they will follow up; and the name of whoever will lead the audit on their side. A professional auditor will usually share all four, and a customer auditor often will if you ask, and the request list in particular turns an open-ended worry into a list of things you can go and find.
Then decide who on your side owns the audit. One person should be the audit liaison, the single point through which requests and evidence flow, because an audit with five people answering the auditor’s emails is an audit where answers contradict each other. At a company of 50 people that is usually the operations or HR lead, and the job is mostly coordination: logging each request, finding the owner of each answer and making sure what goes back is the current approved version.
The evidence auditors ask for
Most compliance audits, whatever the standard, come down to the same short set of questions about your policies and procedures, because the policy is the written rule and the records around it show whether the rule is real. If you can answer the questions in the table below for each policy in scope, you have most of what an auditor will ask for in most audits.
| What the auditor asks | The evidence that answers it | Where a small company usually loses it |
|---|---|---|
| Do you have a policy for this? | The current approved policy, with its title, owner and effective date | Three versions in three folders, and nobody sure which is current |
| Who approved it, and when? | The approval record for that version, naming the approver and the date | An email reply buried in someone’s inbox |
| Is this the version in force? | Version history showing which version replaced which, and when | Overwritten files with no history |
| Did people read it? | A record per person: name, version, date and time of acknowledgment | A shared spreadsheet filled in by hand, or a read receipt that proves only that a message was opened |
| Was it reviewed on schedule? | A review date and the record of the review or re-approval | A calendar reminder that nobody acted on |
| What changed since last time? | A comparison of the two versions and the reason for the change | Memory, which is not evidence |
| Who had access to it? | The rule that decided the audience, and the list of people it covered | A distribution list that was never updated for joiners and leavers |
| What happens when someone breaks it? | An exception or incident record showing the decision and the follow-up | A hallway conversation |
| Was the policy actually followed? | Records that the process produces: training completions, inspection logs, access reviews, signed forms | Records kept by the person who left last year |
Two of those questions deserve a closer look because they are where small companies lose the most time. The first is “did people read it”, because a document that was emailed to everyone proves only that it was sent, and an auditor will ask for a record per person that shows who confirmed, which version they confirmed and when. The second is “what changed since last time”, because an auditor who finds a policy revised since the last audit will want to see what the revision was and that the people affected were told, which is the NDA situation above.
The same logic applies to the records that show a policy being followed, which are not policy documents at all: training completions, inspection logs, access reviews and signed forms. Those live with the people who do the work, and they are the evidence most likely to be in a place only one person knows about. Our guide to the document audit trail covers the record of what happened to the documents themselves, and our guide to policy acknowledgment tracking covers the proof that people were told.
Run a gap analysis in a week
A gap analysis compares what the criteria require with what you can show, and its output is a list of gaps with an owner and a date against each. The method is simple enough that a company without a compliance team can run it in a week, which matters because the temptation is to buy a tool or hire someone before knowing what is actually missing.
Take the audit scope and list the requirements that apply to you, using the standard itself, the request list from the auditor or your own policy list. Next to each requirement, write the policy or procedure that answers it and the record that shows it is followed. Where either is missing, outdated or held only in someone’s head, mark it as a gap, and give each gap a plain description, an owner and a date. Sort the gaps into three groups: things that must be fixed before the audit, things that can be fixed after as long as you can show a dated plan, and things that don’t apply to you and need a recorded reason.
The last group matters more than it looks. An auditor who finds a requirement you haven’t addressed will ask why, and “it doesn’t apply to us because we don’t do that” is a perfectly good answer if it is written down with the reasoning and approved by someone, and a poor one if it is offered for the first time in the room. Many standards expect exactly that record, and our guide to policy exceptions covers how to keep one.
Run a mock audit
A mock audit is a rehearsal in which someone other than the policy owner plays the auditor, and it is the most useful single activity in preparing for a real one. It works because it tests what the auditor tests, which is whether the evidence can be found, rather than whether you think it exists.
Pick ten samples the way an auditor would, including some recent joiners, some recently changed policies and some records from the far end of the period, and for each one ask for the policy, the approval, the acknowledgment or record and the review date, then time how long each takes to produce. Do not help the person finding them, and write down where they went looking, because the places people look are the places the auditor’s request will end up.
The slowest records are the ones to fix first, and that includes records that exist but only on one person’s laptop. If you find a record that is missing, resist the temptation to recreate it after the fact with a backdated signature, because auditors check dates against logs and an honest gap with a plan is a minor finding, while a reconstructed record that is discovered is a question about everything else you have shown them.
A 90-day plan, and a two-week plan
If you have three months, spread the work so that the last month is rehearsal rather than repair. The plan below is built for a company without a compliance team, and it assumes the audit is against a standard or a customer’s requirements that you can get in writing.
Days 90 to 61. Get the audit plan and the request list, name the audit liaison and run the gap analysis, finishing with a list of gaps that is short enough to act on.
Days 60 to 31. Close the gaps, starting with the missing policies, which need writing, approving and sending out for acknowledgment, and then the overdue reviews. Move evidence into one place as you go, so that the mock audit is testing a system rather than a pile.
Days 30 to 8. Run the mock audit, fix the slowest records and brief the people who will be interviewed on what the audit is for and what their part of it looks like, without scripting their answers.
The final week. Hold steady. Freeze policy changes that can wait, because a policy rewritten in the last week is a policy whose evidence is least likely to be complete, and use the time to check the logistics: the room, the access, the schedule and who is available when.
If your audit is in two weeks, the plan changes shape rather than disappearing. Ask the auditor immediately for the request list and the plan, run a one-day gap analysis on only the areas they will sample, and fix in this order: records that are missing but can truthfully be produced, policies that exist but were never approved or sent, and reviews that are overdue and need only a decision. For anything that cannot be fixed in two weeks, write a short, dated plan and be ready to show it, because an auditor who sees a gap you found yourself, with an owner and a date, treats it very differently from one you didn’t know about.
Prepare people for interviews
Auditors interview the people who do the work, because they are checking whether the paper matches practice. They will ask someone in operations how they know which version of a procedure to follow, ask a new joiner what they were told about the policies on their first day, and ask a manager what happens when someone breaks a rule, and the answers need to match what the documents say.
Prepare people by explaining what the audit is for, which is to check the system rather than to catch them out, and by telling them what they will be asked about in general terms. Do not script answers, because auditors notice rehearsed language quickly and a scripted answer that is slightly wrong is worse than an honest one. Instead, make sure each person knows where their policies and procedures live, can find the current version and can describe what they do in their own words.
The questions auditors ask are usually plain: “Can you show me the procedure for this?”, “How do you know it is the current version?”, “What happens if this goes wrong?”, “When were you last told about changes?” and “Who would you ask if you weren’t sure?” Every one of them has a good answer if the policies are in one place, the version is visible and a change always arrives as a message people have to confirm, and a poor one if the answer is that someone emailed it a while ago.
Give the audit liaison a backup, and tell everyone that any request from the auditor goes through them, so the auditor gets one consistent answer and nothing is promised that cannot be delivered.
Audit day
On the day, the aim is to make the auditor’s work easy and your answers consistent. Give them a room, or a shared view, where they can work without interruption, and keep a request log that records each thing they ask for, who is finding it, when it was given and what version was provided. That log becomes a record of your own that shows the audit ran in an orderly way, and it is the first place to look if there is later disagreement about what was provided.
It is worth giving the auditor access to the documents rather than answering every request by email. If your policies live in a system where an auditor can be given read-only access, the requests largely answer themselves, and in AllyMatter that means giving the auditor a Viewer seat, where they see only the documents their tags allow and nothing else in your workspace. Where that isn’t possible, put the evidence in one shared folder with a clear structure and give them access to just that.
Hold a short wrap-up with the auditor at the end of each day, because it lets you hear what they are noting before it becomes a written finding. An auditor who says “I couldn’t find the approval for this one” at the end of day one has given you a night to find it, and one who says it for the first time in the closing meeting has not.
When a record is missing, say so plainly and say what you will do about it. Auditors expect imperfection, and what they are measuring is whether the system notices and fixes its own gaps. A calm “we don’t have that, here is why, and here is what we are doing” tends to leave a better impression than a long search that ends in nothing.
Findings, nonconformities and corrective actions
Almost every audit produces findings, so the first thing to do with a finding is to put it in proportion. A finding is a statement that something observed doesn’t meet a requirement, and auditors usually grade them by how serious and how widespread the gap is.
The terms vary a little between standards, but the pattern is consistent. An observation or opportunity for improvement isn’t a failure, it is something the auditor thinks you should look at. A minor nonconformity is a requirement that is partly met or an isolated lapse, and it needs a corrective action plan that will be checked at the next audit. A major nonconformity is a requirement that isn’t met at all, or a lapse that points to a systemic failure, and it can delay or suspend a certificate, bring a customer’s business to a pause or, for a regulator, lead to a fine or an order.
The finding is not the part that determines how the audit goes, it is the response. A corrective action plan is accepted when it deals with the cause, not just the instance, and when it includes a way to check that the fix worked. Many companies write the plan too narrowly: they fix the one record the auditor found and consider it closed, and the same gap appears in the next sample.
Take the NDA sample from earlier as an example of how the five steps work. Containing it means getting that person to sign the current NDA, which is quick. Finding the cause means asking why a joiner could start in the gap between the old version being withdrawn and the new one being ready, which points to something nobody owned. Fixing the cause means a rule for what a new hire signs while a policy is being rewritten, sent to whoever hires, and the check later is that the next sample of recent joiners has a record each. A plan that stopped at the first step would have closed the finding and left the gap.
The fourth step, telling people, is the one most often skipped, and it is the one that makes the fix durable. A changed policy that doesn’t reach the people it affects has not changed anything on the floor, and the acknowledgments are what show the auditor that the change landed.
If an audit goes badly, with a major finding, it is still recoverable. Read the report as carefully as you read the standard, ask the auditor what evidence would close each item, agree dates in writing, and treat the follow-up audit as another sample rather than a verdict.
After the audit: stay ready
The best audit preparation is the work that doesn’t stop afterward. Fold the corrective actions into your normal rhythm, put the next review dates on the calendar and keep each change approved, sent and acknowledged as it happens, so that the next audit is a sample of normal work and not a project.
Three habits do most of the work. The first is a review date on every policy, with a person responsible and a visible alert when it arrives, so reviews don’t depend on memory; our compliance calendar guide covers the rhythm. The second is treating every change as a controlled change, approved by the right people and sent to the right people before it takes effect, which is what a document control procedure formalizes. The third is keeping evidence where the work happens rather than collecting it in the week before an audit, which is the difference between a company that is audit-ready and one that is audit-prepared.
For a company growing past 50 or 100 people, this is also the point where a compliance program starts to pay for itself, because the same evidence serves the next audit, the next customer questionnaire and the next acquirer’s due diligence.
If your audit is against a named standard
Everything above applies whichever standard you are audited against, and the differences are in what the standard asks to see and how the audit is organized. A few pointers by type of audit follow, with links to our own guides where we have one.
SOC 2. The audit is performed by a CPA firm, and a Type 2 report covers a period of months, so your policies and their evidence have to be in place for the whole of it; see our guide to SOC 2 policies.
ISO 9001. A certification body audits you in two stages, and visits every year afterward in surveillance audits that sample the system; see our guide to the ISO 9001 surveillance audit.
ISO 27001. The structure resembles ISO 9001, with an information security management system as the subject, and the policies, risk records and evidence of operation are what the auditor samples.
HIPAA. An audit or an investigation looks at whether required policies exist, whether staff were trained and whether the safeguards are documented, and the policy and training records are the first things asked for.
Accreditation surveys. Accreditors such as CARF review policies and procedures as part of a survey that decides accreditation; see our guide to CARF accreditation.
Customer audits. These often begin with a questionnaire, and the answers are tested later by an audit; see our guide to answering a security questionnaire. For what a specific standard or regulation requires, our sister site Policy and Compliance explains the requirements and can introduce an independent expert who builds the program with you.
Fix the paper side this week with AllyMatter
We built AllyMatter for the part of an audit that is about policies and procedures: whether each one is written, approved, current, in front of the right people and acknowledged, with a record that proves it without a week of digging. It doesn’t replace your internal audit or the people who run your compliance work, it removes the scramble for the evidence they depend on.
| On audit week the auditor says | What you do in AllyMatter |
|---|---|
| “Which version is current?” | Show the policy: only the approved version reaches your audience, and the version badge sits on the document |
| “Who approved this, and when?” | Open the document’s log, where each approval and rejection appears by name with its date, and each rejection carries its reason |
| “Show me that people read it.” | Show the acknowledgment records, one per person with the version and the time, and the count of people who have confirmed against the people asked |
| “Who opened it, and for how long?” | Use Document Analytics: views, time on screen and last viewed for each person, and the status of each request |
| “What changed since last year?” | Compare any two versions, with every word removed and added shown side by side |
| “Who is supposed to see this?” | Show the tags: the people holding the tags on a policy are the people it is sent to |
| “Is this still reviewed?” | Show the review date on the policy, the alert and email that fire when it arrives, and the re-approval that closes it |
| “Where is the supporting record?” | Open the evidence file attached to the policy, such as a training record or an inspection report |
| “Give me the trail.” | Export the document’s log as a PDF or CSV, filtered by date range or person, or give the auditor Viewer access to what their tags allow |
Setup takes about half an hour, and moving your existing documents in yourself takes about a day; on yearly plans, our migration service usually finishes within a week and often sooner. A practical first day looks like this: bring in the ten policies an auditor is most likely to sample, tag them so each reaches the people it should, set an approval flow, send them out for acknowledgment with reminders on, put a review date on each one and attach the evidence files that go with them. At the end of the day, export one document’s log as a PDF, which is the dry run of the first request an auditor will make.
A policy center won’t write your policies for you, and it won’t collect the logs from your other systems, those stay with the people who own them. What it does is make sure the written rules are approved, current and confirmed by the people they apply to, and that you can show it in minutes, which in most audits is the part that costs the most time. On yearly plans, migration is on us.
Start your 30-day free trial of AllyMatter. No credit card to start, and a 30-day money-back guarantee if you subscribe and change your mind. Free migration.
Common mistakes
Preparing for the standard instead of the sample. Reading every requirement is less useful than testing the ten records an auditor is most likely to choose, so run the mock audit early.
Treating a sent document as a read document. An email to everyone proves a message was sent, so collect an acknowledgment per person that names the version.
Changing policies in the final weeks. A policy rewritten at the last moment is the one whose evidence is incomplete, so freeze non-urgent changes in the last week.
Recreating records after the fact. A backdated record that is discovered casts doubt on everything else, and an honest gap with a dated plan is far cheaper.
Closing the finding, not the cause. If you fix only the record the auditor found, the next sample will find another, so ask why until you reach something you can change.
Questions about preparing for a compliance audit
How long does it take to prepare for a compliance audit?
For a company with its policies already written and approved, about 60 to 90 days is a comfortable preparation window, and the first 30 are usually spent finding out where the evidence is. A company starting from scattered documents needs longer, and a company with an audit in two weeks can still prepare by choosing the highest-risk areas, fixing the records the auditor is most likely to sample and being honest about the rest.
What do auditors look for?
They look for three things in order: a written rule, evidence that the rule was followed, and evidence that someone checks that it keeps being followed. They draw a sample, ask for the policy and the records behind it, and interview the people doing the work to see whether what they say matches what the document says.
What is the difference between an internal audit and an external audit?
An internal audit is run by your own people or a consultant you hire, to find problems before anyone else does. An external audit is run by someone outside, such as a certification body, a customer or a regulator, and its results are what a certificate or a contract decision rests on.
What is a nonconformity?
A nonconformity is a requirement that isn’t being met, found when the auditor compares what you do with the standard, the law or your own procedure. Auditors usually grade them as minor, where a requirement is partly met or a lapse is isolated, or major, where a requirement isn’t met at all or the problem is systemic.
What happens if you fail a compliance audit?
Most audits don’t have a pass or fail grade, they have findings. Minor findings need a corrective action plan, while a major finding can delay a certificate, put an existing one at risk or lead a customer to pause business until it is fixed, and a regulator’s finding can bring a fine or an order.
Can a small business do its own compliance audit?
Yes. A small company can run an internal audit with a checklist drawn from the standard or the law it is held to, and it is worth doing before any external audit, as long as the person doing the checking doesn’t check their own work.
Should the auditor have access to our systems?
Often the easiest way to answer requests quickly is to give the auditor read-only access to what they need. In AllyMatter an auditor can be given Viewer access, and they see only the documents their tags allow, with the rest of your workspace out of view.
A compliance audit rewards the company whose evidence is easy to find, and the most useful preparation is a system in which every policy is approved, sent, acknowledged and reviewed as part of normal work, so that the audit becomes a sample of what already happens.
Start your 30-day free trial of AllyMatter. No credit card to start, and a 30-day money-back guarantee if you subscribe and change your mind. Free migration.