ISO 27001 Penetration Testing Requirements
Organisations pursuing ISO 27001 certification often ask: Is penetration testing required? The short answer is yes but with nuance.
ISO 27001:2022 is an international standard for information security management systems (ISMS). It doesn’t actually mandate specific technical controls like penetration testing outright. Instead, it requires organisations to identify and treat risks using appropriate controls, many of which are outlined in Annex A of the standard.
What Are the Controls in ISO 27001 Where Penetration Testing May Be Applicable?
| Control | Purpose | Applicability of Penetration Testing |
|---|---|---|
| A5.35 Independent review of information security | To ensure the continuing suitability, adequacy and effectiveness of the organisation's approach to managing information security. | A penetration test by a third party can form a type of review that is conducted by individuals independent of the area under review. |
| A5.8 Information security in project management | To ensure information security risks related to projects and deliverables are effectively addressed in project management throughout the project life cycle. | Depending on the project, penetration testing can be integrated as a part of projects to gain assurance that information security requirements have been implemented. |
| A8.8 Management of technical vulnerabilities | To prevent exploitation of technical vulnerabilities. | Penetration testing can help with identifying technical vulnerabilities. |
| A8.16 Monitoring activities | To detect anomalous behaviour and potential information security incidents. | Penetration testing can be used to validate the effectiveness of your monitoring systems. |
| A8.26 Application security requirements | To ensure all information security requirements are identified and addressed when developing or acquiring applications. | Penetration testing can be integrated as a part of application development to gain assurance that information security requirements have been implemented. |
| A8.25 Secure development life cycle | To ensure information security is designed and implemented within the secure development life cycle of software and systems. | Penetration testing can be a component of a greater system of testing in the SDLC. |
| A8.29 Security testing in development and acceptance | To validate if information security requirements are met when applications or code are deployed to the production environment. | Penetration testing can identify insecure code and design issues. |
Can you meet those controls without performing penetration testing?
Possibly yes.
For example, an organisation might implement static application security testing (SAST), and regular vulnerability scanning to demonstrate security testing is performed in development (A8.29). These tools can help identify common coding issues, misconfigurations, and known vulnerabilities early in the software development lifecycle.
What do Most Companies Do?
Automated tooling currently falls a bit short for organisations that require higher levels of assurance. Tools may miss complex business logic flaws, chained vulnerabilities, or context-specific risks that a human attacker could exploit. As a result of this gap, an auditor may expect to see evidence of penetration testing to provide greater assurance that security controls are present and effective.
Most companies opt to perform penetration testing at least annually, or after major system changes, as part of their ISMS.
Need to align your testing approach with ISO 27001? Get in touch!
