Penetration Testing for ISO 27001 and SOC 2: What Is Actually Required

Two things are true at once: neither ISO 27001 nor SOC 2 mandates an annual penetration test in the way most people believe, and almost every organisation certified against either ends up buying one. Understanding why is the difference between testing to pass an audit and testing to find out what is wrong.

What ISO 27001 actually says

The 2022 revision of Annex A includes a control on technical vulnerability management and one on secure development, and the standard as a whole is built on the idea that you identify risks and treat them. Nowhere does it name a penetration test as the required method.

What it does require is that you can show your controls work. For an internet-facing application, the practical way to evidence that is to have somebody competent try to break it and write down what happened. Auditors know this, which is why the request usually arrives as "how do you assure yourselves the application is secure" rather than "show me your pentest report".

What SOC 2 actually says

SOC 2 is not a checklist. It is an attestation against the Trust Services Criteria, and the relevant ones talk about identifying and managing vulnerabilities and monitoring for anomalies. The auditor is testing whether the controls YOU described are designed properly and operating. If your own control description says you carry out annual penetration testing, then you have made it a requirement for yourself, and failing to do it is an exception.

What an auditor is looking for

Having sat on the other side of enough of these conversations, the pattern is consistent. The report itself gets a shorter look than people expect. What gets examined is everything around it.

• Scope. Does the test cover the systems in the scope of the certification, or a subset that quietly excludes the interesting one?
• Independence. Was it done by somebody who does not report to the team that built the thing?
• Date. Does it cover the period under audit, and does it postdate the last significant change?
• What happened next. This is the one that fails people. A report with eight highs and no evidence that any of them were fixed is worse than no report, because it documents that you knew.
• Retest evidence. A statement from the tester that the issues were re-examined and are gone, rather than an internal ticket marked done.

Frequency, and where "annual" comes from

Annual is a convention, not a rule. It comes from PCI DSS, which does prescribe at least annually and after significant change, and it has leaked into how everybody talks about the other frameworks.

The more defensible position is risk-based and it is easier to evidence: test after significant change, and at a frequency that matches how fast the system changes. A platform shipping weekly and tested once a year is tested against a version that no longer exists. An internal tool that has not changed since 2023 does not need the same cadence.

Scope is where certifications go wrong

The most common gap is not the absence of a test. It is a test whose scope does not match the scope of the certification. A SOC 2 report covering a platform, and a penetration test covering the marketing website, is a real combination that occurs more often than it should.

Write the scope statement of the test to reference the same system boundary as the certification, and have the tester state explicitly what was NOT tested. An auditor reading "the administrative interface was out of scope" can decide whether that matters. An auditor discovering it themselves reaches a less generous conclusion.

The evidence chain an auditor actually follows

The report is one link. The chain runs: a policy saying you test, a scope statement matching the certified boundary, a report from an independent party inside the audit period, a record of decisions about each finding, evidence that the ones you said you would fix were fixed, and a retest confirming it. Break any link and the report on its own does not carry the weight people expect it to.

The link most often broken is the fourth. Findings get fixed and nobody records the decision, so an auditor sees eight issues and no trail, and has to ask. Findings get accepted for good commercial reasons and nobody records that either, which reads far worse than the acceptance itself would have. Recording "accepted, by this person, for this reason, revisit in March" takes a minute and is the difference between a control that operates and one you have to argue for.

Internal testing counts, with a caveat

Neither standard requires that a penetration test be external, and a competent internal team testing something they did not build satisfies the independence question for many auditors. What it does not satisfy is a customer questionnaire, which usually asks specifically for third-party testing, and that is often the real driver rather than the certification.

If budget forces a choice, a defensible pattern is internal testing at the cadence your change rate demands, plus an external test annually or on major release, with the scope of the external one covering what your customers most care about. Write that arrangement into your control description and you are audited against what you actually do.

What a certificate is not

Neither standard certifies that your application is free of vulnerabilities, and no honest tester will tell you a test proves that either. Both certify that you have a system for managing risk and that it operates. A penetration test is evidence within that system, not a substitute for it.

That distinction matters commercially as well. A customer asking for your ISO certificate and your latest test report is asking two different questions, and the second one is the one that tells them something about the software they are about to depend on.