Which ISO 27001 control covers penetration testing?

No ISO/IEC 27001 control names penetration testing. A penetration test usually serves as evidence for control 8.8, management of technical vulnerabilities, which was A.12.6.1 in the 2013 edition whose certificates expired on 31 October 2025.

How often should you run a penetration test for ISO 27001?

ISO/IEC 27001 sets no frequency for penetration tests; you set one in the risk treatment plan, and the auditor checks that you keep it. I run one a year and after major changes.

Is a vulnerability scan enough for ISO 27001?

A vulnerability scan can satisfy an ISO 27001 auditor for control 8.8 if your risk assessment supports it. A scan misses flaws in your own authorization logic, so add CI access tests and a yearly penetration test.

Will an ISO 27001 auditor ask for a penetration test report?

An ISO 27001 auditor asks for a penetration test report when your Statement of Applicability names one, because the audit checks evidence for the controls you chose. In my practice, enterprise customers asked for one even when the auditor did not.

Does ISO 27001 require penetration testing?

Answer

Yes in practice: ISO/IEC 27001 does not name penetration testing, but its Annex A control 8.8 requires you to find and evaluate technical vulnerabilities, so penetration-test each application in the ISMS scope that holds customer data once a year and after major changes, and test access checks in CI on every change.

Verdict on the code under testYes

Why

Blast radiussafety-or-legal
Change frequencyregularly
Detectabilitynever
Reversibilityimpossible
Test costheavy

Yes in practice: ISO/IEC 27001:2022 never names penetration testing, but Annex A control 8.8 requires you to find technical vulnerabilities and act on them, and ISO/IEC 27002 lists penetration tests as one way. The typical case is a SaaS application in the scope of a first certification audit. Blast radius is safety-or-legal, because a flaw exposes customer data, and Change frequency is regularly, because endpoints change monthly. Detectability is never, because a user who edits a request to raise their own rights gets ordinary responses, and Reversibility is impossible, because read data cannot be recalled. Test cost is heavy, because a tester needs days and a staging copy, and rule R2 still gives Test mandatory.

When the decision changes
When	Decision	Why
Every system in the ISMS scope is a hosted product whose terms forbid customer penetration tests	Test it differently: check each vendor's certificate or audit report, require multi-factor login and alert on bulk downloads	Test cost rises to prohibitive, because you may not attack the vendor's platform, so rule R4 applies
A system in the ISMS scope holds no customer data, such as a public marketing site with no forms	Do not commission a penetration test for that system; keep it in the vulnerability scan	Blast radius falls to users, Detectability to same-day and Reversibility to trivial, because a redeploy restores a defaced page
A staff tool in the ISMS scope holds no customer data or secrets, such as a meeting room booking app	Test it differently: alert on sign-ins from new countries and review access every quarter	Blast radius falls to internal and Reversibility to with-effort, because a backup restores the bookings; with Detectability eventually, rule R9 applies
The penetration test finds a known kind of flaw, such as a user who sets their own role through a profile update	Test mandatory: a CI test sends a role field to the profile endpoint and asserts that the role did not change	Test cost falls to moderate, because the known request reproduces the flaw, and Blast radius stays safety-or-legal
The application with customer data changes only a few times a year	Test mandatory: keep the yearly penetration test and the CI access tests	Change frequency falls to rarely, and Blast radius stays safety-or-legal, so rule R2 still applies

What breaks if you don't test

The profile endpoint saves every field in the request body. A customer adds "role": "admin" to a profile update and reads every account in their organisation. No alert fires, and the weekly scan stays green, because a scanner does not know which fields a user may set. A customer's own penetration test may find it first.

What you lose if you over-test

A penetration test on every release holds each release for days, and most of each report repeats the last one. A scan-only report sold as a penetration test gives the auditor a document and you false confidence, because it never tries one user's session against another user's data.

How to test

Name the penetration test, its scope and its frequency in the risk treatment plan, and cite it for control 8.8 in the Statement of Applicability.
In CI, send each endpoint that updates a user a field the user may not set, as in OWASP API3:2023, and ask each endpoint for another customer's record.
Once a year and after major changes, an outside tester runs an authenticated test on staging, scoped with the OWASP Web Security Testing Guide, and retests each fix.
Keep the report, a ticket per finding and the retest for the auditor.

Procedure and references

When the answer changes

Every system in the scope is a hosted product you may not test.
A system holds no customer data.
Card numbers enter the scope: PCI DSS requirement 11.4 then requires a penetration test at least every 12 months.

Real incident + Code example

The role field the scanner never touched

On a B2B document product I worked on, our Statement of Applicability met control 8.8 with weekly scans, and the certification auditor accepted them. Eight months later a bank we were onboarding ran its own penetration test and found that PATCH /api/me saved any field, including role. We added a field allowlist that afternoon, a yearly penetration test to the Statement of Applicability, and this CI test:

import request from "supertest";
import { expect, it } from "vitest";
import { app } from "../src/app";
import { createOrg, tokenFor } from "./fixtures";

it("ignores a role sent to the profile endpoint", async () => {
  const org = await createOrg("acme");
  const token = await tokenFor(org.member);

  const res = await request(app)
    .patch("/api/me")
    .auth(token, { type: "bearer" })
    .send({ name: "Dana", role: "admin" });
  expect(res.status).toBe(200);

  const me = await request(app).get("/api/me").auth(token, { type: "bearer" });
  expect(me.body.name).toBe("Dana");
  expect(me.body.role).toBe("member");
});

The name must change, so an endpoint that rejects every update fails the test too.

Sources

Does SOC 2 require penetration testing?Code under test: Yes
Does GDPR require penetration testing?Code under test: Yes
Does HIPAA require penetration testing?Code under test: Yes
Should I test input validation?Yes
Should I test API endpoints?Yes

FAQ

Which ISO 27001 control covers penetration testing?: No ISO/IEC 27001 control names penetration testing. A penetration test usually serves as evidence for control 8.8, management of technical vulnerabilities, which was A.12.6.1 in the 2013 edition whose certificates expired on 31 October 2025.
How often should you run a penetration test for ISO 27001?: ISO/IEC 27001 sets no frequency for penetration tests; you set one in the risk treatment plan, and the auditor checks that you keep it. I run one a year and after major changes.
Is a vulnerability scan enough for ISO 27001?: A vulnerability scan can satisfy an ISO 27001 auditor for control 8.8 if your risk assessment supports it. A scan misses flaws in your own authorization logic, so add CI access tests and a yearly penetration test.
Will an ISO 27001 auditor ask for a penetration test report?: An ISO 27001 auditor asks for a penetration test report when your Statement of Applicability names one, because the audit checks evidence for the controls you chose. In my practice, enterprise customers asked for one even when the auditor did not.