Security Audit Procedures: What Auditors Do, Step by Step (With Evidence Lists)

Every test an auditor performs is one of four procedures, or a combination of them. Audit standards use slightly different names, and the names matter because they appear in the evidence request:

1. Inquiry. Asking the control owner how the control works, when it runs, who performs it and what happens on exception. Inquiry alone is never sufficient evidence; it tells the auditor where to look.
2. Observation. Watching the control performed in real time: a badge reader rejecting a visitor, an engineer approving a change, a restore being run. Observation proves the control can operate; it says nothing about last month.
3. Inspection. Examining the record the control left behind: configuration exports, tickets, logs, signed reviews, screenshots with timestamps. This is the workhorse procedure and the one most evidence requests are about.
4. Re-performance. The auditor independently repeats the control and compares results: recalculating who should have access and reconciling it to who does, re-running a configuration check, attempting the login that the policy says should fail.

NIST SP 800-53A collapses these into three assessment methods: examine (documents, records, configurations, observed activities), interview (people) and test (mechanisms and processes exercised under specified conditions). It adds two attributes that decide how hard a control is pushed: depth (basic, focused, comprehensive) and coverage (how many instances). PCI DSS v4.0 prints a testing procedure beside every requirement using the verbs examine, interview and observe, which is why a Report on Compliance reads like a procedures manual.

The strength ordering drives everything else. A control supported only by inquiry is a control the auditor has an opinion about. A control supported by inspection of the full population, with two items re-performed, is a control the auditor can sign for. When an audit report feels thin, it is almost always because the procedures stopped at inquiry and observation.

Each control gets two questions, and they need different procedures. The first is whether the control is designed to address the risk: if it were performed exactly as written, would it prevent or detect the thing it exists for? The second is whether it operated consistently across the period under review.

Design is tested with a walkthrough: one instance of the process followed end to end, the policy and configuration read alongside it, the owner asked what happens when the trigger fires. Operation is tested against a population. The auditor asks for the complete list of instances in the period (every change, every new account, every backup job), selects a sample, and inspects or re-performs each sampled item. A missing approval in the sample is an exception; enough exceptions make a finding.

Sample sizes are where auditees get surprised. The ranges in Figure 2 are the ones SOC 2 and internal-control audit firms commonly use, and each firm publishes its own in its methodology: one item for an annual control, two for a quarterly one, up to forty for a daily one, more where the population is very large or earlier years produced exceptions. The population has to be complete and demonstrably so, which is why the auditor asks for the export with its row count and the query that produced it. A spreadsheet someone assembled by hand will be re-requested.

SOC 2 makes the distinction visible: a Type 1 report answers the design question at a date; a Type 2 report answers the operating question over a period, typically three to twelve months. Most security audits that matter to customers are operating-effectiveness audits.

Audit methodologies differ in vocabulary and agree on sequence. ISO 19011 describes the process for auditing any management system and ISO/IEC 27007 applies it to information security; the AICPA attestation standards shape SOC 2; NIST SP 800-53A shapes federal and defence assessments. Strip the vocabulary and nine phases remain.

1. Engagement and scope. The criteria (which framework or control set), the systems and locations in scope, the period under review, exclusions, and the names of the people who will answer for each domain. Scope written loosely here becomes a dispute in phase 8.
2. Risk-based planning. The auditor decides which controls get comprehensive procedures and which get basic ones, based on where the data and the privilege sit. A control that protects cardholder data or domain admin gets re-performance; a visitor log gets inspection.
3. Evidence request list. Often called the PBC list (prepared by client): every artefact needed, the period it must cover, the owner and the due date. A good list names the system to export from, which prevents a week of back and forth.
4. Walkthroughs. One instance of each process followed end to end with the owner, from trigger to record. Design conclusions are formed here, and the auditor learns where the records live.
5. Control testing. Populations requested, samples selected, items inspected or re-performed, exceptions logged. This is the longest phase and the one that benefits most from preparation.
6. Technical procedures. Configuration review against baselines, authenticated scans, privileged access reconciliation, log sampling, cloud posture queries, and a penetration test where exploitability has to be proven with a working attack path. Section 5 covers these.
7. Findings analysis. Exceptions are grouped by root cause, rated for severity, and checked for aggregation: five low findings that share a cause are one high finding.
8. Reporting. A draft goes to management for factual accuracy and a written response with owners and dates. The final report carries the opinion, the findings, the responses and the scope limitations.
9. Follow-up and retest. Closure is evidence, dated and signed: a new configuration export, a new population sample, a re-performed test. A finding closed on inquiry alone reopens at the next audit.

