ISO 27001 Penetration Testing: Annex A.8.29, A.8.8 and Certification Evidence

ISO/IEC 27001:2022 introduced substantive revisions to its Annex A technology controls that directly affect penetration testing obligations. Control A.8.29 (Security Testing in Development and Acceptance) requires documented security testing before systems go live. Control A.8.8 (Management of Technical Vulnerabilities) requires a systematic vulnerability management process that explicitly includes penetration testing as an assessment method. Together, these two controls form the technical backbone of an ISO 27001 ISMS as it relates to offensive security. This page explains what certification body auditors expect to see, how to structure a testing programme that survives surveillance and recertification audits, and how to integrate continuous automated testing with scheduled external engagements.

Run ISO 27001 scan

Written by Malte Wagenbach

Founder of Matproof Security. Specialized in AI-driven penetration testing and EU compliance (DORA, NIS2, ISO 27001, SOC 2).

Last reviewed: May 17, 2026

What ISO 27001:2022 actually requires from your penetration testing programme

ISO 27001:2013 included vulnerability management under A.12.6 but was less prescriptive about penetration testing specifically. The 2022 revision significantly strengthened the technology controls. Annex A now contains 93 controls across 4 themes (organisational, people, physical, technological), replacing the 114 controls of the 2013 edition. The 2022 edition added 11 new controls, including A.8.29 (Security Testing in Development and Acceptance) as an entirely new requirement. Certification body auditors — whether UKAS-accredited in the UK, DAkkS-accredited in Germany, COFRAC in France, or ACCREDIA in Italy — have adapted their audit programmes to examine whether A.8.29 and A.8.8 are genuinely implemented. 'We run an annual vulnerability scan' is no longer sufficient evidence. Auditors are increasingly asking to review actual penetration test reports, remediation tracking records, and re-test evidence showing fixes were verified. The practical bar set by experienced ISO 27001 lead auditors in 2024-2025 is: (1) penetration testing must be scoped to cover critical ISMS assets, (2) tests must use documented methodology (OWASP Testing Guide, PTES, or NIST SP 800-115), (3) findings must be risk-rated using CVSS 3.1 or equivalent, (4) remediation must be tracked with acceptance or treatment decisions for each finding, and (5) high and critical findings must be re-tested to confirm resolution.

ISO 27001:2022 Annex A.8.29 (Security Testing in Development and Acceptance) — a new control in the 2022 revision — requires that security testing of new applications and significant changes be defined and implemented in development processes. Penetration testing before major production releases is the standard implementation.
ISO 27001:2022 Annex A.8.8 (Management of Technical Vulnerabilities) requires timely identification and remediation of technical vulnerabilities. The ISO 27002:2022 implementation guidance specifically references penetration testing as a means of technical vulnerability identification complementary to automated vulnerability scanning.
ISO 27001:2022 Annex A.8.25 (Secure Development Life Cycle) and A.8.26 (Application Security Requirements) create a broader obligation to test security throughout development — not just at deployment. CI/CD-integrated penetration testing directly satisfies these controls.
Certification body auditors at surveillance audits (annual) and recertification audits (every 3 years) review whether the penetration testing programme has operated continuously — a single test done two months before audit is a red flag for certificate suspension.
ISO 27001 certification is increasingly demanded in enterprise B2B procurement. If your certificate lapses or your audit finds A.8.29/A.8.8 as major nonconformities, you lose the certificate — and with it, potentially significant enterprise revenue locked behind 'ISO 27001 certification required' vendor qualification criteria.
Cyber insurers offering ISO 27001-premium-discounted policies require that the certified ISMS actually includes active penetration testing. Ghost certifications (maintained on paper without active testing) are increasingly challenged at claim time.
DORA and NIS2 both explicitly recognise ISO 27001 certification as evidence of cybersecurity baseline compliance — but only if the ISMS controls (including A.8.29) are genuinely implemented. An ISO 27001 certificate with a major nonconformity finding on A.8.29 would not satisfy a DORA Art. 24 audit.

