What is the difference between a security audit and a penetration test?

A security audit examines whether your security controls exist, are designed correctly and operate effectively against a standard such as ISO 27001, SOC 2 or PCI DSS, using documents, interviews and sampled evidence. A penetration test is an authorised attack on a defined scope by qualified testers to find and exploit vulnerabilities. The audit proves governance; the test proves whether the controls actually stop an attacker.

Does ISO 27001 require a penetration test?

Not in those words. Annex A control 8.8 requires technical vulnerabilities to be identified, evaluated and addressed, and control 8.29 requires security testing in development and acceptance. Certification auditors routinely expect a current penetration test report for in-scope systems as the evidence for both, together with remediation and retest records.

Does SOC 2 require penetration testing?

The Trust Services Criteria do not mandate a specific method, but the points of focus under CC4.1 and CC7.1 name penetration testing and vulnerability scanning as ways to evaluate controls and identify vulnerabilities. In practice nearly every SOC 2 auditor expects a penetration test within the examination period and asks for the report and remediation evidence.

Can the same firm do our audit and our penetration test?

Keep them separate. A certification body or CPA firm attesting to controls should not also be the party whose test results form the evidence, and the AICPA independence rules prohibit a CPA firm from attesting to its own work. Use a specialist testing firm for the test and an accredited body for the audit.

How often should we do a security audit and a penetration test?

Audits run on the framework's cycle: ISO 27001 surveillance every year with recertification every three years, a SOC 2 Type II examination each year, PCI DSS assessment annually. Penetration tests run at least annually and after significant changes, the floor set by PCI DSS 11.4, DORA Article 24 and most auditors, with release-tied tests for critical applications.

Is a vulnerability scan a security audit or a penetration test?

Neither. A vulnerability scan is an automated check for known weaknesses and is one input into both. PCI DSS v4.0.1 keeps scanning (Requirement 11.3) and penetration testing (Requirement 11.4) as separate requirements, and auditors generally reject a scan report presented as penetration testing evidence.

We have neither. Which should we do first?

Start with a penetration test of your internet-facing and business-critical systems. It gives you the real risk picture within weeks and produces the evidence an audit will later ask for. Then build the governance layer (policies, risk register, remediation process) and schedule the audit so the test, fixes and retest fall inside its examination period.

1 November 2026 · 11 min read · By Michael van Mameren, Lead Penetration Tester (OSCP)

Security audit vs penetration test: two different questions, two kinds of evidence, and how they fit in one annual cycle

An audit asks whether your controls exist and operate as designed. A penetration test asks whether an attacker gets through anyway. Organisations that confuse the two end up with a certificate and a breach, or with a stack of findings and no way to show a regulator what they did about them.

Talk to a security consultant

The short answer

A security audit is a formal, criteria-based examination of whether an organisation's security controls exist, are designed appropriately and operate effectively, measured against a standard such as ISO/IEC 27001, the AICPA Trust Services Criteria behind SOC 2, PCI DSS, or a legal regime such as NIS2 or DORA. It is performed by an auditor, works largely from documentation, interviews, configuration samples and evidence of operation, and results in an opinion, a certificate or a list of nonconformities. A penetration test is a time-boxed, authorised attack on a defined scope by qualified testers, who try to find and exploit vulnerabilities the way a real adversary would. It results in a report of what was found, how it was exploited, how severe it is in your context and how to fix it.

The two overlap in exactly one place: the audit asks for evidence that technical vulnerabilities are identified and managed, and the penetration test report is the strongest evidence you can hand over. Everywhere else they differ in question, method, performer, output and cadence. This guide sets out both, shows where each framework expects testing evidence, and gives a combined annual cycle that satisfies auditors without turning testing into paperwork.

What a security audit is: the four forms you will meet

The word 'audit' covers several distinct exercises. Which one your stakeholder means changes who performs it and what it produces.

ISO/IEC 27001 audit

Two kinds: the internal audit required by clause 9.2, performed by or for the organisation against its own ISMS, and the certification audit by an accredited certification body (stage 1 documentation review, stage 2 implementation audit, annual surveillance, recertification in year three). The output is a certificate with a scope statement plus nonconformities and observations. Annex A controls 8.8 and 8.29 are where testing evidence is examined.

SOC 2 examination

An attestation engagement by a licensed CPA firm under the AICPA attestation standards, against the Trust Services Criteria (Security, plus optional Availability, Processing Integrity, Confidentiality and Privacy). Type I covers design at a point in time; Type II covers operating effectiveness over a period, typically six to twelve months. The output is the auditor's opinion plus a system description. Penetration testing evidence supports criteria CC4.1 and CC7.1.

NIS2 supervisory audit

