Penetration Testing and ISO/IEC 27001:2022 - Requirements, Controls and Practical Evidence

Rick Grassmann

September 23, 2026

Directly related ISO controls

Indirectly related ISO controls

Incident response controls

Scope of the ISO 27001 pentest program

Conclusion

Abstract

ISO/IEC 27001:2022 does not prescribe penetration testing as a standalone requirement for every organization. However, penetration testing can provide valuable evidence for the implementation and effectiveness of several information security controls, particularly in the areas of technical vulnerability management, security testing during development and acceptance, network security, application security, monitoring, and incident response.

This article examines where penetration testing can contribute to an ISO/IEC 27001:2022 Information Security Management System (ISMS), which controls are most directly associated with it, and where other forms of security testing or assurance are more appropriate. It also distinguishes conventional penetration testing from adversary simulation, red teaming, purple teaming and incident-response exercises, which may provide different types of evidence.

The analysis is based on ISO/IEC 27001:2022, with ISO/IEC 27002:2022 used as implementation guidance for the Annex A controls. The central question is therefore not simply if ISO 27001 requires a penetration test, but how an organization can determine when penetration testing is an appropriate part of its risk-based security-testing program.

Three different questions should not be confused

1. Does the control apply? This is determined through the organization's ISMS, risk treatment and applicable requirements.
2. Is penetration testing an appropriate way to test part of it? This depends on the control objective, system, risk and test scope.
3. Does the test demonstrate that the control is effective? Only to the extent that the test objectives, scope, methodology and evidence actually address the relevant control requirements.

A.8.8: Management of technical vulnerabilities

A.8.8 requires the organization to obtain information about technical vulnerabilities, evaluate its exposure to them, and take appropriate measures in response. Penetration testing can contribute to this process by providing evidence about how identified or suspected vulnerabilities can be exploited in the context of the organization's actual systems and security controls.

Depending on its scope and objectives, a penetration test can help determine:

• whether identified vulnerabilities are practically exploitable;
• whether multiple weaknesses can be combined into a meaningful attack path;
• whether compensating security controls prevent or limit exploitation;
• what systems, accounts or information may be reachable following an initial compromise;
• whether privilege escalation or lateral movement is possible;
• whether sensitive information or protected functionality can actually be accessed; and
• whether remediation or mitigation measures have addressed the tested attack path under the retest conditions.

ISO/IEC 27002 identifies penetration testing as one possible measure that can support technical-vulnerability management. It is, however, only one component of the broader process. Vulnerability intelligence, vulnerability identification and scanning, risk assessment, patching, configuration changes, compensating controls and remediation are also relevant to A.8.8. A penetration test therefore provides additional technical evidence; it does not replace the organization's entire vulnerability-management process.

Practical conclusion: Where the organization's risk profile includes significant internet-facing systems, applications, APIs, cloud infrastructure or sensitive information, penetration testing can provide useful evidence for A.8.8, particularly where the organization needs to understand exploitability, attack paths or the effectiveness of remediation and compensating controls.

A.8.29: Security testing in development and acceptance

A.8.29 requires security-testing processes to be established and implemented during the development life cycle. ISO/IEC 27002 describes a range of possible security-testing techniques, including penetration testing, vulnerability assessment, source-code analysis, code review and other forms of testing.

Penetration testing can therefore form part of the security-testing activities performed before a system or significant change is accepted into production. The appropriate testing method and depth should be determined by the security requirements, architecture, changes introduced and risks associated with the system.

Examples of situations in which targeted penetration testing may provide useful evidence include:

• New application: Before accepting a new externally accessible application into production, an application or API penetration test can provide evidence about selected security requirements and attack scenarios.
• Major application change: A significant change to architecture, authentication, authorization, trust boundaries or data flows may justify targeted security testing proportionate to the change.
• New API: APIs may require specific testing of authentication, authorization, object-level access controls and data exposure that may not be adequately demonstrated by automated vulnerability scanning alone.
• Major release: For systems with significant security risks, penetration testing can form part of the evidence considered during security acceptance and release decisions.
• Security-sensitive functionality: Functionality involving authentication, password resets, authorization, administrative operations, payment processing, file uploads, data exports or other security-sensitive business logic may warrant targeted security testing.

