Attaining ISO 27001 certification is a significant milestone for organizations, demonstrating that their information security management system (ISMS) has been independently assessed against the standard's requirements. As part of the certification process, organizations undergo a thorough audit, where an impartial third-party assessor evaluates the ISMS against the established criteria.
During the assessment, the auditor scrutinizes the organization's policies, procedures, and controls, as well as its risk evaluation and risk mitigation strategies, ensuring they align with the standard's requirements. Penetration testing and vulnerability scanning can provide technical evidence for that assessment, but neither is explicitly mandated by ISO 27001:2022.
This article examines ISO 27001 penetration testing requirements, the Annex A controls these assessments support, and how their findings contribute to risk treatment and audit evidence. If you're planning an engagement and need guidance on scope, methods, cost and choosing a provider, read our ISO 27001 penetration testing guide.
ISO 27001:2022 in 2026: the transition is complete
ISO/IEC 27001:2022 replaced the 2013 edition in October 2022. Organizations had a three-year transition period, which ended on October 31, 2025. Certificates issued against ISO 27001:2013 are no longer valid, so every certification and surveillance audit now runs against the 2022 edition and its 93 Annex A controls. Amendment 1 (2024) added climate change considerations to clauses 4.1 and 4.2; it did not change the testing-related controls.
ISO/IEC 27001 is the requirements standard for an information security management system (ISMS), and it is the one you certify against. ISO/IEC 27000 is the overview and vocabulary standard, and ISO/IEC 27002 is the guidance on implementing the Annex A controls.
Is penetration testing required for ISO 27001?
Penetration testing is not explicitly required for ISO 27001 compliance. Nonetheless, organizations can incorporate penetration testing into their ongoing risk assessment, internal audit, and risk management procedures. The standard follows a risk management methodology: organizations identify, assess, and prioritize risks to sensitive data, then select controls to reduce those risks to an acceptable level. Clauses 6.1.2 and 6.1.3 govern risk assessment and risk treatment, with control choices justified in the Statement of Applicability.
ISO 27001 penetration testing detects security vulnerabilities and assesses the practical likelihood of different attack scenarios. Conducting technical security evaluations enables organizations to gauge the effectiveness of their security controls in detecting and thwarting attacks. A web application assessment can reveal security issues that could lead to data breaches, including weaknesses in business logic or authorization. ISO/IEC 27002 lists penetration testing and vulnerability assessments among the ways to identify vulnerabilities. The decision to commission a pentest, or use an alternative assessment, should be documented in the risk assessment process.
For examples of the weaknesses these assessments uncover, see our analysis of common ISO 27001 penetration testing findings.
Which Annex A controls address technical vulnerabilities?
The 2022 edition reorganized Annex A into four themes and renumbered every control. The table below maps the information security controls that a penetration test can support, with the 2013 numbers for reference if your older policies still use them.
ISO 27001:2022 control | What it requires | How a pentest supports it | 2013 equivalent |
|---|---|---|---|
A.8.8 Management of technical vulnerabilities | Obtain information about technical vulnerabilities in information systems, evaluate your exposure, and take appropriate measures | Identifies exploitable vulnerabilities and rates their risk, feeding your vulnerability management and risk treatment plan | A.12.6.1 (and A.18.2.3) |
A.8.29 Security testing in development and acceptance | Define and implement security testing processes in the development life cycle | Tests new systems, major releases and changes before or after go-live | A.14.2.8 and A.14.2.9 |
A.5.35 Independent review of information security | Review your approach to information security independently at planned intervals and after significant changes | Provides an independent technical view of whether controls hold up against attack | A.18.2.1 |
A.8.34 Protection of information systems during audit testing | Plan and agree audit tests on operational systems | Sets the rules for the pentest itself: authorization, scope, timing and safeguards for production | A.12.7.1 |
Results also feed clause 9.1 (monitoring, measurement, analysis and evaluation) and clause 10 (continual improvement), because they show whether your security controls are effective and where to improve them.
Does ISO 27001 require vulnerability scanning?
Not explicitly either. Control A.8.8 requires timely information about technical vulnerabilities. Regular automated vulnerability scanning of external IP addresses, internal networks and web applications is a common way to support this control. Scanning and penetration testing do different jobs:
Vulnerability scanning is automated, frequent and broad. A security scan finds known security flaws such as missing patches and outdated operating systems. Vulnerability analysis adds validation and prioritization of such vulnerabilities, helping teams select appropriate security measures.
Penetration testing is periodic and in-depth, combining expert-led investigation with automated tools and AI assistance where useful. Pentesters validate the results, chain weaknesses, examine business logic and access controls, and show which security vulnerabilities are actually exploitable, including SQL injection, broken authorization and encryption flaws that scanners can miss.
Penetration testing fits alongside ongoing vulnerability management. Most ISO 27001 programs use both a vulnerability assessment and a pen test: scans to keep up with new and emerging threats between tests, and pentests to validate that the controls work against a real attacker. For a closer comparison, see penetration testing vs. vulnerability scanning.
What should an ISO 27001 penetration test cover?
The scope should follow your ISMS scope, security objectives and risk assessment. Test the systems that store or process the information your ISMS protects, and the paths an attacker would use to reach them. In complex systems, scope should account for dependencies between applications, identities and infrastructure. Typical targets include:
Web applications and APIs that handle customer or sensitive data, including bespoke web applications where business logic and authorization affect data security
External network: internet-facing services, external IP addresses and other exposed network assets
Internal network, including wireless and guest networks, wireless devices and segmentation between them
Cloud environments: identities, permissions and exposed services
Mobile applications and their backend APIs, if they are in ISMS scope
Agree the rules of engagement before testing begins, as control A.8.34 requires, and record any systems you exclude and why. For scoping detail, testing time and cost, see our ISO 27001 penetration testing guide.
How often should you run an ISO 27001 penetration test?
ISO 27001 doesn't set a penetration testing frequency. The frequency of penetration tests should reflect risk and significant changes to the target system. Our recommendation, and common best practice:
Penetration testing: conduct penetration testing at least once a year for in-scope systems, and after significant changes such as a major release, new infrastructure or a cloud migration
Vulnerability scanning: continuously or at least monthly for internet-facing assets, as defined in your vulnerability management procedure
Retesting: after remediation, to confirm that fixes for high and critical findings work
The frequency of ISO 27001 penetration testing depends on factors including the organization's size, industry, risk profile, and regulatory requirements. Significant changes to infrastructure or applications can justify an additional assessment. Document the selected cadence in your policy and retain evidence that the assessments take place as planned. Our article on penetration testing frequency compares cadences across frameworks.
What evidence should you give your ISO 27001 auditor?
ISO 27001 certification is granted by an accredited certification body, not by your pentest provider and not by your own team. During the certification or surveillance compliance audit, the body's auditor looks for evidence that your technical vulnerability management works as documented. A technical security assessment can also inform your internal audit, but it does not replace the broader ISMS audit. Useful evidence includes:
Evidence | What it shows |
|---|---|
Penetration test report | Scope, methodology, findings with risk ratings, the associated risk, and remediation guidance (A.8.8, A.8.29) |
Risk treatment plan updates | How each finding was accepted, fixed or mitigated, and by whom (clause 6.1.3) |
Retest or fix-validation results | That remediation was verified, not just reported |
Vulnerability scan history | That scanning runs at the frequency your policy defines |
Attestation letter | A shareable summary of the test for customers and partners, without sensitive technical detail |
For more on each document, see what to expect from a penetration testing report and how a pentest attestation letter differs from it.
ISO 27001 compared with other security standards and frameworks
The same penetration test often supports several frameworks, but their requirements differ:
For PCI DSS compliance, penetration testing is explicitly required. Requirement 11.4 calls for internal and external tests at least every 12 months and after significant changes. See our PCI DSS penetration testing page.
SOC 2 doesn't require a pentest, but one is common evidence for the monitoring and risk assessment criteria (CC4.1 and CC7.1). Read our SOC 2 penetration testing requirements article.
HIPAA, the Health Insurance Portability and Accountability Act, doesn't explicitly require one today. A proposed update to the Security Rule would require annual penetration testing if it's finalized. See our HIPAA penetration testing guide.
In every case, a pentest provides evidence. It doesn't by itself make an organization compliant or certified, or establish regulatory compliance. Legal compliance depends on the organization's applicable obligations.
ISO 27001 penetration testing services
Blaze runs ISO 27001 penetration testing with reporting mapped to relevant Annex A controls, so your auditor can see how identifying vulnerabilities informs the compliance process and risk treatment. Validated findings appear in the Blaze Portal as testing progresses, with retesting and attestation letters available for audit and customer evidence. While we are not a compliance or audit firm, we collaborate with compliance platforms and work alongside your certification body to support your ISO 27001 program.