What Matproof tests to support your ISO 27001 Annex A controls

A.8.29 — security testing in development: pre-release scanning of staging environments, CI/CD-integrated tests that block deployment when Critical/High findings are present, stack-specific testing (Next.js CVE-2024-43481, Django CVE-2024-43990, Spring4Shell CVE-2022-22965)
A.8.8 — technical vulnerability management: continuous CVE monitoring against your fingerprinted technology stack, NVD/GHSA database correlation, automated alerts when new CVEs affecting your specific dependencies are published
A.8.26 — application security requirements: OWASP Top 10 (2021) coverage — A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A07 Authentication Failures, A09 Security Logging and Monitoring Failures
A.8.9 — configuration management: security header checks (HSTS RFC 6797, CSP W3C Level 2, X-Frame-Options, Referrer-Policy, Permissions-Policy), TLS configuration audit (RFC 8446), CORS policy review
A.5.30 — ICT readiness for business continuity: availability and resilience of critical application endpoints, HTTP/2 rapid reset DoS resistance (CVE-2023-44487 mitigations), rate limiting effectiveness
A.8.23 — web filtering and A.8.28 — secure coding: SQL injection (CWE-89), stored and reflected XSS (CWE-79), SSRF (CWE-918), command injection (CWE-78), XML external entity injection XXE (CWE-611)
A.8.3 — information access restriction: IDOR testing (OWASP API1:2023 Broken Object Level Authorization), multi-tenancy isolation verification, horizontal and vertical privilege escalation
A.8.2 — privileged access rights and A.5.17 — authentication information: JWT weakness detection (CWE-347), password reset flow analysis, MFA bypass via session fixation or token replay
A.8.7 — protection against malware: supply chain component analysis (npm, PyPI, Maven, Cargo) against known-malicious packages, SBOM generation support
A.5.7 — threat intelligence integration: findings mapped to MITRE ATT&CK Enterprise, enabling SOC teams to create detection rules from observed attack techniques

Sample finding

High

A.8.8 violation: critical CVE in production dependency undetected for 8 months

Matproof Sentinel identified that the customer's production application uses Spring Framework 5.3.26, which is vulnerable to CVE-2022-22965 ('Spring4Shell', CVSS 9.8) — a remote code execution vulnerability in Spring MVC/WebFlux applications running on JDK 9+. The vulnerability was publicly disclosed in March 2022 and a patch was available within 48 hours. The customer's dependency version had not been updated in 8 months. Sentinel confirmed exploitability by crafting a ClassLoader manipulation request that wrote a JSP webshell to the application's accessible directory. ISO 27001:2022 A.8.8 requires timely identification and remediation of technical vulnerabilities — 8 months constitutes a material control failure that a certification auditor would raise as a major nonconformity.

Fix: Immediate: upgrade Spring Framework to ≥5.3.18 (or ≥6.0.0 if on Spring 6.x). Verify fix by attempting the CVE-2022-22965 exploit payload against the patched staging environment. Process fix for A.8.8 compliance: implement automated SCA (Software Composition Analysis) in CI/CD pipelines using Dependabot, Renovate, or Matproof Sentinel's continuous scanning. Set policy: Critical and High CVEs must be patched within 7 days of vendor disclosure; Medium within 30 days. Document the vulnerability management policy, track remediation in your risk register, and evidence the timeline for the ISO 27001 auditor. Configure Matproof Sentinel email alerts to fire within 24 hours of a new CVE affecting your fingerprinted stack.

Reference: CVE-2022-22965 Spring4Shell (CVSS 9.8) · ISO 27001:2022 A.8.8 Management of Technical Vulnerabilities · CWE-94 Improper Control of Code Generation · OWASP A06:2021 Vulnerable and Outdated Components

ISO 27001 penetration testing options