Practical conclusion: A.8.29 provides a direct basis for incorporating penetration testing into an organization's security-testing program where penetration testing is an appropriate method for the system, change or security requirements being assessed. It does not, however, establish penetration testing as a mandatory test for every application or release.

Clause 6.1.3: Information security risk treatment

Clause 6.1.3 requires the organization to determine the controls necessary to treat its information security risks and to document the resulting decisions in the Statement of Applicability (SoA). The controls selected for risk treatment are determined by the organization's risk assessment and treatment process rather than by treating every Annex A control as universally mandatory.

Penetration testing can therefore become part of an organization's defined risk treatment. For example:

• Risk: An internet-facing application may permit unauthorized access to customer information.
• Treatment: Implement secure-development controls, technical-vulnerability management and periodic penetration testing.

Once penetration testing has been selected as a risk-treatment measure or otherwise incorporated into the organization's ISMS commitments, the organization needs to implement it as defined and retain appropriate evidence. Conversely, an organization may select other measures where its risk assessment and treatment decisions provide an appropriate basis for doing so.

Practical conclusion: Clause 6.1.3 does not independently require penetration testing. It provides the mechanism through which penetration testing may become a defined part of the organization's risk treatment and ISMS.

Clause 9.1: Monitoring, measurement, analysis and evaluation

Clause 9.1 requires the organization to determine what information security processes and controls need to be monitored and measured, how and when they will be measured, and how the results will be analyzed and evaluated. Documented evidence of the results is retained.

Penetration testing can contribute to this measurement and evaluation where the organization has defined testing as an appropriate source of evidence. For example, possible indicators or measures may include:

• the proportion of identified critical applications tested within the defined period;
• the number or proportion of critical findings remediated within the organization's defined timeframe;
• the number of exploitable high-risk findings identified through testing;
• time taken to remediate penetration-testing findings; and
• the proportion of remediation measures successfully verified through retesting.

These metrics measure different aspects of the organization's security-testing and remediation processes; they should not be treated as universal ISO 27001 metrics. The appropriate measures depend on what the organization has decided to monitor and evaluate.

Practical conclusion: Clause 9.1 does not itself require a penetration test. Where penetration testing forms part of the organization's defined measurement and evaluation approach, the resulting findings and metrics can provide evidence for the effectiveness of selected security controls and processes.

A.5.35: Independent review of information security

A.5.35 requires an independent review of the organization's approach to managing information security at planned intervals or when significant changes occur. A penetration test can contribute technical evidence to such a review, particularly when the testing is performed by a suitably independent party.

However, a penetration test is not automatically equivalent to an independent review. A conventional penetration test is primarily a technical assessment of selected systems and attack scenarios, whereas an independent review may consider the broader effectiveness and suitability of the organization's information security approach.

A suitably independent penetration test can therefore contribute two useful forms of evidence:

• technical evidence about exploitable weaknesses within the defined test scope; and
• independent evidence about selected aspects of the organization's security controls and their implementation.

The extent to which the test contributes to A.5.35 depends on its independence, scope, objectives and reporting. A third-party penetration test should therefore not be presented as automatically satisfying the control.

Practical conclusion: A penetration test can support an independent review, but it does not replace the broader review required by A.5.35 unless the review has been deliberately designed to address the relevant requirements.

A.5.36: Compliance with policies, rules and standards

A.5.36 concerns compliance with the organization's own information security policies, rules and standards, as well as applicable external requirements. This creates an important distinction between what ISO/IEC 27001 itself requires and what the organization has chosen to require through its own policies and procedures.

