The word turns up in three conversations in the same week and means something different in each. A customer's procurement team asks whether you have been audited. Your insurance broker asks for the findings of your last security audit. An examiner asks for the documentation behind a compliance filing somebody at your company signed. Three sets of expectations, and companies routinely spend six figures satisfying the wrong one. An audit is a specific kind of work with specific properties, and much of what gets sold under the name is something else.
What Is a Security Audit?
The NIST glossary, carrying the CNSSI 4009-2022 definition, describes an audit as the independent review and examination of records and activities to assess the adequacy of system controls, to confirm compliance with established policies and operational procedures, and to recommend changes where they are needed. The same entry adds a note worth reading twice: audit is often used alongside or in place of inspection and assessment, and those terms are not interchangeable.
Four properties separate an audit from everything adjacent to it.
The criteria are fixed before fieldwork starts. A regulation, a contract or a published standard sets the yardstick, and it does not move because the result is inconvenient. That is why an audit can produce a finding you disagree with.
The auditor chooses the sample. You do not hand over the four access reviews that went well. The auditor picks the months, systems and tickets it wants, which is the point of sampling.
The output uses verdict language. An opinion, an exception, a nonconformity. An assessment gives you a gap list; an audit gives a judgment about whether something met a standard.
It is written for somebody else to rely on. A customer, a regulator, an insurer, a board. That reliance makes independence a requirement rather than a courtesy, and it is why the person who built a control cannot be the person who tests it.
Most work sold to small and mid-sized companies as a security audit is an assessment or a certification rather than an audit in this sense. None of the three is inferior. They answer different questions for different people.
What a Security Audit Examines
Scope varies by framework, but the domains are consistent enough that an auditor's request list rarely surprises anyone twice. What changes is depth.
| Domain | What the auditor tests | The evidence it asks for |
|---|---|---|
| Identity and access | Authentication strength, least privilege, joiner and leaver handling, privileged accounts | Access review records with dates and reviewers, termination tickets, an MFA coverage report |
| Network | Segmentation, firewall and intrusion detection configuration, remote access, wireless | Rule sets with change history, network diagrams, remote access logs |
| Data protection | Classification, encryption in transit and at rest, retention, secure disposal | Key management records, storage configuration exports, destruction certificates |
| Endpoints | Patching, malware protection, device management, detection coverage | Patch compliance reports, agent coverage against the asset inventory |
| Physical | Facility access, media handling, equipment security | Badge logs, visitor records, server room access lists |
| Security operations | Logging, alerting, triage, vulnerability management, incident response | Alert queues with dispositions, scan results with remediation dates, tabletop records |
| Third parties | Due diligence, contract clauses, ongoing monitoring | Vendor inventory, signed security terms, reports collected from suppliers |
The last row has expanded fastest, because the data an auditor asks about increasingly lives on somebody else's platform. A third-party risk program that exists only as a spreadsheet of vendor names produces nothing testable, and it becomes a finding in almost every first audit.
Notice what is not on the list. An audit does not test whether your security is good. It tests whether the controls named in the criteria were implemented and operating. A company can hold a clean report and still ship an insecure product, if the insecure part sat outside the scope.
Types of Security Audits
The label on the engagement tells you what the criteria are, which tells you what the report can be used for.
Compliance audits measure you against a named regulation, standard or contract. The criteria come from outside and are not negotiable. This is the type most companies mean, and the report exists so somebody else will accept it.
Technical or IT security audits examine the infrastructure itself: configurations, patch levels, firewall rules, endpoint coverage. Narrower than a compliance audit, deeper on the technology.
Information security audits are broader, covering governance, policy, training and process alongside the technology. They surface the findings nobody wanted, because they follow the data into departments that do not think of themselves as technical.
Configuration audits compare live settings against a defined hardening baseline. They automate well and are the backbone of continuous monitoring programs.
Risk-based audits start from assets and threats rather than a control list, then judge whether the protections match the exposure. Insurers and boards ask for these more often than regulators do.
Social engineering audits measure how people respond to phishing, pretexting and physical entry attempts, testing the control you cannot read out of a configuration file.
Two things frequently sold as audits are not audits. A vulnerability scan is an automated search for known weaknesses, and a penetration test is a scoped attempt to exploit them. Both produce technical findings, neither tests whether a control operated across a period, and neither issues an opinion. They are inputs to an audit.
Internal vs External Security Audits
The distinction is about who performs the work and what independence they can credibly claim, not about how rigorous the testing is.
A middle category gets forgotten. A second-party audit is one your customer or business partner performs on you directly, usually under a right-to-audit clause somebody signed years ago without reading. Enterprise contracts increasingly carry them, and the first time one is exercised is a bad moment to discover what evidence you cannot produce.
How a Security Audit Works
The phases are the same whether the engagement is a two-week internal review or a formal examination. Durations scale with scope rather than changing shape.
- Scoping. Which systems, which locations, which criteria, which period. Written down and signed, and everything later is judged against it
- The request list arrives. Policies, network diagrams, asset inventories, prior findings, and the evidence for each control in scope
- Walkthroughs and interviews. The auditor watches a control being performed and compares it against what the policy claims happens
- Technical testing. Configuration review, scan results, log sampling, access recertification records, backup restoration evidence
- Analysis. Findings are drafted, ranked by severity, and put to management for a written response before anything is final
- The report is issued: scope, criteria, tests performed, results, exceptions and management responses
- Remediation and follow-up testing on whatever failed. In recurring regimes this sets the opening position for next year
Fieldwork is an exchange, and understanding its shape removes most of the anxiety. The auditor is not hunting for a way to fail you. It is establishing, from records rather than assurances, whether a control operated.
Which Regulations Require a Security Audit
This is where careful reading pays for itself, because almost no US rule requires a thing called a security audit. Rules require a risk analysis, a periodic evaluation, penetration testing, vulnerability assessments, or a written report to the board, and those words carry different obligations, frequencies and independence requirements.
The regimes people most often call audits are not government rules at all. A SOC 2 examination is an attestation performed under AICPA standards by a licensed CPA firm, and its force comes from your customer contracts rather than any statute. PCI DSS is enforced by the card brands through contracts with acquiring banks, and whether you validate through a qualified security assessor or a self-assessment questionnaire depends on the merchant level your acquirer assigns. ISO 27001 is a certification audit performed by a certification body against a published scheme.
The practical consequence: if you are buying an engagement to satisfy a specific obligation, read the clause and buy exactly what it names. Companies buy a general security audit for HIPAA and find it contains no risk analysis, or buy a vulnerability scan for the Safeguards Rule and find they still owe a penetration test.
How to Prepare for a Security Audit
Most first-audit pain is missing records rather than missing controls. The controls were running; nobody kept proof.
The rhythm is the same whether the endpoint is an internal review or a formal attestation, which is why the work of preparing for a SOC 2 audit transfers almost entirely to any other framework you later have to satisfy.
How Much Does a Security Audit Cost?
Be skeptical of any confident single figure, including the ranges published by firms that sell audits, because none is drawn from a published dataset. What is knowable is what moves the number: systems and locations in scope, criteria tested, whether the auditor must travel, whether a period or a point in time is examined, and how much evidence you can produce without help. The last one is the variable you control and usually the largest.
Two costs get left out of quotes and should not be. Staff time during fieldwork is real and never appears on an invoice, and remediation after the report frequently exceeds the fee, because the findings are the point.
How Often Should You Have a Security Audit?
Where a rule sets a frequency, that is the answer and there is nothing to weigh: annual penetration testing under the Safeguards Rule and under Part 500, vulnerability assessments at least every six months under the Safeguards Rule, an annual New York filing by April 15. Where no rule applies, annual is the working default for a full audit, with focused quarterly reviews on high-risk systems and automated configuration checks running continuously underneath both.
The trigger most often missed is change rather than time. A migration, an acquisition, a new product line or a serious incident all invalidate the assumptions the last scope rested on, and both Part 500 and the Safeguards Rule say so in their own language.
What Happens After a Security Audit
The report names its scope, its criteria, the tests performed and the results, with every exception stated alongside management's written response. Read your own report the way a customer would: a spotless result on a narrow scope says less than two well explained exceptions on a scope that covers the product being bought.
Findings get ranked, owned and dated. Anything critical is fixed and retested rather than accepted, and anything accepted gets a written risk acceptance with a name on it, because an unexplained open finding in year two is worse than the original problem.
Key takeaways
- A security audit is an independent examination against criteria fixed in advance, with the auditor choosing the sample and issuing findings, exceptions or an opinion. An assessment finds gaps; an audit renders a judgment.
- The domains are consistent: identity and access, network, data protection, endpoints, physical security, security operations and third parties. What is requested is records, not assurances.
- Internal audits find problems cheaply. External audits produce something a stranger will accept. Programs that work run both.
- Almost no US rule requires a thing called a security audit. HIPAA requires a risk analysis and a periodic evaluation, the FTC Safeguards Rule requires continuous monitoring or annual penetration testing plus semiannual vulnerability assessments, and NY DFS Part 500 requires annual penetration testing by a qualified internal or external party.
- SOC 2, PCI DSS and ISO 27001 are contractual or scheme obligations rather than statutes, and each names a different kind of qualified performer.
- Scoping sets every later cost, and an incomplete asset inventory is the finding that generates other findings.
- A clean report covers its scope, its period and its sample. What it excluded is the more useful question.
Common questions
What is a security audit?
An independent examination of records, systems and activities against criteria set before the work begins, run to establish whether controls were implemented and operating. Fixed criteria, auditor-selected samples, verdict language and a report meant for an outsider to rely on are what make it an audit.
What is the difference between a security audit and a security assessment?
The criteria and the output. An assessment measures where you stand, hands you a gap list, and can flex its scope as it goes. An audit tests against a yardstick fixed in advance and produces findings, exceptions or an opinion. NIST's glossary says outright that the terms are not interchangeable.
How long does a security audit take?
Six to ten weeks is typical from kickoff to issued report: two weeks of scoping, two of walkthroughs and document review, two to three of technical testing, then two of analysis and drafting. Attestations that examine a period add the observation window, which cannot be compressed.
What does an auditor ask for?
An asset inventory, network and data flow diagrams, policies, access review records, termination tickets, change approvals, vulnerability reports, log samples, backup restoration evidence, training records, vendor agreements and your last set of findings. The list is predictable, which is why companies that keep evidence continuously have easy audits.
Is a security audit required by law?
Rarely by that name. Rules require named activities instead: a risk analysis and a periodic evaluation under the HIPAA Security Rule, penetration testing and vulnerability assessments under the FTC Safeguards Rule and NY DFS Part 500, and an annual written report to the board under the Safeguards Rule.
Who can perform a security audit?
It depends on the regime. NY DFS accepts a qualified internal or external party for its annual penetration testing, and the Safeguards Rule sets no performer requirement at all. A SOC 2 examination requires a licensed CPA firm, ISO 27001 a certification body, and PCI DSS validation above certain volumes a qualified security assessor.
How much does a cyber security audit cost?
No authoritative dataset publishes this, so treat single figures with suspicion. Scope drives it: systems and locations examined, criteria tested, travel, and whether a period or a point in time is covered. Staff time and remediation are usually larger than the fee and never appear in the quote.
How often should a security audit be performed?
Follow the rule if one applies, since several set explicit frequencies. Otherwise annual for a full audit, quarterly focused reviews on the highest-risk systems, and continuous configuration checking underneath both. Material change matters more than the calendar, because a migration or acquisition invalidates the assumptions behind the last scope.
Is a penetration test a security audit?
No. A penetration test is a scoped attempt to exploit weaknesses, producing technical findings against a moment in time. An audit tests whether controls operated against fixed criteria, often across a period, and issues a judgment. Several rules require penetration testing by name, so a test is often something an audit checks you performed.
What happens if you fail a security audit?
There is usually no pass or fail. Findings are recorded with a severity, management writes a response, and remediation is tracked to a date. In certification schemes, nonconformities must close before a certificate issues. In attestations, exceptions are printed in the report your customers read.
On this page
- What Is a Security Audit?
- What a Security Audit Examines
- Types of Security Audits
- Internal vs External Security Audits
- How a Security Audit Works
- Which Regulations Require a Security Audit
- How to Prepare for a Security Audit
- How Much Does a Security Audit Cost?
- How Often Should You Have a Security Audit?
- What Happens After a Security Audit
Daniel Reyes
Daniel Reyes is a CISSP who spent twelve years in security operations, most recently leading a detection and response team for a mid-sized healthcare group in Texas. He reviews every resource and breach report on Cyber Security Firms for technical accuracy before it publishes.
Most of the people he has trained arrived having been told too much: a dozen acronyms, six vendors, and no clear idea which risk was theirs. His approach is to explain what an attack actually does before naming the tool that stops it, on the basis that most breaches start with something a reader could have recognised.