A password policy sitting in a shared drive proves that a control was designed it doesn't yet prove that control is operating. Here is what an auditor actually checks once the document review is done, and how to be ready for that part of the audit.

A team can have every policy written, every procedure signed off, and every folder organised and still walk out of an audit with findings. That surprises most first-time compliance leads, because the assumption going in is that the document set is the audit. Documentation is the starting point an auditor uses to understand what a control is supposed to do. A meaningful part of the audit is then spent checking whether that is what actually happens.

What auditors are actually testing

Frameworks like SOC 2, ISO 27001, and CMMC follow different assessment methodologies, with their own scoping, evidentiary, and reporting requirements but they lean on a similar toolkit to get there: document review, interviews, direct observation, and testing. NIST SP 800-171A, the assessment methodology behind CMMC, defines three formal ways assessors gather proof: examining documentation such as policies and system logs, interviewing the people who run the process, and testing the control directly. The Examine method covers reviewing, inspecting, or analysing objects like specifications and mechanisms, while Interview means talking to individuals or groups to validate understanding, and Test means putting a control through real conditions to compare expected behaviour against what actually happens.

ISO 19011, the international standard that provides guidelines for conducting management-system audits, recommends a similar combination of open-ended interviews, direct observation, and document review, because documented procedures don't always reflect actual practice on their own. An ISO 27001 internal audit follows a comparable pattern: auditors sample proof such as access logs, encryption settings, and incident reports, then compare those findings against what the documentation says should be happening. The specific scope, sample selection, and reporting criteria still vary by framework and by certification body.

Interviews: where the paperwork meets reality

Audits commonly include a stage where the auditor stops reading and starts asking. This is usually where genuine gaps surface. Auditors ask staff how a process works and then verify those answers against the actual systems and records, and this comparison between what is documented and what people describe is where many meaningful findings emerge.

Auditors use these conversations to check that the person responsible for a control genuinely understands it and can describe how it operates. A mismatch between what the documentation says and what personnel actually describe is one of the more common sources of audit exceptions though interview responses are themselves a recognised form of audit evidence, and are typically weighed alongside corroborating records rather than dismissed outright. A written access-control policy is strongest when the engineer who manages access can also explain, unprompted, how offboarding actually happens.

If the three answers don't align with each other or with the documented offboarding policy, that inconsistency is a signal worth investigating further. It may point to a control gap, or simply to a documentation or communication issue either way, it's something the auditor will want to trace back to a root cause before deciding whether it rises to a finding.

Proof over time, not a snapshot

The second gap between paperwork and reality is time. A policy describes a control as a permanent state. An auditor needs proof the control held up across an entire review period, not just on the day it was written.

For a SOC 2 Type II report specifically, controls must be shown to operate for the full review period, typically six or twelve months, with evidence collected continuously through that window rather than captured at a single point in time. Type II evaluates both the design of a control and whether it operated effectively across that observation period, which is exactly why most enterprise buyers ask for a Type II report rather than a Type I.

That evidence rarely comes from one large check. Instead, auditors sample a population of dated artifacts logs, tickets, and approvals pulled from across the observation window rather than relying on a single-day snapshot. The size and method of that sample varies by engagement: it's shaped by factors like the total population size, how frequently the control operates, the risk associated with the control, and the specific sampling methodology the audit firm or framework calls for, so there's no single sampling rate that applies across all audits.

Documentation age is itself a signal worth watching

Verbal assurances and undocumented practices aren't automatically disqualified as evidence interviews are a legitimate part of how assessors build understanding of a control. But auditors generally look for those statements to be corroborated by something dated and objective: system logs, access records, monitoring outputs, training records, approvals, and change histories, ideally with screenshots and timestamps attached. A policy without a matching, dated evidence trail behind it tends to read to an auditor as untested rather than clearly compliant.

Where auditors go looking

Five places documents alone can't reach:

Documents vs. evidence: the practical difference

Implemented and documented

On a CMMC assessment specifically, the assessment team reviews the objective evidence package, conducts interviews so staff can demonstrate knowledge of the practices, and directly observes physical and technical controls in operation before compiling findings on what was met and what was not. CMMC's scoring methodology expects each practice to be both implemented and documented as required by the practice statement so a control that's technically enforced but missing the documentation the specific practice calls for can still come up short on that practice, and the reverse holds too: a well-written policy with no operating evidence behind it doesn't satisfy the requirement either. The exact documentation expectations vary practice by practice, so this isn't a blanket rule that every control needs a standalone policy document.

Getting ready for the part documents can't cover

Preparing only the policy folder is preparing for the part of the audit that takes the least time. The stronger approach is to rehearse the same evidence trail an auditor will actually pull:

A policy is real evidence that a control was designed, and in some cases it's evidence enough on its own. But for most operating controls, an interview, a sample, and a live walkthrough are what confirm design turned into practice and that's the part of the audit that tends to determine the outcome.