For example, an organization's security policy might state that internet-facing applications shall undergo penetration testing at defined intervals and following significant security changes. Once such a requirement has been established, the organization needs to demonstrate that it is being followed.

Penetration-testing reports, schedules, remediation records and retest results can provide evidence that the organization's defined testing requirements are being implemented. Conversely, if the organization has not established penetration testing as a policy or other requirement, A.5.36 does not independently create such an obligation.

Practical conclusion: A.5.36 can make penetration testing auditable where the organization has included it in its own policies, rules or standards. The resulting evidence demonstrates compliance with the organization's defined requirements rather than a standalone ISO 27001 requirement to perform a penetration test.

A.8.25: Secure development life cycle

A.8.25 addresses the integration of information security throughout the development life cycle. Penetration testing can support this process by providing security evidence at appropriate points in the lifecycle, but it is only one component of the overall development-security process.

Depending on the organization's development process and risk profile, security activities may include:

• Design: threat modeling and security architecture review;
• Development: secure coding practices, source-code review and automated security analysis;
• Pre-production: vulnerability assessment and dynamic application security testing;
• Acceptance: targeted penetration testing where appropriate;
• Production: ongoing vulnerability management and security monitoring; and
• Major changes: targeted security testing or retesting proportionate to the change.

The appropriate combination of techniques depends on the system, development methodology, security requirements and associated risks. A penetration test should therefore be viewed as one potential assurance activity within the SDLC, rather than as a substitute for the other security activities required throughout the lifecycle.

Practical conclusion: A.8.25 provides the broader lifecycle context in which penetration testing may be used. A.8.29 addresses security testing more specifically; A.8.25 establishes that security needs to be considered throughout the development life cycle rather than only immediately before release.

A.8.9: Configuration management

A.8.9 concerns the establishment, implementation and monitoring of appropriate configurations for systems, networks and other technology. Penetration testing can provide additional evidence about whether configuration weaknesses can be exploited in practice.

Depending on the scope of the test, findings may include:

• unnecessary exposed services;
• insecure TLS configurations;
• default or weak credentials;
• excessive permissions;
• insecure cloud configurations;
• exposed management interfaces;
• unexpected network reachability; and
• security-control bypasses resulting from configuration weaknesses.

Some of these issues may be identified through vulnerability scanning, configuration assessment or other technical controls. A penetration test can add a different type of evidence by attempting to determine whether a configuration weakness can actually be used to reach a protected system, account or function.

Practical conclusion: A.8.9 does not require penetration testing. Where configuration weaknesses could materially affect the organization's attack surface or security boundaries, targeted penetration testing can provide useful additional evidence about their practical security impact.

A.8.20: Network security

A.8.20 addresses the security of networks and network devices. Penetration testing can provide evidence about whether the technical controls enforcing the intended network architecture operate as expected in practice.

For example, an organization may define an architecture in which traffic flows from the Internet through a firewall and DMZ to an application layer, while the database layer is intended to be inaccessible directly from the Internet. A suitably scoped penetration test can attempt to determine whether those intended restrictions can actually be bypassed.

Depending on the test objectives, testing may examine:

• firewall and network-access rules;
• network segmentation and routing;
• exposed services and interfaces;
• lateral movement between network zones;
• VPN and remote-access controls;
• administrative interfaces;
• trust relationships between systems or network zones; and
• network access controls.

A penetration test does not by itself establish that the entire network-security control is effective. Its evidential value depends on the networks, systems, paths and restrictions included in the test.

Practical conclusion: A.8.20 does not explicitly require penetration testing, but targeted testing can provide useful evidence that selected network-security restrictions are effective against realistic attack paths.

A.8.22: Segregation of networks

A.8.22 concerns the segregation of networks where separation is necessary to protect information and systems. This is a useful area for targeted attack-path testing because the organization may need to demonstrate not only that network boundaries exist, but that they restrict unintended access.

