ISO/IEC 27001:2022 does not require a penetration test. It does not name the method, and it sets no frequency. What it requires is that security testing is defined and carried out, under Annex A control A.8.29, and that technical vulnerabilities are found, assessed and acted on, under A.8.8. Your risk assessment and your Statement of Applicability decide the rest. In practice an independent test is the evidence certification auditors accept most readily against both controls, and the report has to be structured so they can read it as evidence rather than as a story.
Your Stage 2 audit is booked. The certification body sends its evidence request and somewhere in it is a line about security testing. You have a scanner running in CI and a spreadsheet of tickets, and you are not sure whether that is the answer.
This is where most first-time ISO 27001 candidates get stuck, and the confusion is reasonable, because the standard genuinely does not tell you what to do here. Here is what the two relevant controls actually ask for, what the auditor checks when they open the report, and how to scope and time the test so it lands inside the audit rather than beside it.
Does ISO 27001 Require a Penetration Test?
No. This is the first thing to get straight, because plenty of vendors sell the opposite.
ISO 27001 is a risk-based standard. The mandatory requirements sit in the clauses, and Annex A is a list of 93 controls you consider, select or exclude, and then justify in your Statement of Applicability. Nothing in that structure names penetration testing, prescribes a scope, or sets an interval. If somebody tells you ISO 27001 mandates an annual pentest, ask them to point at the line.
What the standard does is put two obligations on you that a test happens to answer well.
A.8.29, security testing in development and acceptance. Security testing has to be defined and carried out. Defined means written down somewhere before it happens, with a scope and a method. Carried out means it actually ran and produced a result you kept.
A.8.8, management of technical vulnerabilities. You obtain information about technical vulnerabilities in the systems you use, evaluate your exposure to them, and take appropriate measures. This is a continuous obligation, not an event. It is also the control that most first-time candidates under-evidence, because they produce the finding and forget the trail that shows what happened next.
Read together, those two controls describe a test that was planned, executed against a defined scope, and followed by a documented response. That is a penetration test with a remediation trail. It is not the only possible answer, but it is the one auditors recognise on sight, and for a SaaS product with a public application and an API it is hard to argue in your own risk assessment that a scanner alone covers it.
The Controls a Pentest Report Actually Evidences
The mapping works at two levels, and conflating them is what produces reports auditors send back.
The engagement evidences two controls. A.8.29 is evidenced by the test itself, performed against a documented scope with a named methodology. A.8.8 is evidenced by the findings register, the severity ratings, and the dated record of what was fixed, when, and who verified it.
Each finding evidences the control it touches. This is the per-finding mapping, and it is what turns a technical report into audit evidence:
| Finding type | Annex A control |
|---|---|
| Broken object level authorisation, tenant data reachable across accounts | A.8.3 information access restriction |
| Injection, unsafe deserialisation, output encoding failures | A.8.28 secure coding |
| Privilege escalation, admin function reachable by a standard role | A.8.2 privileged access rights |
| Security-relevant action leaves no audit trail | A.8.15 logging |
| Exposed service, unnecessary port or management interface reachable | A.8.20 networks security |
| Architectural weakness that the design should have prevented | A.8.27 secure system architecture and engineering principles |
| The fix that ships in response, verified at retest | A.8.32 change management |
Our sample report shows this filled in for all thirteen findings in a real redacted engagement, with an evidence status per control, alongside the equivalent SOC 2 Trust Services Criteria table. It is ungated, so you can check the format against what your certification body asked for before you buy anything from anyone.
The Control a Pentest Does Not Evidence
A.8.25, secure development life cycle, is not evidenced by a test report. We state that on the sample report itself and it is worth repeating here, because the overclaim is common and it is the kind an experienced auditor catches.
A.8.25 is about the rules under which you develop software: the documented life cycle, security requirements captured at design time, review gates, separation of development from production. It is evidenced by your process documentation and by the artefacts that process produces. A penetration test is a point-in-time result. It can tell you the life cycle is not working. It cannot tell an auditor what the life cycle is.
If a vendor maps your findings to A.8.25, they have either misunderstood the control or are padding the mapping. Either way the auditor will still ask for the process documents, and you will have paid for a claim that bought you nothing.
The general rule: map what the test proves, and let the ISMS documentation carry the rest. A shorter honest mapping survives audit better than a long one that overreaches.
What the Certification Auditor Checks in the Report
An ISO 27001 auditor is not reading your findings for the technical detail. They are checking whether this document works as evidence against a control. That makes the checks mostly structural, and all of them are things you can verify before you buy:
- It is dated and version controlled. An undated PDF cannot be placed inside an audit period.
- The scope matches the systems inside your ISMS boundary. A report on a marketing site when your certificate covers the product is evidence for nothing.
- The assessor is named and independent. Not “our team is certified”. A person, a credential, and a way to verify it with the issuer.
- The methodology cites a version they can look up. OWASP WSTG v4.2 for web applications, OWASP ASVS 5.0.0 for verification depth, OWASP API Security Top 10 2023 for API surfaces. A report that says “we tested for vulnerabilities” reads as a scanner export.
- Every finding has a severity and a current status. Open, fixed, risk accepted. A finding with no status is an unfinished process, which is a finding about A.8.8.
- Anything marked closed was verified by a retest, not by your own team asserting it.
- The Annex A mapping is in the deliverable, not something you assemble yourself the week before Stage 2.
If a prospective vendor cannot show you a redacted report containing all seven, you are buying a scan with a cover page. Our penetration test report explained walks through what each section is for, and the penetration test plan example is the shape of the document that should exist before testing starts, which is the artefact that satisfies the “defined” half of A.8.29.
Your ISMS Boundary Is Not Automatically Your Pentest Scope
These two scopes overlap but they are not the same thing, and treating them as identical is the most expensive scoping mistake in ISO 27001 work.
Your ISMS scope statement covers a management system. It includes people, offices, suppliers, processes and physical controls. A penetration test covers technical systems. Nobody expects the test to cover your onboarding process or your supplier register.
What the auditor does expect is that the technical systems inside the boundary that handle the information the certificate is about were tested. For the AI-first and API-first SaaS startups we work with, that usually means three things: the production application, its authenticated roles including the tenant boundary, and its APIs. Marketing sites, internal tools and third-party platforms are frequently and legitimately excluded, but the exclusion should be a decision you can point at, consistent with your Statement of Applicability, rather than something that happened because the quote came in cheaper.
Two failure modes we see repeatedly:
Testing one application when the certificate covers three products. The gap surfaces at Stage 2 and there is no time left to close it.
Testing unauthenticated only. The interesting failures in multi-tenant SaaS are all behind login: role separation, object level authorisation, tenant isolation. An unauthenticated test is cheaper and answers a question nobody asked. Give the tester real accounts at every role, and give them two accounts at the same role in different tenants, which is the pair that finds cross-tenant leakage.
If you are scoping this for the first time, how to scope your first penetration test covers the mechanics.
Timing It Against Stage 1 and Stage 2
The certification audit runs in two stages. Stage 1 is a documentation review, where the auditor checks that your ISMS exists on paper: scope, risk assessment, Statement of Applicability, internal audit results. Stage 2 is where they check the controls actually operate, and it is where the pentest evidence is read.
Working backwards from Stage 2:
- 10 to 12 weeks before Stage 2. Scope and run the test. Testing is the short part.
- 6 to 8 weeks before. Remediate the Critical and High findings. This is where the calendar actually goes, because fixes queue behind product work.
- 4 weeks before. Retest, so closed findings are closed with third-party verification rather than your word.
- 2 weeks before. Assemble the evidence pack: the v1.0 report, the v2.0 retest report, the remediation trail with dates, the Annex A mapping.
Run the test too late and you hand the auditor a document containing open Critical findings and no evidence of a response. That is not a neutral outcome. It is direct evidence against A.8.8, because the control is about what you do after you find something, and the report will show you did nothing yet.
After certification, the cycle continues. The certificate runs three years with annual surveillance audits, and whatever testing frequency you wrote into your own documents is what the surveillance auditor will hold you to. When to re-pentest your SaaS app covers the change triggers that should pull a test forward.
ISO 27001 and SOC 2: One Test, Two Vocabularies
Most SaaS teams end up doing both, usually within eighteen months of each other. The technical testing is identical. What differs is the frame the report is read through.
| ISO 27001 | SOC 2 | |
|---|---|---|
| Read against | Annex A controls, A.5 to A.8 | Trust Services Criteria, CC1 to CC9 |
| Controls a test most directly serves | A.8.29, A.8.8 | CC4.1, CC7.1 |
| Who issues the outcome | An accredited certification body | A licensed CPA firm |
| What you get | A certificate, valid three years with annual surveillance | An attestation report covering a point in time or an observation period |
| Scope is set by | Your ISMS scope statement and Statement of Applicability | Your system description |
| Exclusions are justified in | The Statement of Applicability | The system description and control matrix |
One report can carry both mappings per finding, which is how we build the deliverable. The two boundaries are usually close but rarely identical, so the thing to settle before scoping rather than after is which systems sit in both: confirm each boundary, then test the union. Our companion piece on penetration testing for SOC 2 covers the auditor expectations on that side, and ISO 27001 vs SOC 2 covers which to do first if you have not decided.
What ISO 27001 Does Not Say About Penetration Testing
Worth stating plainly, because each of these gets sold as a requirement:
- It does not set a frequency. Yours does, once you write one down. Then it binds you.
- It does not require a specific vendor scheme. No CREST requirement, no CERT-In empanelment requirement, no country requirement. Independence and demonstrable competence are what the auditor tests for. If you are being told otherwise, who actually needs a CERT-In empanelled vendor is the honest version of that question.
- It does not publish a scope template. Your risk assessment produces the scope.
- It does not require the test to be annual to the day. It requires the interval to be risk-based and followed.
- It does not accept a report on its own. Without the remediation trail, you have evidenced half of one control.
The standard itself is published by ISO. ISO/IEC 27002 is the separate guidance companion that explains how each Annex A control is meant to be implemented, and it is the document worth reading if you want the implementation detail rather than the requirement.
Who Issues What
Keeping this line clean protects you as much as it protects us.
Cybersecify delivers the testing evidence. The test, the report, the Annex A mapping, the retest verification. We are a penetration testing firm. We are not a certification body, we do not issue ISO 27001 certificates, and we are not an ISO 27001 certified company ourselves.
An accredited certification body issues the certificate, after Stage 1 and Stage 2, and it has to be independent of whoever helped you prepare. A vendor offering you readiness consulting, the pentest and the certificate is offering you a conflict your certification body will care about. Check the accreditation mark on any certificate you are shown, including your competitors’.
How We Handle ISO 27001 Pentests
The Growth Pentest at INR 1,79,999 is the plan built for teams in an audit cycle. Two scopes over 10 business days, SOC 2 and ISO 27001 evidence mapping in the report, an executive summary written for an auditor rather than for an engineer, 12 hours of founder-led consulting usable for 12 months from kickoff, and one free retest within one month of the v1.0 report. The retest produces a v2.0 report with fixed-state evidence per finding, which is the artefact that closes findings properly.
The Startup Pentest at INR 74,999 covers a single scope in 5 business days with the same report structure and the same free retest. The Annex A and Trust Services Criteria mapping section is not included at this tier, and we would rather say that here than have you discover it at evidence submission.
Both are founder-led. Rathnakara GN (OSCP, M.Sc Cyber Security) leads the testing on every engagement. Our methodology sets out what is in scope and what is explicitly out of scope unless you authorise it in writing, which is the document your auditor will read alongside the report.
If your Stage 2 is more than ten weeks out, this is the right time to scope the test. If it is closer than that, say so when you get in touch and we will tell you honestly whether a retest still fits inside your window.
See the sample report | View pricing | Audit and compliance services | Web application pentest | Book a 30-minute scoping call