In a fixed-scope, 14-day IT security audit the calendar compresses but the phases do not: scoping and the evidence list in the first two days, fieldwork and technical procedures through day eleven, analysis and the readout in the last three, with the retest scheduled after remediation. Longer audits spend the extra time in phases 5 and 6, where the evidence is.

The table below lists, for the domains that produce the most findings, the procedure an experienced auditor runs and the evidence it needs. Control family references follow NIST SP 800-53; the same procedures satisfy SOC 2, ISO 27001 and PCI DSS auditors with different clause numbers attached.

Two patterns repeat. First, almost every procedure starts with a complete population from the system of record and a reconciliation to a second source (HR, tickets, the asset inventory). Second, every procedure ends with an artefact that carries its own date. Teams that keep those exports and reconciliations as a matter of routine pass audits in days. The IT security audit checklist lists the artefacts by domain if you want to start collecting now.

Document review proves intent. Technical procedures prove reality, and they are where a security audit earns its name. They are performed with read-only access provisioned for the audit and removed afterwards, with every query and export logged.

• Configuration review. Settings exported from a sample of systems and compared against the agreed baseline, usually a CIS Benchmark or the vendor hardening guide. The evidence is the export plus the diff, with each deviation accepted, fixed or raised.
• Authenticated vulnerability scanning. A credentialed scan of a sample or the full estate, read together with the patch policy. The finding is rarely the vulnerability itself; it is the gap between the policy's timeline and the ticket ages.
• Privileged access review. Every administrator role from the identity provider, each cloud tenant and the main applications, reconciled to HR and to a business justification. Dormant and shared privileged accounts surface here in almost every first audit.
• Log and alert sampling. Ten dates chosen by the auditor; for each, proof that the expected events exist in the log platform and that a human or an automated rule reviewed them. A benign test event checks that alerting reaches a person.
• Cloud posture. A read-only role per account or tenant, then posture queries for public storage, open security groups, unrotated keys, missing MFA on root and break-glass accounts, and logging gaps. The account inventory itself is a finding when it is incomplete.
• Penetration testing as a procedure. When a control's failure would expose regulated data or administrative privilege, the auditor may commission or review a scoped manual test to prove exploitability with a working attack path. The report then becomes audit evidence. How a pentest fits inside an audit is its own topic; the short version is that it tests the attacker's path while the audit tests the control set.

Behind every line in an audit report sits a working paper, and the quality of the audit is the quality of that file. A working paper records which control was tested against which criteria, the procedures performed, the population and the sample, references to each piece of evidence, the result, any exceptions in detail, and who performed and who reviewed the test. Without it, the report is an essay.

Audit standards describe evidence as needing to be sufficient (enough of it), appropriate (relevant to the assertion and reliable in origin), and obtained by the auditor directly; narration by the auditee does not qualify. In practice that produces a handful of rules worth adopting on the auditee side too:

• Screenshots show the system name, the account used and a visible timestamp; cropped screenshots without context are re-requested.
• Exports keep their native format (CSV, JSON, the console's own report) and travel with a row count and, for anything contested, a hash.
• Evidence generated by the auditor (queries run under the read-only account) outranks evidence prepared by the auditee, and the auditor records the query.
• Each evidence file is referenced from exactly one working paper, so a reviewer can trace any sentence in the report back to a file in minutes.
• The file is retained for the period the framework or the engagement letter specifies, and access to it is restricted, because it is a map of your weaknesses.

An exception becomes a finding when it matters, and a finding is only useful when it is written so that the person fixing it, the person funding it and the person auditing it next year all read the same thing. Internal audit practice uses five parts, and security auditors who skip any of them produce reports that get argued about and never acted on.

• Criteria: the requirement, quoted. "PCI DSS 8.4.2 requires MFA for all access into the cardholder data environment."
• Condition: what the procedure found, with numbers. "Three of eleven jump hosts accept password-only logins."
• Cause: why, established with the owner. "Built from an older image outside the deployment pipeline."
• Effect: what it exposes, written as the attacker path it opens. "A stolen password reaches cardholder data directly."
• Corrective action: what, who, by when, and what evidence will close it. "Enforce MFA at the bastion; platform lead; 30 days; closure evidence is the bastion policy export and a failed password-only login attempt."

Severity is a judgment, and a defensible one combines two axes: how reachable the weakness is from where an attacker realistically starts, and what it reaches. A missing patch on an isolated test server and the same missing patch on an internet-facing portal with customer data behind it are different findings with the same CVE. Findings are then aggregated: a dozen low-severity exceptions that share a root cause (nobody owns the image pipeline) are reported once, as the high-severity finding they are together.

The procedures above are universal; what changes between frameworks is how prescriptive the procedure wording is and who is allowed to perform it.

The same evidence file supports all of them. An organisation that runs its own procedures against NIST SP 800-53A twice a year walks into a SOC 2 Type 2 or an ISO 27001 surveillance audit with the populations, samples and exports already sitting in the folder the auditor will ask for. Our NIST security audit guide covers the mapping between the publications.

Knowing the procedures changes preparation from guessing to assembling. Six things remove most of the friction:

1. Build the evidence list yourself first. For each control in scope, write the population source, the export method and the owner. Hand it to the auditor at kickoff; you will shorten phase 3 by a week.
2. Name one owner per domain who can answer inquiry questions and run the exports. Auditors lose days waiting for the one person who knows where the firewall rules are documented.
3. Provision read-only audit accounts in advance for the identity provider, the cloud consoles, the scanner and the log platform, with their own logging turned on. Screenshots by your staff are weaker evidence than queries by the auditor.
4. Run the reconciliations before the auditor does. Accounts to HR, admins to justification, assets to log sources, vendors to assessments. Every exception you find first is a finding you can close before it is written.
5. Keep an evidence room, a folder structure by control with dated exports, so that the artefacts exist as a by-product of operating the controls all year.
6. Rehearse the walkthroughs. Pick one change, one new starter, one incident and one restore from the period and follow each from trigger to record. Where the chain breaks is where the finding will be.

The 90-day preparation playbook schedules this work, and internal versus external audits explains which of these procedures your own team can legitimately perform before an external auditor repeats them.

Our IT security audit runs these procedures across 20 NIST SP 800-53 domains against the live environment, with each control evaluated for design and operating effectiveness through interviews, documentation review and technical evidence collection across on-premises, cloud (Azure, Entra ID, Microsoft 365, AWS) and DevSecOps environments. The engagement is fixed-price and agreed in writing, the remediation roadmap is delivered 14 days from kickoff, and you read the full report before you pay.

The deliverables are the ones this guide describes: an executive summary, a technical findings report written in the five-part format, a compliance gap matrix and a program plan, backed by a working-paper file you can hand to your next auditor.

Want the procedures run against your estate?

Tell us what framework your customers or regulators are asking about and what is in scope. We will send a fixed price in writing and a 14-day plan that names the evidence we will ask for on day one.

Related Reading

• What Is a Security Audit? Types, Process and Checklist
• 10 Crucial Steps for an Effective IT Security Audit
• How to Prepare for a Security Audit: The 90-Day Playbook
• NIST Security Audit: CSF 2.0, 800-53 and 800-171 Explained
• The Role of Penetration Testing in IT Security Audits

Published: October 2026 · Author: Alexander Sverdlov, Atlant Security

This guide describes audit procedures as practised under NIST SP 800-53A, PCI DSS v4.0, the AICPA attestation standards for SOC 2 and ISO 19011 with ISO/IEC 27007. Sample size ranges are common practice and vary by firm and by framework. Nothing here replaces the procedures your own auditor or certification body specifies for your engagement.