For example, where production systems are intended to be isolated from development systems, a suitably scoped assumed-breach or penetration test could examine an attack path such as:

• compromise a workstation or other defined starting point;
• attempt access to the development network;
• attempt to cross the boundary into production; and
• attempt to reach privileged infrastructure where this is within scope.

This type of testing can provide evidence about the effectiveness of the technical separation under the tested conditions, rather than relying solely on network diagrams or configuration documentation.

Practical conclusion: A.8.22 does not require penetration testing. Where network segregation is an important risk treatment, targeted testing can provide useful evidence that the intended boundaries prevent the attack paths included within the test scope.

A.8.31: Separation of development, test and production environments

A.8.31 concerns the separation of development, testing and production environments. Penetration testing can contribute evidence by examining whether an attacker who gains access to one environment can cross the intended boundaries into another.

The relevant question is therefore not only whether separate environments exist, but whether the technical and access controls separating them resist unintended access. Depending on the architecture, testing may examine:

• network reachability between environments;
• shared credentials or authentication mechanisms;
• IAM relationships and excessive permissions;
• shared secrets and other credentials;
• CI/CD permissions and deployment paths;
• cloud roles and trust relationships;
• exposure of production data to non-production environments; and
• administrative interfaces accessible across environment boundaries.

A targeted attack-path test can complement architecture reviews, configuration assessments and access-control reviews by testing whether selected separation mechanisms withstand an attempted compromise. The test should be scoped carefully because production systems, development systems and deployment infrastructure may have different authorization and operational constraints.

Practical conclusion: A.8.31 does not require a penetration test. Where separation between environments is a significant security boundary, targeted penetration or assumed-breach testing can provide additional evidence about the effectiveness of that separation.

A.8.32: Change management

A.8.32 requires changes to information-processing facilities and systems to be managed through an appropriate change-management process. Security testing can form part of that process where a change could materially affect the organization's security posture.

A typical process for a significant change may therefore be:

Major change → Risk assessment → Security impact assessment → Appropriate security testing → Acceptance → Production

The appropriate testing method should depend on the nature and risk of the change. A penetration test may be appropriate where the change introduces a new attack surface, modifies a security boundary or materially changes authentication, authorization or other security-sensitive functionality. In other cases, a vulnerability assessment, configuration review, code analysis or other targeted security test may be more appropriate.

Examples of changes that may justify targeted penetration testing include:

• introducing a new authentication mechanism;
• migrating systems or applications to a new cloud platform;
• exposing a previously internal application to the Internet;
• changing the authorization architecture;
• introducing a new API gateway or other security boundary;
• performing a major database migration; and
• changing network segmentation or trust relationships.

Practical conclusion: A.8.32 does not require a penetration test for every change. It provides a change-management context in which security testing, including targeted penetration testing, can be required by the organization's risk assessment and security impact assessment.

A.8.34: Protection of information systems during audit testing

A.8.34 addresses the protection of information systems during audit testing and other assurance activities involving operational systems. It is therefore relevant when a penetration test forms part of such an assurance activity, particularly where testing could affect availability, integrity or confidentiality.

For a production penetration test, the organization should thus establish appropriate controls around the activity before testing begins. Depending on the scope and risk of the test, this may include documented:

• authorization and ownership of the test;
• scope and test objectives;
• systems, IP addresses, domains or applications included in the test;
• systems and activities explicitly excluded from the test;
• testing windows and operational constraints;
• prohibited or restricted techniques;
• technical and management escalation contacts;
• criteria and procedures for suspending the test;
• rules of engagement;
• handling and protection of sensitive test data; and
• procedures for dealing with an incident or unexpected impact during testing.

The exact controls should be proportionate to the test and the systems involved. A.8.34 does not establish penetration testing as a requirement. Instead, where audit or assurance testing is performed against operational systems, the activity itself needs to be planned and controlled so that the testing does not create unacceptable risk.