—	Free scan	Matproof Sentinel	Traditional consultancy
Automated scan engine	✓ (3-min preview)	✓ Full scan	✗ Manual only
OWASP Top 10 coverage	Partial	✓ Complete	✓ Complete
Proof-of-exploit evidence	✗	✓ Per finding	✓ Per finding
Regulatory mapping (DORA/NIS2/ISO 27001)	✗	✓ Automated	✓ Manual
Audit-ready PDF report	✗	✓ Instant	✓ 2–4 weeks delivery
Continuous / recurring scans	✗	✓ Per deploy	✗ Annual engagement
Time to first result	~3 min	~30 min full scan	2–4 weeks
Price	€0	From €149	€8,000–€25,000
Source code review (SAST)	✗	✓ On Growth plan	✓ Scoped engagement
API testing (REST/GraphQL)	✗	✓ Automated	✓ Manual

Matproof Sentinel for ISO 27001 compliance

Single Run

€149 one-time

1 full pentest scan
AI-prioritized findings with CVSS 3.1
Proof-of-exploit per finding
Audit-ready PDF report
Regulatory mapping (DORA, NIS2, ISO 27001)

Unlimited scans (up to 3 domains)
Continuous monitoring
CI/CD integration (GitHub, GitLab)
All regulatory mappings
Priority support

Start Starter →

Growth

€799 / month

Unlimited scans + domains
Authenticated / White-Box testing
API & cloud infrastructure tests
Dedicated security account manager
24h SLA response time

Contact for Growth →

Frequently asked questions about ISO 27001 penetration testing

Does ISO 27001:2022 explicitly require a penetration test?

ISO 27001 does not use the phrase 'penetration test' explicitly in the normative standard text. However, Control A.8.29 (Security Testing in Development and Acceptance) requires that security testing activities are defined and implemented, and ISO 27002:2022 (the implementation guidance for ISO 27001 controls) explicitly lists penetration testing as an implementation mechanism for A.8.29 and A.8.8. In practice, certification body auditors treat the absence of any penetration testing programme as a major nonconformity for organisations whose ISMS scope includes significant digital assets. 'We do vulnerability scans' without any structured penetration testing is consistently flagged as insufficient by experienced ISO 27001 lead auditors.

What does a certification auditor look for during an ISO 27001 A.8.29 audit?

Experienced ISO 27001 lead auditors conducting A.8.29 audits typically review: (1) a documented security testing policy or procedure that names penetration testing as a required activity, (2) actual penetration test reports from within the preceding 12 months (for surveillance audits) or showing continuous activity over the 3-year certification period (for recertification), (3) evidence that tests were scoped to cover critical ISMS assets — not just perimeter systems, (4) CVSS 3.1 or equivalent risk rating for all findings, (5) a remediation tracking mechanism (risk register, issue tracker, or dedicated tool) showing disposition of each finding, (6) for Critical/High findings: re-test reports confirming remediation, (7) that test results were communicated to management. An auditor will sample the finding list and cross-reference with the remediation register — discrepancies are major nonconformity territory.

How does the ISO 27001 3-year recertification cycle affect penetration testing requirements?

Certification bodies typically conduct an initial certification audit (Stage 1 document review + Stage 2 on-site), followed by two annual surveillance audits (years 1 and 2), and a recertification audit in year 3. For A.8.29 and A.8.8 compliance: surveillance audits examine whether penetration testing has been conducted since the last audit and findings remediated. Recertification audits look at the full 3-year programme — you need evidence of testing at regular intervals, not just a rush of activity in the month before recertification. Best practice: schedule testing in Q2 and Q4 annually, so you always have current test evidence for surveillance audits scheduled in Q1 or Q3, and a comprehensive testing history for recertification.

Does running Matproof Sentinel satisfy ISO 27001 A.8.29 and A.8.8?

