ISO 27001 Penetration Testing Requirements
ISO 27001 does not explicitly require penetration testing, but auditors routinely expect it as evidence that your security controls are operating effectively. This guide explains the penetration testing requirements, control mappings, and auditor expectations associated with ISO/IEC 27001:2022.
Key Takeaways
- ISO 27001:2022 does not explicitly mandate penetration testing, but auditors commonly expect it as evidence of control effectiveness.
- Annex A.8.8 (Management of Technical Vulnerabilities) and A.8.29 (Security Testing in Development and Acceptance) are the primary controls supported by penetration testing.
- Vulnerability scanning alone is not sufficient; penetration testing is expected to validate whether vulnerabilities are actually exploitable.
- ISO 27001 pentest scope should align with the ISMS boundary and typically includes web applications, APIs, cloud infrastructure, internal networks, identity systems, and third-party integrations.
- Annual penetration testing is the commonly expected cadence for certification maintenance and surveillance audits.
- Remediation evidence and retesting of critical findings are important components of a compliant ISO 27001 security testing program.
- ISO 27001:2022 introduced new controls relevant to pentesting, including Threat Intelligence (A.5.7), Cloud Security (A.5.23), Monitoring Activities (A.8.16), Data Masking (A.8.11), and Data Leakage Prevention (A.8.12).
Contents
Quick Summary
What CISOs and IT Leaders Need to Know
ISO/IEC 27001:2022 is the world's leading standard for Information Security Management Systems (ISMS). It does not use the words 'penetration testing' as an explicit mandate — but no serious Stage 2 certification audit passes without one. Penetration testing is the primary technical evidence that Annex A controls are operating effectively, not just documented.
What Is ISO 27001:2022?
Background and Context
ISO/IEC 27001:2022 is an international standard published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). It specifies the requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). It is the most widely adopted information security certification globally, with over 70,000 certified organizations worldwide.
| Who Needs ISO 27001? | Examples |
|---|---|
| SaaS and cloud providers | Any software company handling customer data — increasingly required by enterprise procurement |
| Financial services firms | Banks, fintechs, insurance companies processing sensitive financial and personal data |
| Healthcare and life sciences | Alongside HIPAA (US) — ISO 27001 often required by EU and global healthcare clients |
| Government contractors | Many procurement frameworks require ISO 27001 or equivalent for sensitive government contracts |
| Supply chain participants | Vendors in regulated supply chains (automotive: TISAX, aerospace, defense) often required to certify |
| Managed service providers | MSPs handling client infrastructure increasingly expected to hold ISO 27001 by enterprise clients |
| Term | Plain English Meaning |
|---|---|
| ISMS | Information Security Management System — the governance framework defined by ISO 27001. |
| Annex A | The 93 reference controls organizations select from based on their risk assessment. |
| SoA | Statement of Applicability — documents which Annex A controls apply, which are excluded, and why. |
| Stage 1 Audit | Documentation review — auditor confirms ISMS documentation is in order before Stage 2. |
| Stage 2 Audit | On-site evidence review — auditor checks controls are implemented and operating effectively. This is where pentesting evidence is examined. |
| Surveillance Audit | Annual check between recertification cycles — evidence of continued control operation required. |
| Recertification Audit | Full audit every 3 years — ISMS must demonstrate sustained effectiveness. |
| Nonconformity | A finding where a control is not implemented or not operating as required. Major NCs can block certification. |
| ISO 27002:2022 | The companion implementation guidance standard for Annex A controls — auditors reference it. |
The ISMS Structure: Clauses and Annex A
Understanding the Two-Layer Framework
ISO 27001 follows the Harmonized Structure shared by ISO 42001, ISO 9001, and other management system standards. It has two layers: mandatory governance clauses (4–10) and Annex A reference controls selected based on risk assessment.
| Layer | What It Covers |
|---|---|
| Clauses 4–10 (Mandatory) | Context, leadership, planning (risk assessment and treatment), support, operations, performance evaluation (Clause 9.1 — key pentest hook), and improvement. All mandatory. |
| Annex A Controls (Risk-Based) | 93 reference controls across 4 themes. Selected via Statement of Applicability based on risk assessment. Auditors review the SoA to confirm appropriate controls are selected and implemented. |
| ISO 27002:2022 (Guidance) | Non-normative implementation guidance for each Annex A control. Auditors use ISO 27002 to assess the quality of control implementation — it is the 'how' behind the Annex A 'what'. |
| Theme | Controls | Key Security Areas |
|---|---|---|
| A.5 — Organizational | 37 controls (A.5.1–A.5.37) | Policies, threat intelligence, access control policy, supplier security, incident management, compliance, information classification |
| A.6 — People | 8 controls (A.6.1–A.6.8) | Screening, employment terms, training and awareness, discipline, offboarding, remote working, security reporting |
| A.7 — Physical | 14 controls (A.7.1–A.7.14) | Physical security perimeters, entry controls, equipment security, clear desk, secure disposal, cabling security |
| A.8 — Technological | 34 controls (A.8.1–A.8.34) | Endpoint protection, privileged access, encryption, logging, vulnerability management, security testing, network security, cloud security, secure development |
Clause 9.1 (Monitoring, Measurement, Analysis and Evaluation) requires organizations to determine what needs to be monitored, what methods will be used, when analysis occurs, and who is responsible. It demands objective evidence that security controls are actually working. Penetration testing is the strongest form of evidence available for Clause 9.1 — it demonstrates not just that a control exists, but that it holds up under real-world attack conditions. Auditors treat Clause 9.1 as the bridge between documented controls and demonstrated effectiveness.
Required Controls and Pentest Mapping
ISO 27001:2022 Annex A Controls with Security Testing Relevance
The controls below are drawn directly from ISO/IEC 27001:2022 Annex A. While the standard does not mandate penetration testing by name, these are the controls certification auditors look to for pentest evidence. Controls are listed with 2022 numbering alongside legacy 2013 references for organizations in transition.
| Control | Name | Pentest Relevance |
|---|---|---|
| A.5.7 (NEW) | Threat Intelligence | Threat intelligence gathering directly informs pentest scope. Pentest findings are a primary source of operational threat intelligence — real exploitability data, not theoretical advisories. |
| A.5.20 | Addressing Security Within Supplier Agreements | Third-party security testing validates supplier controls. Pentesting supplier-facing systems or APIs confirms security requirements are met in practice. |
| A.5.21 | Managing Information Security in the ICT Supply Chain | Supply chain security testing validates that third-party components (APIs, SDKs, open source libraries) do not introduce exploitable vulnerabilities into the ISMS boundary. |
| A.5.23 (NEW) | Information Security for Use of Cloud Services | Cloud configuration review and exploitation testing validates that cloud service security controls meet ISMS requirements. AWS/Azure/GCP misconfigurations are in scope. |
| A.5.25 | Assessment and Decision on Information Security Events | Pentest events generate information security events that must be assessed. Tests whether the assessment and decision process actually operates correctly. |
| A.5.36 | Compliance with Policies, Rules and Standards | Penetration testing provides technical evidence of compliance with implemented controls. Nonconformities found in pentests must be addressed under this control. |
The Technological theme contains the controls most directly satisfied by penetration testing. A.8.8 and A.8.29 are the two controls auditors specifically reference when asking for pentest evidence.
| Control | Name | Pentest Relevance |
|---|---|---|
| A.8.8 | Management of Technical Vulnerabilities | THE PRIMARY PENTEST CONTROL. Requires timely identification and evaluation of technical vulnerabilities and appropriate action. Penetration testing is the gold standard — it goes beyond scanning to validate exploitability. |
| A.8.29 | Security Testing in Development and Acceptance | THE DEVELOPMENT PENTEST CONTROL. Requires security testing processes defined and performed throughout the development lifecycle. Web application pentests and pre-release security testing satisfy this control directly. |
| A.8.2 | Privileged Access Rights | Privilege escalation testing validates that privileged access is properly restricted. Testers attempt to gain admin rights through misconfiguration, credential abuse, or application flaws. |
| A.8.3 | Information Access Restriction | Access control testing — IDOR, broken authorization, API access bypass — validates that access restrictions are enforced technically, not just in policy. |
| A.8.5 | Secure Authentication | Authentication testing covers MFA bypass, password policy enforcement, brute force resistance, SSO weaknesses, and session management vulnerabilities. |
| A.8.9 (NEW) | Configuration Management | Configuration review and hardening validation tests that systems are deployed with secure baselines — common findings include default credentials, unnecessary services, and insecure defaults. |
| A.8.11 (NEW) | Data Masking | Testing validates that sensitive data is appropriately masked in non-production environments — development/staging data exposure is a common pentest finding. |
| A.8.12 (NEW) | Data Leakage Prevention | Pentest validates DLP controls — tests whether sensitive data can be exfiltrated via email, USB, cloud uploads, or API responses without triggering controls. |
| A.8.15 | Logging | Pentest validates that logging captures attack activity — if a pentest generates no alerts or log entries, that is a direct A.8.15 / Clause 9.1 finding. |
| A.8.16 (NEW) | Monitoring Activities | Pentest exercises validate whether monitoring systems detect adversarial activity. Red team exercises are particularly relevant — if detection fails during testing, it will fail during real attacks. |
| A.8.20 | Networks Security | External and internal network pentests validate firewall rules, DMZ architecture, service exposure, and network boundary protections. |
| A.8.22 | Segregation of Networks | Network segmentation testing validates that VLAN boundaries hold, lateral movement between segments is blocked, and critical systems are isolated from less-trusted environments. |
| A.8.24 | Use of Cryptography | Encryption testing validates TLS configuration, cipher suite strength, certificate management, and key storage — weak cryptography is a common high-severity pentest finding. |
| A.8.25 | Secure Development Life Cycle | Security testing is a required component of the SDLC. Pentest provides evidence that the SDLC produces secure outputs at each stage. |
| A.8.26 | Application Security Requirements | Web application and API pentesting validates that defined security requirements are actually implemented — authentication, authorization, input validation, and data protection. |
| A.8.28 | Secure Coding | Penetration testing identifies vulnerabilities resulting from insecure coding — SQL injection, XSS, insecure deserialization — that SAST/DAST may miss. |
| A.8.31 | Separation of Dev, Test and Production | Environment isolation testing validates that production credentials, data, and systems are not accessible from development or test environments. |
| A.8.34 (NEW) | Protection of Systems During Audit Testing | Rules of engagement and testing safeguards ensure that the pentest itself does not cause a production incident. Proper scoping and controls protect systems during testing. |
ISO 27002:2022 guidance for A.8.8 explicitly states that organizations should:
This is the closest ISO 27001 gets to a direct penetration testing requirement. Certification auditors treat a documented annual pentest with remediation evidence as the minimum bar for A.8.8.
Highlighted Control Areas
Security Topics with Specific Annex A Mappings
The following areas represent the most pentest-relevant control categories in ISO 27001:2022. Each maps to specific Annex A controls and includes guidance on what security testing should validate.
A.8.5 (Secure Authentication) requires authentication controls appropriate to the risk of unauthorized access. A.5.16 (Identity Management) governs the identity lifecycle. A.8.2 (Privileged Access Rights) specifically addresses high-privilege credential management. ISO 27002 guidance for A.8.5 recommends multi-factor authentication, strong password policies, and controls against brute force and credential stuffing attacks.
| Testing Area | Annex A Control |
|---|---|
| Password complexity, length, and lockout policy enforcement | A.8.5 — Secure Authentication |
| Multi-factor authentication implementation and bypass testing | A.8.5 — MFA explicitly recommended in ISO 27002 guidance |
| Default credentials on systems, applications, and network devices | A.8.5, A.8.9 — Configuration Management |
| Privileged account credential security and management | A.8.2 — Privileged Access Rights |
| Service account and API key management | A.8.2, A.5.16 — Identity Management |
| Password reset and credential recovery workflow testing | A.8.5 — authentication resilience |
| Credential exposure in code repositories, logs, or error messages | A.8.28 — Secure Coding; A.8.11 — Data Masking |
Access management is one of the most tested areas in ISO 27001 audits. A.5.15 (Access Control) establishes the policy foundation. A.8.3 (Information Access Restriction) requires technical enforcement. A.8.2 (Privileged Access Rights) demands that elevated access is strictly controlled and reviewed. The principle of least privilege must be demonstrated in practice through testing, not just declared in policy.
| Testing Area | Annex A Control |
|---|---|
| Role-based access control and least privilege enforcement | A.5.15 — Access Control; A.8.3 — Information Access Restriction |
| Privilege escalation — vertical (user to admin) and horizontal | A.8.2 — Privileged Access Rights; A.8.3 |
| Broken object-level authorization (IDOR/BOLA) in applications and APIs | A.8.3 — Information Access Restriction; A.8.26 |
| Orphaned accounts — terminated employees, unused service accounts | A.5.18 — Access Rights; A.6.5 — Responsibilities After Termination |
| Admin interface exposure and hardening | A.8.2, A.8.9 — Configuration Management |
| Third-party and supplier access validation | A.5.20 — Supplier Agreements; A.5.21 — ICT Supply Chain |
A.8.8 is the definitive vulnerability management control in ISO 27001:2022. ISO 27002 guidance explicitly calls for periodic penetration testing as part of A.8.8 implementation. A.5.7 (Threat Intelligence) feeds threat data into vulnerability prioritization. A.8.9 (Configuration Management) addresses hardening gaps. Vulnerability scanning and penetration testing are complementary — scanning identifies known CVEs, pentesting validates whether they are actually exploitable in your specific environment.
| Activity | Annex A Control / Cadence |
|---|---|
| Vulnerability scanning — automated, continuous or periodic | A.8.8 — Management of Technical Vulnerabilities |
| Annual penetration test — external and internal | A.8.8 — explicitly referenced in ISO 27002 implementation guidance |
| Web application and API security testing | A.8.29 — Security Testing in Development and Acceptance |
| Cloud configuration review and exploitation testing | A.5.23 — Cloud Security; A.8.8 |
| Patch management timeline validation | A.8.8 — timely remediation per risk rating |
| Post-change security testing (after significant changes) | A.8.8 — re-evaluate after environmental changes |
| Remediation retesting before surveillance audit | A.8.8, Clause 9.1 — demonstrating control effectiveness |
A.8.22 (Segregation of Networks) explicitly requires that networks be segregated based on information sensitivity and system criticality. A.8.20 (Networks Security) governs broader network security controls. Network segmentation testing validates that logical and physical boundaries actually prevent lateral movement between trust zones.
| Testing Area | Annex A Control |
|---|---|
| Network segmentation — VLAN boundary testing and lateral movement | A.8.22 — Segregation of Networks |
| Firewall rule review and bypass attempts | A.8.20 — Networks Security |
| DMZ architecture validation — can DMZ hosts reach internal systems? | A.8.22, A.8.20 |
| Production vs. development/test environment isolation | A.8.31 — Separation of Development, Test and Production |
| Guest network isolation from corporate systems | A.8.22 — Segregation of Networks |
| Cloud VPC, security group, and subnet configuration testing | A.5.23 — Cloud Services; A.8.22 |
| Network service exposure — unnecessary ports and services | A.8.20, A.8.9 — Configuration Management |
A.8.24 (Use of Cryptography) is the primary encryption control, requiring a policy on cryptographic controls and key management. A.5.33 (Protection of Cryptographic Keys) governs key lifecycle management. Penetration testing validates that encryption is correctly implemented — not just that a policy exists. Weak cipher suites, expired certificates, and cleartext data transmission are common high-severity findings.
| Testing Area | Annex A Control |
|---|---|
| TLS/SSL configuration — cipher suites, protocol versions, certificate validity | A.8.24 — Use of Cryptography |
| Cleartext data transmission detection — internal and external | A.8.24, A.8.26 — Application Security Requirements |
| Sensitive data exposure in API responses and error messages | A.8.11 — Data Masking; A.8.26 |
| Encryption key storage and exposure testing | A.5.33 — Protection of Cryptographic Keys |
| Database encryption validation at rest | A.8.24 — cryptographic controls |
| Hardcoded secrets in source code or configuration files | A.8.28 — Secure Coding; A.5.33 |
| Certificate management and rotation procedures | A.8.24, A.8.9 — Configuration Management |
A.5.12 (Classification of Information) and A.5.13 (Labelling) establish the data classification framework. A.8.10 (Information Deletion) and A.8.11 (Data Masking) are new 2022 controls addressing data lifecycle and protection in operational environments. Penetration testing validates that classification controls are enforced technically. Multi-tenant SaaS environments and shared databases are high-risk areas for data segregation failures.
| Testing Area | Annex A Control |
|---|---|
| Multi-tenant data isolation — can Tenant A access Tenant B data? | A.5.12, A.8.3 — Information Access Restriction |
| Data classification enforcement in API responses | A.5.12, A.8.11 — Data Masking |
| Non-production environment data masking validation | A.8.11 — Data Masking (new 2022 control) |
| Database access control — unauthorized queries to sensitive tables | A.8.3, A.8.10 — Information Deletion |
| Data leakage via logs, error messages, or cache headers | A.8.12 — Data Leakage Prevention (new 2022) |
| Storage bucket and file share access control testing | A.5.12, A.5.23 — Cloud Security |
ISO 27001:2022 significantly strengthened supplier security controls. A.5.21 (ICT Supply Chain) is an expanded control addressing software supply chain risks. A.5.23 (Cloud Security) is a brand new 2022 control for cloud service provider security. Supply chain testing validates that third-party components — APIs, SDKs, open source libraries, cloud services — do not introduce exploitable vulnerabilities into the ISMS boundary.
| Testing Area | Annex A Control |
|---|---|
| Third-party API security testing | A.5.20 — Supplier Agreements; A.5.23 — Cloud Security |
| Software composition analysis (SCA) of dependencies | A.5.21 — ICT Supply Chain; A.8.8 |
| Cloud service configuration review and exploitation testing | A.5.23 — Cloud Security (new 2022 control) |
| Supplier access path testing — VPNs, portals, shared credentials | A.5.19 — Supplier Relationships; A.8.2 |
| Vendor-provided component security assessment | A.5.21 — ICT Supply Chain |
| Penetration testing firm's own ISO 27001 certification | A.5.19 — due diligence on security service providers |
A.8.15 (Logging) and A.8.16 (Monitoring Activities — new 2022) together require that organizations generate, protect, and actively monitor security logs. A.8.16 explicitly lists penetration testing as a method for extending security monitoring to establish system baselines. If a penetration test runs simulated attacks and no SIEM alerts fire, no logs are generated, or no incident response is triggered — that is a direct A.8.15/A.8.16 finding.
| Testing Area | Annex A Control |
|---|---|
| SIEM/IDS detection validation — did pentest activity generate alerts? | A.8.16 — Monitoring Activities (new 2022) |
| Log completeness — are all access and security events captured? | A.8.15 — Logging |
| Log integrity — can logs be tampered with or deleted? | A.8.15 — Logging protection |
| Log retention validation — are logs available for the required period? | A.8.15 — retention requirements |
| Incident response trigger testing — do IR procedures activate? | A.5.26 — Response to Information Security Incidents |
| Audit trail bypass testing — can logging be disabled during attack? | A.8.15, A.8.16 |
ISO 27001:2013 vs. 2022: What Changed?
Key Changes Affecting Pentest Programs
Organizations certified to ISO 27001:2013 had until October 31, 2025 to transition to the 2022 version. The 2022 revision significantly reorganized Annex A and added 11 new controls relevant to modern security testing programs.
| Aspect | ISO 27001:2013 | ISO 27001:2022 |
|---|---|---|
| Control structure | 114 controls across 14 domains | 93 controls across 4 themes |
| Primary pentest control | A.12.6.1 — Technical Vulnerability Management | A.8.8 — Management of Technical Vulnerabilities (expanded) |
| Development security testing | A.14.2.8 + A.14.2.9 (separate controls) | A.8.29 — Security Testing in Development (merged and strengthened) |
| Cloud security | Not explicitly addressed | A.5.23 — Information Security for Use of Cloud Services (new) |
| Threat intelligence | Not explicitly required | A.5.7 — Threat Intelligence (new) |
| Monitoring activities | A.12.4 — Logging and Monitoring | A.8.16 — Monitoring Activities (expanded, explicitly references pentesting) |
| Data masking | Not explicitly addressed | A.8.11 — Data Masking (new) |
| Data leakage prevention | Not explicitly addressed | A.8.12 — Data Leakage Prevention (new) |
| Configuration management | Addressed via A.12 | A.8.9 — Configuration Management (new, explicit control) |
| Supply chain security | A.15 — Supplier Relationships | A.5.19–A.5.22 + A.5.23 (significantly expanded) |
The ISO 27001:2013 to 2022 transition deadline was October 31, 2025. All active certificates issued under the 2013 version have expired or been reissued under the 2022 standard. If your pentest program still maps findings to 2013 Annex A control numbers, update your reporting templates to reference 2022 control numbers (e.g., A.12.6.1 to A.8.8; A.14.2.8/9 to A.8.29). Auditors at surveillance and recertification audits will reference the 2022 controls exclusively.
Pentest Scope for ISO 27001
What Should Be In Scope?
ISO 27001 pentest scope is defined by the ISMS boundary — the systems, services, locations, and processes included in the certified scope. Any component that stores, processes, or transmits information assets covered by the ISMS should be considered. The Statement of Applicability (SoA) defines which controls apply, and pentest scope should cover the systems those controls protect.
| Component | Typical Testing Focus | Relevant Controls |
|---|---|---|
| External perimeter | Public-facing assets, IP ranges, DNS, exposed services, boundary controls | A.8.20, A.8.8 |
| Web applications and APIs | Authentication, authorization, business logic, injection, OWASP Top 10 | A.8.26, A.8.29, A.8.3 |
| Internal network | Segmentation, lateral movement, inter-VLAN access, internal service exposure | A.8.22, A.8.20 |
| Cloud infrastructure | AWS/Azure/GCP IAM, storage, misconfigurations, cloud-native services | A.5.23, A.8.8 |
| Identity and access management | SSO, MFA, directory services, privilege escalation, orphaned accounts | A.8.5, A.8.2, A.5.16 |
| Development and CI/CD pipelines | Source code exposure, deployment pipeline security, secrets in CI/CD | A.8.25, A.8.29, A.8.28 |
| Third-party integrations | API keys, vendor access paths, supply chain component security | A.5.21, A.5.23 |
| Endpoints and workstations | Endpoint protection, encryption validation, lateral movement from workstation | A.8.1, A.8.7, A.8.24 |
| Logging and monitoring systems | Detection capability, log integrity, SIEM alert validation | A.8.15, A.8.16 |
What Certification Auditors Expect
Evidence Requirements for Stage 2 and Surveillance Audits
Surveillance and Recertification Audits
Maintaining ISO 27001 Certification Over Time
ISO 27001 certification is maintained through a three-year cycle: initial certification (Stage 1 + Stage 2), followed by two annual surveillance audits, and then a full recertification audit in year three. Penetration testing evidence is expected at every stage.
| Audit Type | Timing | Pentest Evidence Expected |
|---|---|---|
| Stage 1 — Documentation Review | Initial certification | Pentest policy and procedures documented. Methodology selected and recorded in ISMS documentation. |
| Stage 2 — Implementation Audit | Initial certification (typically 3–6 months after Stage 1) | Recent pentest report (within 12 months) covering ISMS scope. Remediation evidence. A.8.8 and A.8.29 implementation demonstrated. |
| Surveillance Audit 1 | 12 months after certification | Updated pentest or new annual pentest. Evidence that previous findings are remediated. Vulnerability scanning logs. |
| Surveillance Audit 2 | 24 months after certification | Annual pentest covering any scope changes. Updated SoA if new systems added. Continued remediation evidence. |
| Recertification Audit | 36 months after certification | Full ISMS re-evaluation. All pentest evidence for the three-year period. Trend analysis — are the same finding types recurring? Demonstrates continual improvement (Clause 10). |
ISO 27001's Clause 10 (Improvement) requires that nonconformities are corrected and the root cause addressed to prevent recurrence. This applies directly to pentest findings. If the same vulnerability type (e.g., SQL injection, weak authentication) appears in consecutive annual pentests, auditors will question whether the SDLC and control improvements are working. Recurring findings without systemic remediation are a Clause 10 nonconformity — not just a technical finding. Use pentest trends over multiple years as evidence of continual ISMS improvement.
Resources
ISO 27001 and Pentesting References
The primary source. Purchase required. Defines all mandatory ISMS requirements including Clauses 4–10 and Annex A. Essential before any ISMS implementation or audit preparation.
Implementation guidance for every Annex A control. Auditors use ISO 27002 to assess the depth of control implementation. Explicitly references penetration testing in A.8.8 and A.8.16 guidance.
Explains how NIST SP 800-115 (the technical testing standard) relates to ISO 27001 and other compliance frameworks. Useful for scoping and methodology documentation.
The most widely referenced penetration testing methodology standard. Acceptable for ISO 27001 A.8.8 and A.8.29 methodology documentation. Free and authoritative.
Industry-standard methodology for web application and API security testing. Directly applicable to A.8.26 (Application Security Requirements) and A.8.29 (Security Testing in Development).
CIS Controls map well to ISO 27001 Annex A. Useful for prioritizing control implementation and demonstrating defense-in-depth alongside ISO 27001 certification.
Adversarial tactics and techniques framework. Useful for mapping pentest findings to real-world threat actor behavior — strengthens A.5.7 (Threat Intelligence) evidence and adds context to audit reports.
Official ISO guidance on transitioning from ISO 27001:2013 to 2022. Essential for understanding control number mapping (e.g., A.12.6.1 to A.8.8) when updating pentest report templates.
CREST is a professional body for penetration testing. CREST-certified testers are widely recognized by ISO 27001 certification bodies as qualified independent assessors for A.8.8.
.avif)
