By requirement
One test, many audits
Most organisations answer to several frameworks that each want evidence of security testing. We scope one annual test so its report, control mapping and retest letter serve each audit, and flag where dedicated scope is unavoidable.
What it asks for
What these frameworks ask of security testing
They do not all ask for the same thing. ISO 27001 and SOC 2 do not mandate a penetration test, yet expect evidence that technical vulnerabilities are managed and controls are evaluated. PCI DSS is prescriptive: internal and external tests at least every 12 months and after significant change, plus segmentation testing. DORA requires yearly testing of systems supporting critical or important functions, and threat-led testing for identified entities. NIS2 asks entities to assess whether their risk-management measures are effective.
The overlap is large enough that one well-scoped test can serve several audits. A single methodology, a scope covering the union of in-scope systems, findings mapped to each framework's controls and a retest letter give every reviewer something concrete. It is not a guarantee: each auditor, QSA or supervisor decides what they accept, and some activities, such as PCI DSS segmentation testing or DORA TLPT, have rules of their own that may need dedicated scope.
ISO/IEC 27001:2022, Annex A 8.8 and 8.29
Penetration testing is not mandated, but where the controls on managing technical vulnerabilities and on security testing in development and acceptance are selected, you need to show they operate. An independent test with tracked remediation is a common way to evidence them; the certification body decides what it accepts.
SOC 2, CC4.1, CC7.1 and CC4.2
Not explicitly mandated. A CC4.1 point of focus names penetration testing as an evaluation type; CC7.1 covers detecting vulnerabilities and CC4.2 timely correction of deficiencies. The CPA firm judges whether the test supports your described controls.
PCI DSS v4.0.1, Requirement 11.4
Explicit. A documented methodology, internal and external tests at least every 12 months and after significant change, retesting of corrected findings, and segmentation testing where segmentation reduces scope, every six months for service providers.
DORA, Regulation (EU) 2022/2554, Articles 24 to 26
A risk-based testing programme run by independent testers, with appropriate tests at least yearly on ICT systems supporting critical or important functions. Penetration testing is among the listed tests; identified entities also need TLPT at least every three years.
NIS2, Directive (EU) 2022/2555, Article 21
Measures must include policies and procedures to assess the effectiveness of cybersecurity risk management. For certain digital providers, Implementing Regulation (EU) 2024/2690 adds a risk-based security testing policy with documented methodology, results and mitigations.
Customer security questionnaires
Not a framework, but often the most frequent request: evidence of an independent test within the last year, its scope, and confirmation that high-risk findings were fixed. A shareable summary and retest letter usually answer it.
What to test
Scoping one test for several audits
Build the union of scopes
List what each framework covers: the ISMS scope, the SOC 2 system description, the cardholder data environment and the ICT systems supporting critical or important functions. The test scope is the union, with each target tagged to the frameworks it serves.
Apply the strictest rule
Where requirements differ, adopt the strictest: PCI DSS methodology elements, organisational independence of testers, testing after significant change and retention of results. Meeting the strict version usually satisfies the lighter ones.
Fit the audit calendar
Place fieldwork so results and retests fall inside the SOC 2 Type 2 period, ahead of the ISO surveillance audit and within the PCI DSS 12-month window. One date rarely suits everything, so we agree priorities first.
Carve out what needs its own test
PCI DSS segmentation testing, the six-monthly service-provider cycle and DORA TLPT follow their own frequency and process. We identify these at the outset and scope them separately rather than stretching the annual test.
What you receive
One evidence pack, many readers
Technical report
Methodology, scope, dates, tester independence and detailed findings with exploitation evidence and remediation guidance, written to stand on its own for an auditor, QSA or supervisor who did not attend the test.
Control mapping appendix
Each finding and test activity mapped to the relevant control in each framework, such as Annex A 8.8, CC7.1, PCI DSS 11.4 or DORA Article 25. The mapping is guidance; each auditor reaches their own view.
Retest letter
A dated letter confirming which findings were retested and verified as resolved. It supports PCI DSS 11.4.4, SOC 2 CC4.2, DORA's requirement to remedy issues found in testing, and the question customers ask most.
Shareable summary
An executive summary or attestation letter for customers and partners, confirming an independent test took place and outlining scope and outcome without exposing exploitable detail.
Common pitfalls
Where combined testing falls short
Mistakes that cost time at audit, and how to avoid them.
Assuming acceptance
An evidence pack built for several frameworks still has to satisfy each reviewer separately. Agree in advance with your auditor, QSA or supervisor that the scope and methodology meet their expectations.
Scope drift between audits
A test scoped to the ISO certificate boundary may miss part of the cardholder data environment or a SOC 2 system component. Mismatched scope is the usual reason combined evidence is challenged.
Treating the annual test as TLPT
DORA TLPT is threat-led, runs on live production systems, has its scope validated by the competent authority and follows its own process. A standard annual penetration test does not substitute for it.
Ignoring change-driven testing
PCI DSS requires testing after significant infrastructure or application changes, not only once a year. A single annual test leaves gaps if a major release or migration follows it.
Who decides what counts
PXL Security is an independent offensive-security firm, not an auditor, assessor, certification body or regulator. We deliver the testing and the evidence; your auditor, assessor or competent authority decides what they accept. This page is general guidance, not legal advice.
FAQ
Questions we're often asked
Can one penetration test really satisfy several audits?
Often, for the core annual test, because the frameworks overlap heavily on what they want to see. It works when the scope covers every framework's systems and the methodology meets the strictest requirement. Each auditor or assessor still decides for themselves what they accept.
Will our QSA accept a test also used for ISO 27001 and SOC 2?
Reuse is common, but the test has to meet PCI DSS Requirement 11.4 on its own terms, including methodology, coverage of the cardholder data environment and tester independence. Segmentation testing may need its own scope and, for service providers, a six-monthly cycle. Confirm with your QSA.
Does this replace DORA threat-led penetration testing?
No. TLPT applies to financial entities identified by their competent authority, at least every three years, on live production systems with a scope validated by the authority. It follows a dedicated threat-led process. The annual multi-framework test supports the wider DORA testing programme, not TLPT.
Is PXL Security the auditor?
No. PXL Security is an offensive security firm. We are not a CPA firm, certification body, QSA or supervisor, and we do not issue SOC 2 reports, ISO certificates or compliance attestations. We provide independent testing evidence for those who do.
How do you handle different audit dates?
We map each audit window first, then place the test and retest where they serve the most important deadlines. Where dates conflict, a smaller targeted test or retest later in the year can fill the gap.
Is this compliance advice?
No. This page is general guidance based on the published frameworks and common audit practice. Requirements change and interpretation varies, so confirm scope and evidence with your auditors, assessors and regulators.
Services that deliver this
Scope your Multi-framework test.
Send a short description of your environment and goals. A senior tester, not a salesperson, will reply with questions, a proposed approach and a quote.