Practical conclusion: A.8.34 is primarily relevant to the safe execution of a penetration test rather than to the decision whether a penetration test is required. It can therefore provide an important framework for governing intrusive testing of production systems.

A.8.26: Application security requirements

A.8.26 concerns the identification and specification of information security requirements for applications. Penetration testing can provide evidence about whether selected security requirements are enforced by the implemented application.

For example, if an application requirement states that users must not be able to access another tenant's records, a test case could explicitly attempt:

Tenant A session → Attempt access to Tenant B objects → Expected result: access denied.

GET /api/accounts/tenant-b/invoices/4821
Authorization: Bearer <tenant-a-test-token>

HTTP/1.1 403 Forbidden

Security requirement: A user authenticated in Tenant A is unable to access objects belonging to Tenant B.

Similar testing can be designed around requirements relating to:

• authentication;
• authorization and access control;
• session management;
• protection of sensitive data;
• administrative functions;
• input handling and validation; and
• security-relevant logging and monitoring.

This creates a useful traceability chain:

Security requirement → Implementation → Test case → Test result → Evidence

A penetration test will not necessarily cover every application-security requirement. Requirements should therefore be mapped to appropriate verification methods, with penetration testing used where it is an effective way of testing the requirement in question.

Practical conclusion: A.8.26 does not require penetration testing. Where application-security requirements can be meaningfully tested through realistic attack scenarios, penetration testing can provide concrete evidence about their implementation.

A.8.28: Secure coding

A.8.28 addresses secure coding principles and practices. Penetration testing can identify vulnerabilities that result from weaknesses in application code and can demonstrate their potential security impact.

Depending on the application and test scope, examples may include:

• SQL injection;
• command injection;
• cross-site scripting (XSS);
• insecure deserialization;
• path traversal;
• server-side request forgery (SSRF);
• authorization flaws;
• insecure direct object references or equivalent object-access-control weaknesses; and
• business-logic vulnerabilities.

These findings can provide evidence about the security consequences of coding weaknesses, but a penetration test is not a substitute for the secure-coding practices themselves. It may identify a vulnerability after implementation without demonstrating whether secure coding standards, code reviews or developer security practices are consistently being followed.

A comprehensive approach can therefore combine secure-coding standards and developer guidance with activities such as code review, static analysis, dependency analysis, dynamic application testing and penetration testing. The appropriate combination depends on the application, development process and associated risks.

Practical conclusion: A.8.28 does not require penetration testing. Penetration testing can provide useful evidence about security weaknesses resulting from application code, while other development-security activities provide evidence that secure coding practices are being applied systematically.

A.8.30: Outsourced development

A.8.30 addresses the security of outsourced software development. Where software is developed by a third party, penetration testing can provide additional technical evidence about the security of the delivered system and whether selected security requirements have been implemented effectively.

This can be particularly useful where contractual or supplier documentation states that secure-development practices are being followed. A penetration test can provide evidence about the resulting application, rather than relying solely on the supplier's description of its development processes.

The test should, however, be considered alongside other supplier-assurance measures such as contractual security requirements, development standards, security documentation, assurance reports and appropriate review activities. A penetration test cannot establish by itself that the supplier's overall development process is secure.

Practical conclusion: A.8.30 does not require penetration testing. Where outsourced software represents a significant security risk, penetration testing can provide additional technical evidence about the security of the delivered system and the effectiveness of selected security requirements.

A.5.23: Information security for use of cloud services

A.5.23 addresses information security in the acquisition, use, management and termination of cloud services. Penetration testing can contribute to the assessment of cloud-hosted systems and services where the organization is responsible for the relevant components and is authorized to test them.

Depending on the cloud architecture and the organization's responsibilities, testing may include:

• cloud-hosted applications and APIs;
• identity and access management;
• storage access controls;
• tenant or workload isolation;
• exposed management interfaces;
• security-group and network-access configuration;
• serverless functions; and
• containerized environments.

