ISO 27001 & SOC 2: The Technical Evidence Your Auditor Actually Wants

Ask a room of engineers what ISO 27001 requires and someone will say "a pentest once a year." Search the standard for the word and you won't find it. That gap between what the framework literally says and what auditors actually demand is where certification projects quietly go wrong — and where a well-scoped penetration test turns into the cheapest evidence you will ever buy.

Two frameworks, one uncomfortable requirement

ISO 27001 and SOC 2 are management frameworks. They are not vulnerability checklists, and neither of them hands you a to-do list that says "test your applications on a schedule." What they do instead is subtler and, in practice, harder: they require proof that your technical measures function. Documentation can show that you wrote a policy. It cannot show that the policy stops anyone.

That is the crack where penetration testing enters. An auditor reading your risk register sees intent. An auditor reading a pentest report sees outcome — a real person, with real tools, trying to break in and reporting exactly how far they got. Almost every auditor, in almost every certification, eventually asks for that outcome. Not because the standard names it, but because nothing else answers the question.

Which ISO 27001 controls need real testing

The 2022 revision of Annex A restructured the control set, and three controls lean directly on technical testing. A.8.8 covers management of technical vulnerabilities. A.8.29 covers security testing in development and acceptance. A.8.9 covers configuration management. On top of those sits clause 9.1 in the main body of the standard: monitoring, measurement, analysis and evaluation of the ISMS.

The practical difference between these is what trips people up. An automated scanner answers A.8.8 cleanly — you can show a list of findings and a remediation tracker, and that satisfies "we know what vulnerabilities we have." It does not answer A.8.29, and it does not answer clause 9.1, because neither is asking whether you have a list. They are asking whether you verified that your defences hold.

A scanner will not chain two medium-severity findings into a working compromise. It does not understand that an exposed staging endpoint plus a reused credential equals domain admin. A human tester does, because that is the entire job.

Caution: Watch your Statement of Applicability. If you marked A.8.29 as applicable and you have no testing evidence to show for it, you have written your own nonconformity. Auditors check the match between what you declared applicable and what you can actually produce — line by line.

Where penetration testing fits inside SOC 2

SOC 2 is built on the Trust Services Criteria, and two criteria matter most here. CC4.1 requires periodic evaluations of control effectiveness. CC7.1 requires detection and monitoring of vulnerabilities and new configurations.

Then comes the detail that catches companies off guard. In a Type II audit, the auditor is not examining a moment — they are examining a window, typically three to twelve months. What counts is that testing happened inside that window, and that every remediation was followed through to closure. A brilliant test run the month before your observation period begins produces exactly zero evidence for that period. It is the single most expensive scheduling mistake in SOC 2 preparation, and it is entirely avoidable: plan testing alongside the audit window, not after it.

What each control asks for, and what a pentest delivers

The mapping below is the one worth keeping on your desk while you assemble evidence. Read the middle column as the requirement and the right column as the artefact an auditor will accept.

Notice how much of that right-hand column depends on the second test, not the first. Clause 9.1 is not satisfied by a snapshot; it is satisfied by a trend. An auditor wants to see that you found something, fixed it, and then verified the fix — and that the loop repeats. A single report, however thick, tells half the story.

When to schedule the test in the certification cycle

Timing is where good testing gets wasted. The rules of thumb that hold up across ISO and SOC 2 engagements:

• Before the Stage 2 audit for ISO — so you discover major findings in a conference room with your own team, not in front of the auditor.
• In the first weeks of the SOC 2 Type II observation period — leaving room to remediate and retest inside the same window.
• Annually, to feed surveillance audits.
• After any major architecture change, cloud migration, or new product launch.

That last point deserves emphasis. Certification is not a one-time event; it is a rhythm. Every time your attack surface changes shape, the evidence from last year describes a system that no longer exists. Auditors know this, and they ask.

What the report must contain to survive audit

A pentest report is not a deliverable for your engineering team alone. It is an audit artefact, and it needs to be written for a reader who was not in the room. Five things make the difference between a report that closes a control and one that generates follow-up questions:

