Penetration testing vs security audit: which one your organization needs first
When a SOC 2, ISO 27001 or regulator request lands, the first decision is whether you need proof that a control works or proof that an attacker cannot get in. A penetration test proves exploitability against defined targets: a tester attempts real attacks, documents what succeeds and shows the impact. An audit or attestation does something different. It checks controls against a set of criteria and issues an opinion. A SOC 2 examination is performed by a CPA under AT-C section 205, a Type 1 report covers control design as of a date, and a Type 2 report adds an opinion on operating effectiveness over a period. An ISO 27001 certificate comes from an accredited certification body, not from the testing firm you hired.
Buy the audit first when the request names a report or certificate, such as a SOC 2 Type 2 report for customer due diligence or ISO 27001 certification for a tender. An auditor will test whether your access reviews, change records and vulnerability management process operate as described, and will not accept a penetration test as a substitute for those records. Buy the penetration test first when you have no idea how exposed your internet-facing systems are, or when the regulator or the auditor asks for technical validation of specific risks. Before you sign anything, ask the auditor which evidence they expect, and check whether ISO/IEC 27001:2022 control A.8.8 (management of technical vulnerabilities) is in scope, since that is where test results usually land.
Neither replaces the other, and many organizations need both. The test finds weaknesses that the audit may not sample, and the audit checks that the organization finds and fixes weaknesses on a repeatable schedule. Ask the auditor whether a penetration test report can be used as evidence and for which criteria, and ask the testing provider whether its report states scope, dates, methods and retest results in a form the auditor can read. Confirm both points in writing before the engagement starts, because a report that is technically strong but scoped to the wrong systems will not satisfy the auditor.
How penetration testing and a security audit differ on the factors that matter to buyers
This table compares a penetration test and a security audit on goal, question answered, performer, scope, method, independence, output and evidentiary use. Read it to decide which one answers your question, and note that many buyers need both because they answer different questions.
| Factor | Penetration test | Security audit |
|---|---|---|
| Goal | Find and validate exploitable weaknesses in defined targets by attempting real attacks | Check whether controls exist, are designed correctly and operate as described against stated criteria |
| Question answered | Can a tester get past these controls on these targets, and how far can they go? | Do the controls meet the criteria, and can the organization show they worked over the period? |
| Who performs it | Security testers, internal or third party, with skills the scope requires | A CPA firm for a SOC 2 examination, an accredited certification body for ISO 27001, or internal audit staff for internal audits |
| Scope | Named hosts, applications, accounts or networks agreed in a rules of engagement | Trust services categories, Annex A controls or internal audit objectives defined by the criteria or charter |
| Method | Reconnaissance, exploitation and post-exploitation, usually with manual work; NIST SP 800-115 treats it as a target validation technique | Inquiry, inspection of documents and samples, observation and reperformance of controls |
| Independence requirements | Depends on the program: some frameworks require an independent tester, and the buyer should confirm the requirement with the framework owner | The auditor must be independent of the audited organization under the rules that govern the attestation or certification |
| Output | Findings with evidence of exploitation, risk ratings and remediation guidance; a report of tested scope, not a pass or fail verdict | An opinion or certificate: a SOC 2 report with a Type 1 or Type 2 opinion, or an ISO 27001 certificate issued by an accredited body |
| How the result is used as evidence | Can support a control or requirement as direct testing evidence where the framework accepts it, such as HITRUST's treatment of penetration test reports | Is the evidence itself. Auditors rely on it for the opinion and may still request test reports as supporting evidence |
Which approach a SOC 2, ISO 27001 or regulated buyer should commission
A SOC 2 examination is an assertion-based engagement performed by a CPA under AT-C section 205 of the AICPA attestation standards. A Type 1 report describes whether controls are designed as of a specific date, while a Type 2 report adds the CPA's opinion on whether those controls operated effectively over a period. The auditor does not run an attack, so the question is whether your penetration test evidence supports the controls being examined.
- Type 1 scope: Expect a point-in-time view of control design. A recent penetration test report may support the design of vulnerability management controls, but it does not prove operation over time.
- Type 2 scope: Expect the auditor to sample test activity across the period. Dated reports, scope statements and remediation tracking records are what make the evidence usable.
- Scope alignment: Confirm that the systems in the test match the system description and the services in the examination boundary.
- Tester documentation: Ask whether the report identifies the testers, methods and findings in enough detail for an auditor to trace remediation.
- Management representation: Management's written representations about control operation are a separate artifact. The test report is one input to them, not a substitute.
Confirm with your CPA firm which trust services criteria apply and what sampling evidence it expects for penetration tests before you commission the work.
ISO does not certify organizations. Accredited ISMS certification bodies do, and they operate to ISO/IEC 17021-1:2015 together with ISO/IEC 27006-1:2024, which IAF MD 29:2024 required them to apply to all clients by 31 March 2026. For vulnerability management, Annex A control A.8.8 asks the organization to obtain information about technical vulnerabilities, evaluate its exposure and take appropriate measures. CIS maps its external penetration testing safeguard 18.2 to A.8.8, which is why testers often end up in certification discussions.
- Accredited body: Confirm that the certification body holds accreditation for the scope you need and ask how it treats penetration test evidence.
- Control mapping: Map each test to A.8.8 and record how exposure was evaluated and what action followed.
- Surveillance visits: Expect the certification body to look for ongoing evidence between audits, not only a report at certification time.
- Statement of applicability: Make sure the scope of testing matches the controls you claim as implemented.
- Remediation records: Keep proof that findings were prioritized, fixed or accepted through a documented decision.
Ask the certification body, in writing, what form of penetration test evidence it accepts and how it expects the test to be scoped.
For financial entities in the EU, DORA Article 25(1) lists testing tools that include vulnerability assessments and scans, open source analyses, source code reviews where feasible, scenario-based tests and penetration testing. Article 26 requires threat-led penetration testing at least every 3 years for entities identified by their competent authority. TIBER-EU, dated January 2025, runs threat intelligence-based red team tests and states that these tests produce no pass or fail result, so a regulator-led exercise is not an audit outcome.
- Competent authority: Confirm with your supervisor whether you are in scope for threat-led testing and how often it applies to you.
- Test type: A DORA penetration test and a TIBER-EU exercise differ in method, team and closure, so state which one you are buying.
- Evidence form: Expect a regulator to read reports for findings, remediation and lessons, not for a certificate.
- Testing provider: Ask the authority which provider criteria it applies before you select a firm.
- Timeline and governance: Agree in writing who approves scope, who receives results and how remediation is tracked.
Confirm the program requirements, the authority's expectations and any provider rules directly with your competent authority before you commission work.
An internal audit or risk-driven program asks a different question from an external attestation. Internal audit checks whether controls are in place and working against your own policies, while a risk assessment decides where exposure matters most. NIST SP 800-115 classes documentation review, log review, ruleset review and system configuration review as passive review techniques, separate from target vulnerability validation techniques such as penetration testing. Both kinds of work are useful, and they produce different evidence.
- Passive review: Documentation, log, ruleset and configuration reviews show what controls were defined and configured.
- Active validation: Penetration tests show whether a weakness can be exploited, which a review alone cannot demonstrate.
- HITRUST context: The HITRUST Assessment Handbook v1.2 treats penetration test reports as evidence for direct testing of requirement statements, so a test can satisfy part of a HITRUST assessment.
- Risk linkage: Tie each test to a documented risk so the internal audit committee can see why the scope was chosen.
- Independence: Decide whether internal staff or an outside firm will test, and record how that choice affects the objectivity of results.
Confirm with your internal audit function which control objectives it will sample and whether it will accept penetration test reports as evidence.
What a penetration test finds and misses, and what an audit finds and misses
A penetration test proves that specific weaknesses can be exploited, while an audit tests whether controls are designed and operating as claimed. NIST SP 800-115 separates passive review techniques from target vulnerability validation, and the gaps each method leaves are different.
Exploitable weaknesses and attack paths
A penetration test shows that a weakness can be used against a defined target, and it can chain several small issues into a route to data or administrative access. NIST SP 800-115 places penetration testing under target vulnerability validation, where real exploits run against systems in scope. Check the rules of engagement, the access the testers started with, and whether the report lists the attack path step by step so that retesting after fixes is possible.
Configuration and design gaps
A penetration test samples the paths testers chose during the engagement window, so a misconfigured setting or a weak design decision that was not reached can stay hidden. Design flaws in workflows, such as approval logic or tenant isolation, often need reviewer judgment rather than an exploit. Ask the provider which systems were excluded, which roles were tested, and whether configuration reviews were run alongside the test.
Control design and operating gaps
An audit examines whether controls are designed to meet the criteria and, for a Type 2 SOC 2 examination, whether they operated over a period. Findings often concern missing approvals, late access reviews, or change records that do not match policy. Auditors use documentation review, log review and configuration review, which NIST SP 800-115 classes as passive review techniques. Ask which control owners were interviewed and what evidence the auditor sampled.
What an audit sample will not reveal
An auditor tests a sample of items, such as a few change tickets or user access reviews, so a control that failed on unsampled items may not appear in the report. Exploitable flaws in code or hosts are generally outside an audit's technical depth. A clean report therefore does not show that a specific vulnerability is absent. Ask which periods and populations were sampled and whether exceptions were noted in the report.
A clean test is not a clean environment
A penetration test with no critical findings only shows that the testers did not succeed within their scope, time and access. It says nothing about controls that were never exercised, such as incident response or detection coverage. The same caution applies to a passing audit opinion, which does not validate the technical depth of a single system. Ask what the test did not attempt and which controls remain unverified before reading a clean result as assurance.
Where a penetration test report serves as audit evidence
An auditor may accept a penetration test report as evidence for a testing or vulnerability management control, but only as one input to that control. The auditor still evaluates the control itself: whether the organization has a defined testing program, acts on findings and can show that it did. For ISO/IEC 27001:2022, the relevant anchor is Annex A control A.8.8, which asks the organization to obtain information about technical vulnerabilities, evaluate its exposure and take appropriate measures. The CIS Controls mapping links its external penetration testing safeguard, 18.2, to A.8.8, which is why many ISMS teams point auditors to a recent external test when they discuss that control. Before scoping any engagement, confirm with your certification body or the auditor how they will treat a penetration test report for A.8.8 and what they expect it to contain. Confirm this in writing, not in a kickoff call.
Four attributes decide whether a report helps or gets questioned. The first is scope: the report must name the systems, applications, networks and environments tested, so the auditor can match them to the in-scope systems of the ISMS or the service description in a SOC 2 examination. A report on a public marketing site does not cover a payment API. The second is dates: the auditor needs the test window and must judge whether it falls within the audit period or the interval the organization claims. The third is findings status: an open critical finding with no remediation plan is evidence of a gap, not of control. The fourth is retesting, which shows that the organization validated fixes. Ask the testing provider to state the methodology used and whether testing was manual, automated or both, since an automated scan alone is weaker evidence for an exploitation-based test.
Use the report to show the control operating, not to close the audit question. For a SOC 2 Type 2 examination, a penetration test over the period supports the testing criteria but the CPA still tests how the organization identifies, tracks and remediates vulnerabilities across the whole period. For HITRUST, the HITRUST Assessment Handbook v1.2 treats penetration test reports as evidence for direct testing of requirement statements, yet the assessor still checks the requirement. Plan the remediation tracker, risk acceptance records and retest evidence alongside the report, because those documents answer the questions a report cannot. Illustrative example: a report dated before a major release, with no record of retest, may cover the old system but not the one under audit. Ask your auditor which artifacts they will sample before the test is scheduled.
What you receive from each approach
This table compares the artifacts each approach produces, from a penetration test report to an audit opinion or certificate. Read it to see who issues each document, what it proves, and what it cannot prove on its own. DeployOpen prepares systems and evidence for these assessments but does not issue audit reports, attestations or certifications; the auditor or certification body does.
| Deliverable | Penetration test | Audit or attestation |
|---|---|---|
| Core output | Findings with reproduction steps, a risk rating for each finding and retest results after fixes | An opinion or decision on whether controls meet defined criteria, issued by the independent auditor or certification body |
| Who issues it | The testing provider that performed the work, under the rules of engagement agreed beforehand | A CPA firm for a SOC 2 report, an accredited ISMS certification body for ISO 27001, and internal audit for an internal audit report |
| What it describes | What was tested, the access used, the techniques attempted and what was exploited or not exploited | For SOC 2, a description of the system and the controls tested; for ISO 27001, the scope of the ISMS and the certification decision |
| Management response | Remediation actions are recorded against each finding, usually tracked by the client after the report | Management provides a written response and representations; internal audit reports include management action plans with owners |
| Time dimension | A snapshot of the target at test time, with retest results confirming whether fixes worked | A SOC 2 Type 1 covers control design as of a date; a Type 2 covers operating effectiveness over a period |
| Evidence use by others | Often submitted to assessors as evidence for vulnerability and testing requirements | Often shared with customers, partners or regulators as a third-party assurance statement |
| What it cannot prove alone | That all controls work, that policies exist or that the organization is certified | That no exploitable weakness exists at the time of testing |
What drives cost and effort in each approach
A SOC 2 examination, an ISO 27001 certification audit and a penetration test are bought from different people for different outputs, so their costs move for different reasons. The cards below separate the drivers and name who is paid for each, so you can read a written quote against the work it actually covers.
Scope breadth and system count
Auditors price the number of systems, locations and services inside the defined boundary, while testers price the number of targets, applications and roles they must exercise. Each adds sampling, fieldwork and reporting time. Ask the quote to list every system in scope by name, the number of in-scope applications, and whether the boundary is the same for the audit and the test. A narrower boundary that is documented up front usually keeps both fees easier to compare.
Depth of controls evaluated
A SOC 2 examination tests the controls mapped to the Trust Services Criteria you select, and an ISO 27001 certification audit tests the controls in your Statement of Applicability. A penetration test instead measures how far an attacker can get against defined targets. Deeper control testing means more samples and more evidence reviewed. Ask which criteria or Annex A controls are included, and whether the test scope covers exploitation or only assessment.
Type 1 versus Type 2 observation period
A Type 1 SOC 2 report covers control design at a point in time, while a Type 2 report adds an opinion on operating effectiveness across a period. The longer observation window means more evidence collection and more auditor sampling, so Type 2 work recurs across the period and not only at the report date. Ask the quote to state the observation window, the sampling approach, and what the fee covers if the auditor finds an exception and extends testing.
Readiness of documentation and evidence
Auditors and testers spend less time on engagements where policies, asset inventories, change records and access reviews already exist and match how systems run. Missing or inconsistent evidence drives extra requests and follow-up, which is billed time. Ask who prepares the evidence package, whether readiness work is priced separately from the audit, and how the auditor expects population lists and screenshots to be delivered.
Retesting and remediation cycles
A penetration test finding often needs a retest after the fix, and that retest is usually a separate line item. In an ISO 27001 cycle, the vulnerability management control A.8.8 is checked again at each surveillance or recertification visit, so evidence of remediation recurs. Ask whether one retest round is included, how many findings are covered, and whether retesting is priced as a fixed fee or as time and materials.
Tester independence and who pays
Auditors must be independent of the organization they assess, and a penetration tester whose findings feed an audit should not also design the fixes they then validate. Independence can raise cost because it limits who you can hire and may require separate firms for the test and the audit. Ask who is paid for each engagement, whether the same firm is proposed for both, and how the quote documents independence for the auditor.
Questions buyers ask before choosing between a penetration test and an audit
Does a penetration test satisfy SOC 2 or ISO 27001 on its own?
No. A penetration test is technical evidence that specific weaknesses can or cannot be exploited at a point in time. A SOC 2 examination is an assertion-based attestation performed by a CPA under AT-C section 205, and an ISO 27001 certification comes from an accredited certification body, not from ISO itself. Auditors assess whether controls are designed and operating against defined criteria. A penetration test report can support that work as one piece of evidence, for example for vulnerability management, but the auditor decides what it proves. Confirm with your auditor or certification body which evidence they will accept and how they want it packaged.
What does a SOC 2 Type 2 examination need from our organization?
A Type 2 report needs the organization to describe its system and controls, provide management's written assertions, and make evidence available for an operating period, not a single date. A Type 1 report covers control design as of one date, while a Type 2 report adds the CPA's opinion on operating effectiveness over a period. Expect requests for policies, change records, access reviews, incident tickets and vulnerability management records across that period. Penetration test reports, remediation tracking and retest evidence are common inputs for the vulnerability and security criteria. Ask the CPA which Trust Services Criteria apply and which samples they will pull.
Can our internal team run the penetration test that an audit will rely on?
It depends on what the auditor and any contract require. NIST SP 800-53 control CA-8 has an enhancement for an independent penetration testing agent or team, and DORA and PCI DSS expect independence in some contexts. Where independence is not required, an internal team can produce useful results, but the auditor will judge the tester's independence, skill and documentation. Internal testers also tend to share assumptions with the systems' builders. Confirm the independence rules in your target framework before deciding who tests, and keep the rules of engagement and test records in a form an auditor can read.
How long does preparation take, and what does it demand from our staff?
No supplied source gives a duration for preparing an audit or a penetration test, so confirm timelines in writing with the auditor and the testing provider. Work is driven by how many systems are in scope, how current the asset inventory is, whether evidence already exists, and how quickly staff can answer questions. Typical staff demands include a named owner for each control, access to logs and configuration records, a contact for rules of engagement, and time to fix and retest findings. For a SOC 2 Type 2, the operating period itself sets a minimum timeline because evidence must exist for the whole period.
What does the auditor need from us that a penetration test provider does not supply?
The auditor needs a control narrative, evidence of operation over time, and proof that findings were tracked to closure. A penetration test provider supplies an exploitation report for a defined scope. Auditors commonly ask for the scope document, the dates of testing, the tester's qualifications, the list of systems covered, remediation tickets and retest results. Map each framework requirement to the evidence you hold, and confirm with the auditor whether a test report from a given date is sufficient or whether they expect a more recent one.
What should we ask a provider to put in a written scope?
A written scope should state the targets by name or address range, the testing viewpoint, whether testing is authenticated, whether production systems are included, the testing window, the testers' qualifications, the rules of engagement and the contact for emergencies. It should also list what is out of scope and what the deliverables are, including the report format and retest terms. Ask how findings will be mapped to the framework requirements you need to evidence. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and its quotes follow from that written scope. Ask any provider to show a sample report and to confirm which framework citations it covers.
Can a penetration test replace an internal audit?
No. An internal audit checks whether the organization's own processes and controls work as designed, including governance, policy adherence and evidence handling. A penetration test checks whether technical defenses can be defeated for a defined target. NIST SP 800-115 treats review techniques, such as documentation and configuration review, as distinct from target vulnerability validation such as penetration testing, and the two are often combined. Use the penetration test to inform the audit's technical sections, and let the audit cover the processes that surround the findings.
How to combine a penetration test and an audit in one year
This sequence lets one year's penetration test feed the audit as evidence of technical testing, while the audit confirms that controls operate as described. Confirm the exact timing and evidence expectations with your auditor before you fix dates.
Confirm frameworks and criteria with auditors
Ask your SOC 2 CPA firm, ISO 27001 certification body or internal audit function which criteria, Annex A controls or internal control objectives the audit will cover, and whether they will accept penetration test reports as evidence for any of them. Record the answers in writing, including the audit period or Type 1 date and the evidence format they expect. The step is done when the auditor's expectations are on file and the penetration test scope can be traced back to specific controls.
Define the in-scope systems
Work with the control owners to list the systems, applications, APIs, cloud accounts and network segments that sit inside the audit boundary, then match that list to the penetration test scope. Where the auditor treats an item as in scope but the test does not include it, either extend the test or document why the gap is acceptable. The output is a single scope register that both the tester and the auditor can read, signed off by the system owners.
Schedule the penetration test ahead of the audit window
Agree a test date that falls early enough in the audit period that findings and fixes can be retested before the audit ends. Put the rules of engagement, testing windows and any production safeguards in writing with the tester. Confirm with your auditor whether a test performed during the period, or shortly before it, is the one they will rely on. The step is complete when the test date, scope and rules of engagement are approved and the auditor has acknowledged the schedule.
Run the test and triage the findings
The testing provider executes the agreed scope and delivers a report that lists each finding with its affected system, severity rationale, reproduction steps and recommended remediation. Your security team confirms which findings are valid, assigns owners and sets remediation targets. Keep the report unedited for evidence purposes, since auditors compare it with the scope. The step closes when every finding has an owner and a tracked remediation item.
Collect remediation evidence for each finding
For each closed finding, gather the change record, configuration change, patch reference or code commit that shows the fix, along with the date it was applied. Where a finding is accepted as a risk, record the approval, the compensating control and the review date. Auditors who test operating effectiveness will look for this trail, so store it alongside the original report. The step is done when every finding has either a fix record or a signed risk acceptance.
Retest the remediated findings
Have the tester, or an independent team if your auditor requires it, verify that the fixes work and that the affected systems still meet the test's acceptance criteria. Record the retest date, the method and the result for each item. A retest confirms the fix, but it does not replace evidence that the underlying control operates over the audit period. The step is complete when the retest report shows each finding as resolved or formally accepted.
Hand the scope and results to the auditor
Provide the auditor with the scope register, the final penetration test report, the retest report and the remediation evidence in the format agreed in the first step. Explain how each report maps to the criteria or controls it supports, and note which parts of the audit rely on other evidence, such as configuration reviews or access logs. Ask the auditor to confirm receipt and any open questions. The step closes when the auditor has accepted the package or listed the items still needed.
How DeployOpen scopes and delivers penetration testing and audit readiness
DeployOpen runs security testing and prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. We keep the two lanes separate: a penetration test produces technical findings, while an independent auditor or certification body decides whether controls meet a criteria set.
How we scope
- Engagements are fixed-scope, with targets, deliverables and timelines agreed in writing before work starts.
- The written scope states which systems, environments and access levels the penetration test covers, and which the audit readiness work covers.
- Scope also states which evidence an independent auditor will need, so test reports are written to be usable in that review.
How we build
- Testing runs against your own infrastructure, including your cloud accounts, data centers or air-gapped networks.
- Test accounts, rules of engagement and testing windows are set up with your team before any exploitation begins.
- Control evidence is organized against the criteria your auditor uses, so gaps are visible before the assessment starts.
How we hand over
- Deliverables include a penetration test report with reproducible findings, validated risks and recommended remediation steps.
- Documentation covers the controls prepared, the evidence collected and the open items your auditor should review.
- Retest results are documented so you can show which findings were closed and how each fix was verified.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope work.
- Retainers can cover periodic retesting after remediation or refreshed evidence before a scheduled audit period.
- Ask your auditor which evidence they accept from a penetration test before agreeing on the retainer's scope.