Under NIS2 (Directive (EU) 2022/2555) competent authorities may subject essential entities to regular and targeted security audits, on-site inspections and security scans (Article 32), and important entities to ex-post supervision (Article 33). In the Netherlands this runs through the Cyberbeveiligingswet with sector supervisors such as the Rijksinspectie Digitale Infrastructuur. The entity must show, under Article 21(2)(f), policies and procedures to assess the effectiveness of its risk-management measures; regular testing is how that is evidenced.

IT audit by a Register EDP-auditor or CISA

A broader assurance engagement on IT general controls by a certified IT auditor (an RE registered with NOREA, or a CISA under ISACA), often as part of the financial statement audit or as an ISAE 3402 or 3000 report for service organisations. It covers access, change, operations and continuity. Technical vulnerability management is one control area, and a current penetration test report is its standard evidence.

What a penetration test is

A penetration test is an authorised, scoped simulation of an attack performed by qualified testers against systems, applications, networks or people, within an agreed time window and rules of engagement. The method follows recognised standards (PTES, OWASP WSTG and MASTG, NIST SP 800-115): reconnaissance, vulnerability analysis, exploitation, post-exploitation and reporting. Unlike a vulnerability scan, it is manual and adversarial. Testers chain weaknesses, abuse business logic and move laterally, which is where the findings that matter to a board tend to sit.

The output is a report: an executive summary, a scope and methodology statement, findings scored for severity (CVSS, adjusted for your context) with reproducible evidence, an attack narrative showing how findings combine, and prioritised remediation. A retest confirms the fixes. The test tells you what an attacker could do today. It does not tell you whether your policies exist, whether your access reviews run every quarter, or whether your supplier contracts contain the right clauses. That is the auditor's territory.

Security audit vs penetration test, side by side

Seven dimensions on which the two instruments differ. The one place they meet is the evidence row.

Dimension	Security audit	Penetration test
Question answered	Do the required controls exist, are they designed correctly and did they operate as intended over the period?	Can an attacker, within this scope and time, compromise these systems, and what would the impact be?
Method	Document review, interviews, walkthroughs, sampling of evidence, configuration review against criteria	Hands-on adversarial testing: reconnaissance, exploitation, privilege escalation, lateral movement
Evidence produced	Audit trail of samples, interview notes, control test results, management representations	Reproducible exploitation evidence: screenshots, request and response pairs, proof of concept, access achieved
Who performs it	Internal auditor, accredited certification body, CPA firm, RE or CISA, or the supervisory authority	Certified penetration testers (OSCP, OSWE, CREST), independent of the system owners
Output	Opinion, certificate or attestation report; nonconformities, deviations, recommendations	Findings report with severity, attack narrative and remediation plan; retest confirmation
Frequency	Annual surveillance or examination period; internal audit per the audit plan; supervisory audits as scheduled or ad hoc	At least annually and after significant change (PCI DSS, DORA, most auditors); per release for critical applications
Cost driver	Size of the ISMS or system boundary, number of controls and locations, period length, auditor seniority	Scope breadth and depth (hosts, applications, roles), test type, tester seniority, reporting and retest

How penetration test evidence feeds the audit

Auditors do not perform penetration tests. They ask for evidence that you do, and that you act on the results. These are the clauses where the report is examined.

ISO/IEC 27001:2022, Annex A 8.8 and 8.29

Control 8.8 requires that information about technical vulnerabilities is obtained, exposure evaluated and appropriate measures taken; control 8.29 requires security testing in development and acceptance. Auditors expect a current penetration test report for in-scope systems, a documented risk evaluation per finding, remediation records and retest evidence. The clause 9.2 internal audit should check the same chain first.

SOC 2 Trust Services Criteria CC4.1 and CC7.1

CC4.1 requires ongoing and separate evaluations of whether controls are present and functioning; CC7.1 requires procedures to identify new vulnerabilities. The points of focus name penetration testing and vulnerability scanning explicitly. For a Type II report the auditor samples the examination period, so test and remediation must fall inside that window.

PCI DSS v4.0.1 Requirement 11.4

The most prescriptive of the four: internal and external penetration testing at least once every 12 months and after significant changes, by a qualified internal resource or qualified external third party with organisational independence, following an industry-accepted methodology, covering the cardholder data environment and the segmentation controls (11.4.5), with exploitable vulnerabilities corrected and retested (11.4.4). The Qualified Security Assessor checks the report against each sub-requirement for the Report on Compliance.

DORA Articles 24 to 27 and Article 6(6)