• Explicit scope — which addresses, applications and accounts were tested, and just as importantly, what was left out.
• Declared methodology — OWASP, PTES, or equivalent — with start and end dates.
• Motivated severity — not a CVSS score copied straight out of a scanner, but a judgement about exploitability and business impact.
• An executive summary a management committee can read without a translator.
• Documented retest, with the final state of every finding.

That last item is the one auditors reach for first. A finding marked "remediated" without a retest is an assertion, not evidence. A finding marked "remediated, retested on this date, no longer reproducible" is evidence. The difference in audit outcomes is disproportionate to the effort involved.

Note: These same deliverables have already supported audit and registration processes for financial institutions and payment processors in Moldova. The pattern is consistent across sectors — the artefact matters as much as the finding.

Scope: the thing auditors notice first

Your test perimeter must cover the systems inside your declared ISMS scope, or the systems supporting whichever SOC 2 criteria you selected. In practice that means customer-facing applications, the infrastructure hosting them, authentication mechanisms, and — increasingly — cloud configuration.

A perimeter narrower than your declared scope is the first thing an auditor spots, because it is the easiest inconsistency to check: they hold your scope statement in one hand and your report in the other. A test that covers 80% of your declared systems does not read as "mostly compliant." It reads as a gap, and gaps invite deeper questions about everything else.

Who should run the test

An internal team can do it. Independence, however, is what auditors are pricing in. ISO 27001 requires the evaluation to be objective, and SOC 2 looks more favourably on an external party. If the team that built the system is also the team that tests it, expect a request for additional evidence of separation of duties — evidence most organisations cannot produce convincingly.

The straightforward path is an external provider with a declared methodology and an independently written report. It removes an entire category of audit friction before it appears.

The questions that come up every time

Does ISO 27001 mandate a penetration test?

The standard never uses the word as an explicit obligation. But A.8.8, A.8.29 and clause 9.1 require identifying technical vulnerabilities, testing security, and evaluating the effectiveness of measures. In practice, auditors accept a penetration test as the most direct evidence for those requirements — and an organisation that declared A.8.29 applicable without being able to show testing is exposed to a nonconformity finding.

Is a vulnerability scan enough for SOC 2?

Scanning covers the continuous monitoring element of CC7.1, but it rarely satisfies CC4.1 on its own, because CC4.1 asks about effectiveness. A scanner reports what might be vulnerable; a penetration test shows what can actually be exploited and how far an attacker gets. Most auditors expect both: recurring scanning plus at least one manual test inside the observation period.

How old can the report be?

The usual rule is twelve months maximum, but for SOC 2 Type II something else governs: the report must be dated inside the observation window. An excellent test run a month before the window opens produces no evidence for that window. For ISO, test before the certification audit and then annually at surveillance.

What scope must be tested for certification?

Everything in the ISMS scope, or everything supporting your chosen SOC 2 criteria: customer-facing applications, hosting infrastructure, authentication mechanisms, and cloud configuration. A perimeter narrower than the declared scope is precisely what the auditor checks first.

Can an internal team do it?

Yes, but independence matters. ISO requires objective evaluation, and SOC 2 places more confidence in an external party. When the builders are also the testers, expect requests for additional separation-of-duties evidence — the simplest route is an external provider with a declared methodology and an independent report.

The takeaway

The certification industry has a habit of treating penetration testing as a checkbox purchased shortly before an audit. That framing misses what the frameworks are actually asking. ISO 27001 and SOC 2 are both, at heart, asking a single question: can you demonstrate that your defences work against someone trying to break them? A policy proves intent. A scanner proves awareness. Only a test — scoped to your declared systems, run inside your audit window, and followed by a documented retest — proves function. Companies that internalise that early spend less on certification, not more, because they stop buying evidence that auditors cannot use.

This material is informational and does not constitute certification advice. Exact requirements depend on your declared scope and on the certification body or audit firm you choose.