ISO 27001 Penetration Testing

The scope statement in your ISMS defines what the certificate covers, and the test should match it. We align the engagement to that boundary so the evidence maps onto the controls your auditor examines, rather than testing assets outside scope and paying for coverage you cannot use.

A.8.8 requires you to obtain information about technical vulnerabilities, evaluate your exposure, and take action. Penetration testing is a primary source of that information for exploitable, real-world vulnerabilities, and the report gives you the evaluation and prioritized action the control expects.

A.8.29 calls for security testing during development and before acceptance. Testing a release before it goes live, and after significant change, is exactly this control in practice. We map findings back to it so your auditor sees the process, not just a one-off test.

Related access and cryptography controls

Findings frequently touch A.8.3 (information access restriction), A.8.5 (secure authentication), and A.8.24 (use of cryptography). Where a broken authorization check or weak session handling undermines one of these, we say which control it affects so the link to your Statement of Applicability is explicit.

Clause 9 covers monitoring, measurement, internal audit, and management review. An independent penetration test is a strong input to all of them: it measures whether your technical controls perform, and the report feeds directly into the management review that clause 9.3 requires.

Your SoA declares which Annex A controls apply and why. When you claim A.8.8 or A.8.29 as applicable, an auditor expects evidence they are implemented. A test report is that evidence, and we structure it so the mapping to your SoA is obvious rather than something you have to reconstruct.

We map the in-scope applications, APIs, perimeter, and cloud environment, then agree rules of engagement and test windows. This is also where we confirm the boundary matches your ISMS scope statement, so nothing gets tested that falls outside the certificate.

Using Burp Suite, nmap, ffuf, and hands-on business-logic analysis, we work through authentication, authorization, injection, SSRF, and misconfiguration. When we exploit a finding we prove impact and stop, capturing enough evidence to make the report reproducible for your engineers and credible to your auditor.

You receive a report structured for both leadership and technical teams, mapped to the Annex A controls in play, plus a free retest so you can close findings before the audit date. The closure statement demonstrates A.8.8 action in practice.

IDOR and missing authorization checks that let a user reach data or functions they should not are consistently the highest-impact findings. They map to A.8.3 and A.8.5 and they are the kind of logic flaw a scanner routinely misses.

Missing MFA, tokens that never expire, weak password-reset logic, and session fixation each hand an attacker a foothold without much effort. These undermine A.8.5 directly.

SQL injection, SSRF into internal services, and insecure deserialization give an attacker reach well beyond a single request. Internal-facing components trusted by design often fail once tested.

Exposed admin interfaces, verbose errors leaking internals, secrets in configuration, and over-permissive cloud storage are the quiet gaps. They contradict A.8.9 configuration management until you find and fix them.

The report is an input to your risk assessment, your risk treatment plan, and your management review. Because findings carry the control they affect, updating your SoA evidence and your clause-9 records is straightforward rather than a translation exercise.

An external test looks at your internet-facing attack surface the way a remote attacker would: the perimeter, the public applications, and the exposed services. It is the minimum most auditors expect and the fastest to scope. For a cloud-native company with no traditional office network, it may be nearly the whole picture.

An internal test assumes an attacker already has a foothold, whether from a phished credential or a compromised device, and asks how far they can move. This is where segmentation, internal access controls, and privilege separation get their real check. If your ISMS scope covers an internal network or a corporate environment, leaving it untested is a gap an auditor will notice.

Assumed-breach as a middle ground

Where a full internal test is not proportionate, an assumed-breach scenario gives you much of the insight for less effort: we start from a low-privilege position and see what an attacker reaches. It is a pragmatic way to evidence internal controls without a large engagement.

Test early enough before initial certification that you have time to remediate and retest, so your Stage 2 auditor sees closed findings rather than a list of open ones. Presenting a report with remediation already evidenced is the strongest position for A.8.8.

Certification is maintained by annual surveillance audits and a full recertification every three years. A test in each cycle, plus one after any significant change under A.8.29, keeps your technical-vulnerability evidence continuous rather than a single stale report the auditor questions.