Matproof Sentinel's automated penetration testing directly addresses A.8.29 (testing in development/acceptance — via CI/CD integration and pre-release scanning) and A.8.8 (vulnerability management — via continuous CVE monitoring and structured findings with remediation tracking). For many organisations with web applications and APIs as their primary digital asset, Sentinel's automated testing combined with an annual structured external pentest will satisfy certification auditor expectations. The Sentinel PDF report is structured to provide the evidence artefacts auditors look for: scoped findings, CVSS ratings, proof of exploitation, remediation recommendations, and re-test capability. However, for organisations with complex environments (internal network segmentation, OT/SCADA systems, physical access controls within ISMS scope), automated web application testing alone will not cover all relevant controls — a broader engagement is recommended.

What is the difference between ISO 27001 A.8.29 and A.8.8?

A.8.29 (Security Testing in Development and Acceptance) focuses on the software development lifecycle — ensuring security is tested before code is deployed to production. It applies to internally developed and procured software. A.8.8 (Management of Technical Vulnerabilities) is broader — it covers ongoing identification and remediation of vulnerabilities across all technical assets throughout their operational lifetime, not just at deployment. A.8.29 is satisfied by pre-release penetration testing and SAST/DAST in CI/CD. A.8.8 is satisfied by continuous CVE monitoring, regular vulnerability scanning, periodic penetration tests on production systems, and a documented remediation process. Both controls must be implemented — one covers 'test before deploy', the other covers 'monitor and fix in production'.

Can ISO 27001 certification substitute for NIS2 Art. 21 or DORA Art. 24 compliance?

ISO 27001 certification is internationally recognised evidence of cybersecurity maturity and many competent authorities treat it as a positive indicator during NIS2 supervisory assessments. However, it does not substitute for NIS2 or DORA compliance. NIS2 Art. 21 requires sector-specific measures and reporting obligations that ISO 27001 does not cover (e.g., incident notification within 24 hours, Art. 23 NIS2). DORA Art. 24 requires testing of specific ICT systems for financial entities that goes beyond what a standard ISO 27001 ISMS scope would cover. The most effective posture is to treat ISO 27001 as the governance framework, and NIS2/DORA compliance as extensions requiring specific additional technical testing and reporting procedures.

What penetration test scope is appropriate for an ISO 27001 ISMS?

The penetration test scope for ISO 27001 should align with the ISMS scope definition. If your ISMS covers 'information security for our customer-facing SaaS platform', then the penetration test scope must include that platform's web application, APIs, authentication infrastructure, and any supporting cloud services. If the ISMS scope is organisation-wide, the scope should be risk-based: critical assets (those handling the most sensitive data or providing the most critical business functions) should be tested annually; less critical assets can be on a 2-year cycle. For ISO 27001 certification purposes, it is better to have a well-scoped and regularly tested scope than a nominally comprehensive scope tested infrequently. Auditors are more concerned with evidence of continuous control operation than with scope breadth.

How do I handle ISO 27001 penetration test findings during a certification audit?

During a certification audit, open findings are not inherently a problem — auditors understand that penetration tests will generate findings and that remediation takes time. What auditors look for is evidence of a functioning process: (1) findings are documented and risk-rated, (2) each finding has a treatment decision (fix with timeline, risk acceptance with justification, or compensating control), (3) Critical/High findings have been remediated and re-tested within a reasonable timeframe (typically 30-60 days for Critical, 90 days for High), (4) low-severity findings are tracked and addressed in prioritised order, (5) management has reviewed the overall finding status. A clean finding register with no overdue Critical/High items is the goal. Matproof Sentinel's remediation tracking feature exports this data in audit-ready format.

Go deeper — related blog articles

Get audit-ready penetration testing evidence for ISO 27001

Matproof Sentinel generates structured penetration test reports mapped to ISO 27001:2022 Annex A.8.29 and A.8.8 — ready for certification body auditors. Start with a free 3-minute scan or get a full audit-ready report from €149.