ISO 27001 penetration testing: what 8.8 and 8.29 ask for
No control in ISO/IEC 27001:2022 is called penetration testing. Two Annex A controls are where auditors look for one: 8.8 on technical vulnerabilities and 8.29 on security testing. Below, both are paraphrased, with the records a continuous pentest leaves for each and the questions only your auditor can settle.
What ISO 27001 asks for
ISO/IEC 27001:2022 sets the requirements for an information security management system (ISMS). Its Annex A lists 93 controls. You choose the ones your risk assessment calls for and record each choice, with the reason, in your Statement of Applicability (clause 6.1.3 d). The guidance on how to implement each control is in a companion standard, ISO/IEC 27002:2022.
The control texts are ISO's copyright, so here are the three a pentest touches, in our words:
- 8.8Management of technical vulnerabilities
- Get information about technical vulnerabilities in the systems you use, evaluate how exposed you are, and take appropriate measures. A pentest can find vulnerabilities in your own code, which no vendor advisory covers.
- 8.29Security testing in development and acceptance
- Define security testing processes and run them inside the development life cycle, for new systems and for changes to existing ones.
- 8.34Protection of information systems during audit testing
- Plan any test of operational systems and agree it with the right management before it runs. This is where your signed authorization for the pentest belongs.
None of the three sets an interval or names a method. Your risk assessment decides both, and the auditor checks that you did what your own process says.
How a continuous pentest maps to 8.8 and 8.29
ISO 27001 is a management system standard, so the auditor wants to see a process running and the records it leaves behind.
8.29 puts security testing inside the development life cycle. If you release every week and pentest once a year, most of what reached production went out without one. On Rheono's continuous plans, an intensive pass starts after each release, against the web app and API named in your written scope, so each change is tested once it ships. The checks you run before release, such as code review and staging tests, stay part of your own process. The hunt adds an attacker's view of what went live, and each run is dated in your portal. On Starter, the record is one deep hunt a month.
For 8.8, the auditor follows a vulnerability from discovery to closure. Rheono gives each finding a CVSS score and a working proof of concept, files it as a ticket in your tracker if you connect one, and retests it after your fix. The retest result goes into the next signed report, so the closure has its own evidence.
For 8.34, the authorization you sign before the first run names the hosts, the test window and the exclusions, with the rules of engagement. It is valid for 90 days.
What the report gives your auditor
- Scope and test window, matching the authorization you signed
- Method, including the verification bar every finding cleared before it shipped
- Each finding with CVSS, CWE, a working proof of concept, a remediation and the Annex A controls it bears on
- A dated retest result for every finding you fixed
- Signature: Advanced electronic signature (eIDAS, PAdES-B-T) + RFC 3161 timestamp
- An evidence pack with a findings register and a SHA-256 manifest, ready to file with your ISMS records
The sample report shows the format with made-up data, including the Annex A references on a finding.
What your auditor still decides
An accredited certification body audits your ISMS and issues the certificate. Rheono is not one, and does not audit or certify you. Your auditor decides:
- whether your Statement of Applicability justifies the controls you chose
- whether the pentest scope matches the risks your assessment found
- whether the findings were treated in line with your risk treatment plan
- what else 8.8 needs, such as patch records and an asset inventory, which a pentest does not replace
Where cSquare GRC fits
The report is one input to your ISMS. cSquare GRC, our GRC partner, runs your ISO 27001 program: it maps the signed report to 8.8, 8.29, 8.34 and any other control in your Statement of Applicability, tracks each fix until the retest closes it, and gives your auditor a read-only workspace.
Rheono's part ends at the signed report and the retests. The pentest-to-audit page shows who owns each step and what proves it happened.
ISO 27001 pentest questions
- Does ISO 27001 require a penetration test?
- No Annex A control is named for one. Auditors look for testing evidence under 8.8 and 8.29, and for a web application a pentest is a common way to provide it. Your risk assessment decides whether you need one and how often.
- How often should we run one?
- The standard sets no interval. Your risk assessment and your release pace should set it, and the auditor checks that you follow your own process. Testing after each release keeps the evidence current from one audit to the next.
- Does the signed authorization help with 8.34?
- Yes. It records the scope, the test window, the exclusions and the rules of engagement, agreed before anything runs, which is the planning and agreement 8.34 asks for. It is valid for 90 days.
- Is the report enough on its own for 8.8?
- Your auditor decides. Expect them to read the pentest report next to your vulnerability process, patch records and risk treatment decisions, because 8.8 covers all of them.
- Do you test anything beyond the web app and API?
- No. Rheono tests web apps and APIs inside the written scope. If your Statement of Applicability needs internal network, cloud configuration or physical testing, plan that separately.
See what a hunt finds on your own app first.
The free check is read-only and takes about 20 minutes. A researcher confirms before it starts, and the report arrives by email.