Cloud testing requires particular attention to authorization and the shared-responsibility model. An organization cannot assume that it is permitted to perform arbitrary intrusive testing against infrastructure operated by a cloud provider. The provider's testing policies, contractual terms and technical restrictions must be considered before testing begins.

The scope should therefore distinguish between components controlled by the organization, components operated by the provider and any other systems for which explicit authorization is required.

Practical conclusion: A.5.23 does not require cloud penetration testing. Where testing is appropriate, it should be performed only within the organization's responsibility and the permissions granted by the relevant cloud provider and other parties.

A.8.16: Monitoring activities

A.8.16 concerns monitoring activities intended to detect anomalous behavior and other relevant security events. Penetration testing can contribute to this control when the test is specifically designed to assess whether simulated attack activity is detected and handled appropriately.

For example, an assumed-breach or adversary-simulation exercise may follow an attack path such as:

Simulated attack → Telemetry generated → Detection rule triggered → Alert generated → Security team investigates → Incident process initiated

This can provide evidence about different parts of the detection chain, including whether relevant activity generates telemetry, whether detection mechanisms identify it, and whether alerts are appropriately investigated and escalated.

A conventional vulnerability-focused penetration test may identify exploitable weaknesses without deliberately testing the organization's monitoring and response capabilities. The test objectives therefore need to be designed around the monitoring questions the organization wants to answer.

Practical conclusion: A.8.16 does not require penetration testing. Appropriately designed attack simulation can provide evidence about the effectiveness of selected monitoring and detection capabilities, particularly when the exercise is coordinated with the relevant security or incident-response teams.

A.5.7: Threat intelligence

A.5.7 concerns the collection and analysis of information about information security threats to produce relevant and actionable threat intelligence. Threat intelligence can also be used to make penetration-testing objectives more closely aligned with the organization's threat environment.

For example, intelligence relevant to the organization's sector or technology environment may indicate increased exposure to:

• credential attacks;
• exploitation of exposed remote-access services;
• specific application vulnerabilities;
• supply-chain compromise;
• cloud identity attacks; or
• other attack techniques relevant to the organization's systems.

Such information can be used to develop realistic test scenarios and prioritize particular attack paths:

Threat intelligence → Relevant threat scenarios → Penetration-test objectives → Test evidence → Risk treatment

The penetration test itself does not satisfy A.5.7. Rather, threat intelligence can provide an input into deciding what should be tested and why. This helps ensure that security testing is connected to the organization's current threat environment rather than being based solely on a generic testing checklist.

Practical conclusion: A.5.7 does not require penetration testing. Threat intelligence can, however, be used to inform the scope, scenarios and priorities of penetration testing and other security-assurance activities.

Security testing can also be deliberately designed to exercise incident-response capabilities. A controlled attack exercise can examine whether an organization can progress from simulated attack activity through detection, alerting, triage, escalation, containment and subsequent learning.

This is, however, different from a conventional vulnerability-focused penetration test. Once the primary objectives include testing the organization's detection and response capabilities, the activity is more appropriately described as an assumed-breach exercise, adversary simulation, red-team exercise or incident-response exercise, depending on its scope and methodology.

A.5.24: Information security incident management planning and preparation

A.5.24 concerns the establishment and preparation of the organization's information security incident-management process, including relevant roles, responsibilities, communication arrangements and supporting procedures.

A controlled attack exercise can provide evidence about whether those preparations work in practice. For example, an authorized assumed-breach exercise could examine what happens when simulated malicious activity is detected:

Simulated attack → Detection → Event assessment → Escalation → Response → Containment

The exercise may examine:

• incident-response roles and responsibilities;
• contact and escalation procedures;
• SOC or CSIRT readiness;
• availability of appropriate personnel;
• communication channels;
• incident-response playbooks;
• authorization boundaries;
• coordination between security, IT, management and other relevant functions; and
• readiness to invoke business-continuity or crisis-management processes where appropriate.