Article 25 lists penetration testing among the tests a resilience testing programme shall include; Article 24 requires annual testing of ICT systems behind critical or important functions; Articles 26 and 27 add threat-led penetration testing for designated entities. Article 6(6) requires regular internal audit of the ICT risk-management framework. The test reports are what internal audit and the supervisor (DNB or AFM in the Netherlands) will ask for.

GDPR Article 32(1)(d) and NIS2 Article 21(2)(f)

Both require a process for regularly testing, assessing and evaluating the effectiveness of security measures, without naming a method. Supervisors and data protection authorities accept penetration testing as the normal way to evidence this for technical measures. The audit checks that the process exists, runs on schedule and produces follow-up.

When you need which

Use the question you need answered to pick the instrument.

A customer, regulator or board asks for proof that your security programme is governed: you need an audit (ISO 27001 certification, a SOC 2 report or an ISAE assurance report).
You want to know whether a specific application, network or cloud environment can be compromised today: you need a penetration test.
You are preparing for certification or a SOC 2 examination: test first, so the report and remediation evidence exist when the auditor samples the period.
You are launching or materially changing a system: a penetration test before go-live. The audit will pick it up at the next cycle.
A supervisor announces a NIS2 or DORA inspection: both. Confirm your testing evidence is current, then prepare the governance documentation the inspector reads first.
You hold an audit certificate and have never tested: the certificate proves the process exists. The test tells you whether the process has been working.
You test every year and have never been audited: you know your vulnerabilities but cannot prove governance to a customer. An ISO 27001 or SOC 2 programme turns the testing into evidence.

A combined annual cycle that satisfies both

Sequence matters. Test before the audit samples the period, remediate before the auditor asks, and keep the two calendars on one page.

Quarter 1: scope and plan

Confirm the ISMS or system boundary with the audit owner, map every in-scope system to a test type and frequency (the expectation behind DORA Article 24 and ISO 27001 control 8.8), and schedule tests so reports land at least eight weeks before audit fieldwork.

Quarter 2: penetration testing

External and internal infrastructure tests, application tests for systems inside the audit boundary, cloud configuration review where relevant. Findings go into the risk register with owners and deadlines, the document the auditor traces from.

Quarter 3: remediation and retest

Fix, then retest medium and higher findings. The retest letter is what closes PCI DSS 11.4.4 and what ISO 27001 and SOC 2 auditors sample as evidence that the control operates, not merely exists.

Quarter 4: internal audit, then external audit or examination

Run the clause 9.2 internal audit against the chain from test to fix to retest, correct any process gaps, then present the full chain to the certification body, CPA firm or supervisor.

Continuous: change-triggered testing and scanning

Monthly or continuous vulnerability scanning and penetration tests tied to significant changes keep the evidence unbroken between cycles. Document what counts as significant; the auditor will ask.

Common misunderstandings

'We are ISO 27001 certified, so we are secure.' The certificate proves that a management system exists and was audited on sampled evidence. Certification bodies do not exploit your systems. Organisations with current certificates are breached regularly through vulnerabilities that an afternoon of testing would have found. 'We had a pentest, so we will pass the audit.' A test report covers one scope at one moment; the auditor also needs the policy, the risk evaluation, the remediation records and the retest. 'A vulnerability scan is a pentest.' It is not, and PCI DSS v4.0.1 separates them into Requirements 11.3 and 11.4 for that reason.

'The auditor will do the pentest.' Auditors assess independence carefully. The body that certifies you should not also be the firm whose test results it is certifying, and under the AICPA independence rules a CPA firm cannot attest to its own work. 'Once a year is enough.' Once a year is the floor the frameworks set. Systems that change weekly need testing tied to releases, and the audit will ask how you concluded that annual was sufficient.

Where HackersHub fits

HackersHub performs the penetration testing side and writes the report so that it slots into the audit: a scope and methodology statement, findings mapped to the control they evidence (ISO 27001 A.8.8, SOC 2 CC7.1, PCI DSS 11.4, DORA Article 25), reproducible evidence, and a verification retest of medium and higher findings within 90 days so the remediation chain is complete when the auditor samples it. Our security consulting practice aligns the testing calendar with your certification or examination cycle and prepares the governance evidence an auditor or supervisor reads first.

We do not issue ISO 27001 certificates or SOC 2 opinions. Those belong with an accredited certification body or a CPA firm, and keeping the roles separate is what makes the evidence credible. Every HackersHub tester holds at least the OSCP, with OSWE and CREST-certified testers on the team, and Michael van Mameren, Lead Penetration Tester (OSCP), signs off every report.

Frequently asked questions

Related guides

Aligning your testing calendar with your audit?

We test to the control, report to the auditor's expectations and retest within 90 days so the evidence chain is complete when it is sampled. Talk to an expert.

Talk to a security consultant Contact us