ISO 27001 does not contain a line that says "you must conduct a penetration test." What it contains is a set of Annex A controls that, under the 2022 revision, make penetration testing the most direct way to satisfy the security testing evidence requirement, and auditors from accredited certification bodies increasingly expect to see it.
Understanding which specific controls create the testing obligation, what evidence satisfies them, and what distinguishes passing from failing documentation is what separates a successful ISO 27001 surveillance or certification audit from an unexpected finding. The confusion stems from the fact that ISO 27001 is a flexible, risk-based standard. Flexibility creates ambiguity, and auditors fill ambiguity with expectations based on industry practice.
This guide maps the specific ISO 27001:2022 Annex A controls relevant to penetration testing, explains what each requires in concrete terms, and covers what auditors examine when reviewing the security testing evidence package.
The ISO 27001:2013 revision contained the primary technical vulnerability management control under Annex A 12.6.1, which required the organisation to obtain information about technical vulnerabilities of information systems in use and take appropriate measures. Penetration testing was implicit in "appropriate measures" but not named.
ISO 27001:2022, published in October 2022, restructured the Annex A controls significantly. The control count moved from 114 to 93, with new controls added and others merged or renamed. The controls most directly relevant to penetration testing in the 2022 version are:
8.8: Management of technical vulnerabilities (the primary vulnerability management control, updated from the 2013 Annex A 12.6.1).
8.29: Security testing in development and acceptance (new in 2022, control explicitly addressing security testing requirements for systems under development.
5.29: Information security during disruption (relevant to business continuity testing, which sometimes intersects with security testing requirements.
Understanding which control is the basis for an auditor's penetration testing expectation matters because each has a different scope, evidence standard, and applicability.
Control 8.8 requires the organisation to obtain information about technical vulnerabilities of information systems being used, evaluate the organisation's exposure to such vulnerabilities, and take appropriate measures to address the associated risk.
What this means for penetration testing: "obtaining information about technical vulnerabilities" includes both passive vulnerability intelligence (CVE feeds, vendor advisories) and active vulnerability assessment through scanning and penetration testing. "Taking appropriate measures" includes remediation, and the remediation must be evidenced.
Auditors reviewing control 8.8 look for: a documented vulnerability management process that specifies how vulnerabilities are identified, assessed, prioritised, and remediated; evidence that the process is operating, not just documented; and technical evidence from actual vulnerability identification activities, which in practice means scan reports, vulnerability assessment reports, and penetration test reports.
The key question auditors ask against 8.8 is: how do you know what vulnerabilities exist in your environment? A policy document stating that vulnerability scanning is conducted is not evidence that it has been conducted. Timestamped scan reports, penetration test reports, and remediation tracking records are.
Frequency expectation: ISO 27001 does not specify vulnerability testing frequency in the control text. Auditors apply judgment based on the organisation's risk assessment. For production systems handling sensitive information, annual penetration testing is the widely accepted minimum, with additional testing following significant changes. An organisation with a documented risk assessment that justifies quarterly testing based on high-risk classification faces an auditor who will verify that quarterly testing actually occurred.
Control 8.29 is new in the 2022 revision and addresses security testing specifically in the context of development and acceptance processes. It requires that security testing programmes and criteria be established for development and acceptance, and that acceptance tests be planned, documented, and executed.
What this means for penetration testing: 8.29 creates a security testing obligation for systems in development and at acceptance milestones, before systems enter production. For software development organisations, this control is directly relevant to whether penetration testing occurs before production deployment, not just as an annual post-deployment exercise.
Auditors reviewing 8.29 look for: documented security testing criteria that specify what testing is required before acceptance; evidence that testing was conducted against those criteria; and records showing that findings were addressed before the system entered production.
For organisations pursuing ISO 27001 certification that have significant active development, 8.29 makes pre-production penetration testing an expectation, not just post-production annual testing. The controls together create a testing cadence that covers both the production environment (8.8) and the development lifecycle (8.29).
The evidence package auditors review for ISO 27001 security testing controls has three components that work together.
The security testing policy or procedure. A documented process defining how security testing is conducted, at what frequency, by whom, covering what scope, and how findings are managed. The policy must be approved by management and version-controlled. Auditors check that the policy exists, that it is current, and that it reflects what the organisation actually does rather than aspirational practice.
Evidence of testing conducted. Penetration test reports from within the relevant period, covering the scope defined in the policy. Auditors check the report date against the audit period, the scope against the ISMS scope, and whether the report contains genuine penetration testing evidence rather than automated scanner output relabelled as a pentest. What is inside a VAPT report and what makes it credible covers what distinguishes a report that satisfies an auditor from one that will generate questions.
Remediation and closure evidence. Auditors do not stop at confirming that testing occurred. They follow through to whether findings were addressed. The remediation tracking record showing each finding's status, remediation action, date, and retest confirmation completes the evidence chain. A penetration test report with ten high-severity findings and no remediation record leaves the auditor uncertain whether the ISMS is actually reducing risk.
One of the most consequential aspects of ISO 27001 auditor practice is what "appropriate measures" means in the context of control 8.8. The standard deliberately leaves this to organisational judgment informed by risk assessment, but auditors apply their own professional judgment about what is appropriate for a given organisation.
For an organisation handling financial transaction data, healthcare records, or significant personal data volumes, "appropriate measures" will typically be interpreted by auditors to require penetration testing rather than just vulnerability scanning. The distinction matters: a vulnerability scan identifies potential vulnerabilities through signature matching; a penetration test confirms which vulnerabilities are exploitable and demonstrates the business impact. For high-risk environments, the latter is what auditors consider appropriate.
This is where the Reddit thread "Facing compliance hurdles with ISO 27001" that appears in the search results originates. Organisations that conducted only vulnerability scanning and assumed it satisfied control 8.8's security testing expectation discover at surveillance or recertification audits that the auditor expected more. The security gaps DAST and standard testing misses covers the ten categories that distinguish genuine penetration testing from scanner-based assessment.
The penetration test scope for ISO 27001 purposes should align with the ISMS scope documented in the organisation's information security management system. If the ISMS scope covers three web applications, the corporate internal network, and two cloud environments, the penetration test scope should cover the same systems, or document a justified reason for any exclusions.
Auditors compare the ISMS scope statement to the penetration test scope. Gaps require explanation. An ISMS that claims to protect customer data processed through a web application, where the web application is out of scope for the penetration test, creates a question that auditors will ask.
What a real web application penetration test should cover maps the twelve dimensions of comprehensive web application testing. For ISO 27001 purposes, any internet-facing system in the ISMS scope should be tested at the application layer, any internal system containing or connected to information assets should be included in internal testing, and any significant API surfaces or cloud infrastructure should be explicitly addressed.
ISO 27001 certification involves an initial certification audit and annual surveillance audits, with a full recertification audit every three years. The question of when penetration testing must have occurred depends on which audit the organisation is preparing for.
Initial certification (Stage 1 and Stage 2): The certification audit evaluates whether the ISMS is implemented and operating effectively. For a first certification, auditors expect evidence that the security testing process has been operational long enough to demonstrate effectiveness. Testing conducted within six months of the Stage 2 audit, with remediation evidence, is generally sufficient.
Surveillance audits (annual): Surveillance audits sample controls from the previous certification period. If penetration testing is in the audit sample, auditors look for evidence that testing occurred within the surveillance period (the year since the previous audit) and that findings were managed. An organisation that has not conducted penetration testing since its initial certification will have a gap the surveillance auditor will note.
Recertification (every three years): Full recertification reviews the entire ISMS. Evidence of security testing across the three-year period is expected, not just recent testing.
The ISO 27001:2022 framework's emphasis on risk-proportionate, ongoing security management creates natural alignment with continuous penetration testing models.
Control 8.8's vulnerability management obligation is ongoing, not annual. A continuous penetration testing model that tests on every significant deployment satisfies the ongoing nature of the control more directly than annual point-in-time testing. Continuous penetration testing and how it differs from annual pentests covers the operational model and how deployment-triggered testing produces evidence of ongoing security validation rather than periodic snapshots.
Control 8.29's development and acceptance testing requirement is satisfied by testing that occurs before production deployment. Agentic testing triggered at the pre-production stage generates findings and remediation evidence that directly satisfies the 8.29 documentation requirement.
The evidence record that continuous agentic testing produces (timestamped assessments, findings, remediation tracking, retest confirmations) is exactly the package that ISO 27001 auditors want to see across a certification period. How autonomous pentesting produces a continuous compliance evidence record covers how this record is generated and how it maps to the control evidence standards ISO 27001 auditors apply. For the foundational agentic testing model, agentic pentesting and continuous security validation covers the full architecture.
Many organisations manage ISO 27001 alongside other compliance frameworks. ISO 27001 certification is frequently pursued alongside or in parallel with SOC 2, PCI DSS, or HIPAA, and a well-scoped penetration test can generate evidence useful across multiple frameworks simultaneously.
For organisations managing ISO 27001 and SOC 2, SOC 2 penetration testing: what auditors actually require covers the Trust Service Criteria that create SOC 2's testing obligation and how they map to ISO 27001's controls. For payment processing organisations, PCI DSS penetration testing requirements explained covers the Requirement 11.4 obligations that layer on top of ISO 27001 with specific frequency and segmentation requirements. For healthcare organisations, HIPAA penetration testing requirements covers the seven gaps specific to HIPAA that go beyond standard ISO 27001 scope.
For penetration testing services and VAPT services structured to produce ISO 27001-compatible evidence, the 10x Pentest platform delivers exploit-proven findings, remediation tracking, and same-day retest confirmation. See pricing or get in touch to discuss structuring a testing program around your ISO 27001 audit cycle. For agentic penetration testing that generates the continuous evidence record ISO 27001 surveillance audits expect, that page covers the delivery model in detail.
Q1. Does ISO 27001 require penetration testing?
ISO 27001 does not mandate penetration testing by name. However, Annex A control 8.8 (Management of technical vulnerabilities) requires organisations to obtain information about technical vulnerabilities and take appropriate measures, and control 8.29 (Security testing in development and acceptance) requires security testing before systems enter production. For organisations handling significant volumes of sensitive data or operating in high-risk environments, accredited certification body auditors typically interpret these controls to require penetration testing as the appropriate evidence of technical vulnerability management. An organisation that conducts only vulnerability scanning without active exploitation testing may find their auditor questioning whether that satisfies "appropriate measures" for their risk level.
Q2. Which ISO 27001 controls relate to penetration testing?
The three controls most directly relevant are: Annex A 8.8 (Management of technical vulnerabilities), which requires active identification and remediation of vulnerabilities in systems in use; Annex A 8.29 (Security testing in development and acceptance), which requires security testing before production acceptance; and Annex A 5.29 (Information security during disruption), which addresses continuity-related testing that can include security scenario testing. Control 8.8 is the primary control that creates penetration testing expectations in most certification audits.
Q3. How often does ISO 27001 require penetration testing?
ISO 27001 does not specify a frequency. The standard's risk-based approach means the appropriate frequency should be determined by the organisation's risk assessment and reflected in the security testing policy. In practice, annual penetration testing is the widely accepted minimum for production systems handling sensitive information. Auditors conducting surveillance audits expect to see testing evidence covering the audit period since the last assessment. For systems undergoing significant changes, control 8.29 creates an additional testing obligation before each production deployment, independent of the annual cycle.
Q4. What is the difference between ISO 27001:2013 and ISO 27001:2022 for penetration testing?
ISO 27001:2013 addressed technical vulnerability management through a single control (Annex A 12.6.1) that required obtaining information about vulnerabilities and taking appropriate measures. ISO 27001:2022 restructured and strengthened this through two distinct controls: 8.8 (continuing the vulnerability management obligation) and 8.29 (explicitly adding security testing requirements for development and acceptance processes). The 2022 revision makes pre-production security testing an explicit requirement rather than an implication of the vulnerability management control, which increases the penetration testing obligation for software development organisations operating under the 2022 version.
Q5. What evidence does ISO 27001 penetration testing need to produce?
The complete evidence package for ISO 27001 security testing controls includes: a documented security testing policy or procedure defining scope, frequency, methodology, and responsibility; penetration test reports from within the relevant audit period, covering systems in the ISMS scope, with findings evidenced through active exploitation rather than scanner output; a remediation tracking record showing the status and resolution of each finding; and retest confirmation showing that critical and high findings were addressed and confirmed closed. Auditors reviewing surveillance or recertification evidence expect all three components, not just the initial test report.
SAST tools catch injection flaws, hardcoded secrets, and insecure patterns early. They cannot catch business logic, runtime behavior, or authorization gaps. Here is exactly where the line falls.
Tejas Dhokane Aug 18, 2026 
IAST instruments the application at runtime to observe security issues during actual execution. This guide explains how it works, where it fits in the AppSec stack, and when to use it.
Tejas Dhokane Aug 18, 2026 
EASM discovers your unknown external exposure continuously. Traditional pentesting confirms what's exploitable in a defined scope on a fixed schedule. Neither is complete without the other.
Tejas Dhokane Aug 18, 2026 Schedule a free consultation and see how teams like yours are strengthening their security posture — continuously.