Incident-management exercises can therefore provide evidence about whether documented preparations are understood and usable under realistic conditions. The exercise must be appropriately authorized and designed so that it does not create unacceptable operational risk.

Practical conclusion: A.5.24 does not require a penetration test. An appropriately designed attack simulation or incident-response exercise can provide evidence about the organization's practical readiness and the effectiveness of its incident-management preparations.

A.5.25: Assessment and decision on information security events

A.5.25 concerns the assessment and classification of information security events, including the criteria used to determine whether an event constitutes an information security incident and how incidents are prioritized and handled.

An appropriately designed attack exercise can generate realistic security events against which this process can be tested. Depending on the exercise objectives, these may include:

• credential attacks;
• privilege-escalation activity;
• unusual authentication;
• suspicious network connections;
• exploitation attempts;
• lateral movement;
• abnormal access to sensitive information; and
• persistence or other post-compromise activity.

The objective can be to determine whether the security team:

1. detects the relevant events;
2. correlates related activity;
3. understands its significance;
4. assigns the appropriate classification or priority; and
5. escalates the matter according to the defined procedures.

A conventional vulnerability penetration test that identifies a vulnerability does not, by itself, demonstrate that this event-assessment process is effective. The test must generate and observe relevant security events and evaluate how the organization handles them.

Practical conclusion: A.5.25 does not require penetration testing. Attack simulation can contribute evidence where the exercise is specifically designed to test event detection, assessment, classification and escalation.

A.5.26: Response to information security incidents

A.5.26 concerns the organization's ability to respond to information security incidents in accordance with established procedures. Relevant response activities can include containment, evidence preservation, investigation, escalation, documentation and communication.

A controlled adversary-simulation or assumed-breach exercise can test these capabilities in practice. For example, an authorized exercise might provide the response team with evidence of a simulated compromised workstation while the simulated attacker performs predefined activities within the agreed scope. The response team may then need to:

• identify and isolate the affected endpoint;
• determine the scope of the simulated compromise;
• preserve relevant evidence;
• investigate authentication and other security activity;
• identify affected accounts or systems;
• escalate the incident appropriately;
• communicate with relevant stakeholders; and
• restore or recover affected systems where appropriate.

This produces a different type of evidence from a conventional penetration test. A vulnerability-focused test may demonstrate that an attacker can obtain privileged access. An adversary-simulation exercise can additionally examine whether the organization detects the activity, investigates it and takes appropriate response actions.

Practical conclusion: A.5.26 does not require a penetration test. To provide meaningful evidence for incident-response capabilities, testing should be explicitly designed to exercise the organization's response processes rather than merely identify technical vulnerabilities.

A.5.27: Learning from information security incidents

A.5.27 concerns using knowledge gained from information security incidents and related activities to improve information security controls and reduce the likelihood or impact of future incidents. The same principle can be applied to lessons identified through security exercises and penetration testing.

Testing can therefore form part of a continuous improvement cycle:

Penetration test / attack exercise → Observed attack path and results → Detection and response performance → Weaknesses identified → Root-cause analysis → Control improvements → Updated procedures → Retest or follow-up exercise

This allows the organization to consider not only which vulnerabilities were identified, but also why they existed, whether existing controls operated as intended, how the organization responded, and what changes are necessary to reduce the likelihood or impact of similar events.

The learning process should also consider successful outcomes. If an exercise demonstrates that an attack was detected, escalated and contained as intended, that provides evidence about controls and procedures that are working effectively and should be retained or further strengthened.

Practical conclusion: A.5.27 does not require penetration testing. Penetration tests, adversary simulations and incident-response exercises can all contribute to the learning process when their findings are analyzed, translated into appropriate improvements and followed up where necessary.

Classifications

Organizations should not treat all forms of penetration testing and security testing as the same assurance activity. Different methods can provide evidence about different security objectives:

• Vulnerability / infrastructure pentest: Can provide evidence relevant to A.8.8, A.8.20, A.8.22 and related controls by testing whether technical weaknesses, exposed services, access restrictions or network boundaries can be exploited.
• Application pentest: Can provide evidence relevant to A.8.25, A.8.26, A.8.28, A.8.29 and related controls by testing whether selected application security requirements and controls withstand realistic attack scenarios.
• Adversary simulation: Can provide evidence relevant to A.5.24-A.5.27 and A.8.16 when the exercise is designed to test whether an organization can detect, assess, respond to and learn from realistic attack activity.
• Purple-team exercise: Can provide evidence relevant to A.5.25, A.5.26, A.5.27 and A.8.16 by combining simulated offensive activity with defensive observation, detection and response improvement.
• Incident-response tabletop: Can provide evidence relevant to A.5.24-A.5.27 by exercising people, roles, communications, procedures and decision-making without necessarily conducting technical exploitation.

These distinctions matter because a conventional vulnerability-focused penetration test should not automatically be presented as evidence that A.5.24-A.5.27 are fully implemented. A test can provide evidence relevant to a control only where its scope, objectives and methodology deliberately exercise aspects of that control.

What ISO 27001 does not establish

Several commonly repeated claims about penetration testing should therefore be treated carefully. ISO/IEC 27001:2022 does not establish a universal rule such as:

• "You must conduct an external penetration test once per year."
• "Every application must receive a pentest."
• "The test must be performed by a CREST-certified company."
• "The test must be external."
• "A vulnerability scan is always insufficient."

Such requirements can arise from an organization's risk treatment, internal policies, contractual commitments, regulatory or legal requirements, customer requirements, or other applicable obligations. They should not be presented as universal requirements of ISO/IEC 27001:2022 itself.

The organization determines which controls are necessary for its risk treatment and records the resulting decisions in the Statement of Applicability. Where penetration testing is selected as a risk-treatment measure or other ISMS commitment, the organization should define the relevant scope, objectives, frequency and evidence requirements and then implement them as specified.

The absence of a universal ISO/IEC 27001 penetration-testing requirement therefore does not mean that penetration testing is unnecessary. It means that its applicability, scope and frequency are determined in the context of the organization's risks, systems, security requirements and other applicable obligations.

ISO/IEC 27001:2022 does not impose a universal requirement to perform penetration testing as a standalone activity. Instead, penetration testing should be considered as part of the organization's risk-based approach to security testing and assurance.

The analysis shows that penetration testing can contribute evidence to a range of ISO/IEC 27001:2022 controls. The relationship is particularly direct for technical-vulnerability management and security testing in development and acceptance, while other controls may benefit from targeted testing where the test objectives correspond to the control requirements. For monitoring, incident management and response, conventional penetration testing may need to be supplemented or replaced by appropriately designed adversary-simulation, red-team, purple-team or incident-response exercises.

The important distinction is that a penetration test does not automatically satisfy a control simply because the test is technically relevant to it. The scope, objectives, methodology and resulting evidence must correspond to what the organization is trying to demonstrate. Likewise, ISO/IEC 27001 does not prescribe a universal testing frequency, tester certification, external testing requirement or requirement to test every application.

Ultimately, the appropriate penetration-testing program depends on the organization's information security risks, technology, development processes, applicable requirements and chosen risk treatments. Where penetration testing is selected as part of those measures, the organization should be able to demonstrate why it is performed, what it is intended to establish, how the testing is controlled, and how the resulting findings are addressed and verified.

ISO/IEC 27001:2022 provides the requirements for the Information Security Management System (ISMS), while ISO/IEC 27002:2022 provides implementation guidance for the Annex A controls. Keeping that distinction clear is essential when determining what ISO/IEC 27001 actually requires and what penetration testing can contribute as evidence of effective security controls.