● Talk to a security engineer: +92 323 8295031info@protonyte.com  ·  PCSF batch enrolling now

ISO 27001 penetration testing, and where the standard actually asks for it

ISO/IEC 27001 does not contain a clause saying "perform an annual penetration test". What it contains is Annex A 8.8, management of technical vulnerabilities, together with clause 9 on monitoring and measurement and clause 10 on improvement - and an auditor who wants evidence that you do what 8.8 says. A penetration test is the most straightforward evidence there is, which is why almost every certified organization has one.

the clause your report

ENGAGEMENT SCOPEtypical 1 - 2 week test

Systems inside the ISMS scopeIN SCOPE
Internet-facing servicesIN SCOPE
Internal network and privileged accessIN SCOPE
Findings mapped to Annex A controlsIN SCOPE
Evidence for clause 9 and 10IN SCOPE
Supplier and cloud environmentsOPTIONAL
// the basics

What your auditor is looking for

Not a certificate from us. Evidence that the controls in your Statement of Applicability are operating, that you find technical weaknesses, that you act on them, and that the loop closes. A penetration test provides all four if it is scoped to the ISMS and the remediation is documented afterwards.

The scope question is the one that catches people. A test of one application when the ISMS covers the whole organization is evidence about that application and nothing else. We scope from the Statement of Applicability and the ISMS boundary, and where something in that boundary is out of our reach we say so in the report rather than leaving a gap the auditor finds.

  • 01Scoped from the ISMSNot from one application somebody nominated.
  • 02Mapped to Annex AEach finding tied to the control it touches, so the link to your Statement of Applicability is explicit.
  • 03Evidence of the loopFinding, action, retest, closure - which is what clause 10 asks you to show.
  • 04Works for Stage 1 or surveillanceWe will tell you which of the two you are preparing for and scope to it.
// coverage

What we test

Scoped from your ISMS boundary and Statement of Applicability, with each finding mapped back to the Annex A control it touches.

// A 8.8, A 8.20

External surface

Everything reachable from outside the organization.

  • Exposed services and remote access
  • Public applications and portals
  • Email and domain security
  • Unpatched and unsupported software
// A 5.15 to A 5.18

Access control

The largest group of controls in the Annex, and the easiest to evidence badly.

  • Authentication and privileged access
  • Access rights in practice versus on paper
  • Multi-factor coverage
  • Account lifecycle and leavers
// A 8.20 to A 8.23

Network security

Segregation, filtering and what actually crosses.

  • Network segregation tested, not read
  • Filtering and egress control
  • Internal escalation paths
  • Wireless, where in scope
// A 8.25 to A 8.29

Application security

Secure development controls, measured against the running system.

  • Injection and input handling
  • Authorisation between roles
  • Session and token handling
  • Third-party components
// A 5.23, A 8.9

Cloud and configuration

Where the ISMS boundary now usually extends.

  • Cloud service configuration
  • Identity and key management
  • Storage exposure
  • Configuration drift from your baseline
// clause 9 and 10

The evidence

The reason the test is being bought.

  • Findings mapped to Annex A controls
  • Nonconformity and corrective action input
  • Retest closing the loop
  • Dated record for the audit file
// methodology

How the work runs

  1. 1

    Read the scope documents

    Yours, not ours. The ISMS boundary decides what the test covers.

    • ISMS scope statement
    • Statement of Applicability
    • Stage 1, Stage 2 or surveillance
    • Previous findings, if any
  2. 2

    Scope and accounts

    Mapped to the boundary, with anything unreachable flagged now rather than in the report.

    • Systems in the ISMS boundary
    • Accounts at each role
    • Cloud read-only access where relevant
    • Written authorisation
  3. 3

    Test

    Manually, against the boundary, outside and inside.

    • External surface
    • Internal network and escalation
    • Applications and APIs in scope
    • Cloud configuration where included
  4. 4

    Map and report

    Each finding tied to the control it touches.

    • Findings with evidence and severity
    • Annex A control mapping
    • Remediation your team can action
    • Executive summary for management review
  5. 5

    Retest and close

    The part that satisfies clause 10.

    • Findings re-attacked after you fix
    • Closure summary dated and retained
    • Input for your corrective action log
    • A debrief before your audit
// the deliverable

What you are left holding

Two documents and a conversation. Written so the person who signs the invoice and the person who writes the fix can both use them.

  • Executive summary in plain language, with the business risk first
  • Technical findings with the evidence that proves each one
  • CVSS score and a risk rating that reflects your business, not a template
  • Remediation written for the stack you actually run
  • A free retest, and a closure summary you can hand to a customer
  • A debrief call with the tester who did the work, not an account manager
Ask for a sample report
// the standards

Measured against something

The work follows ISO/IEC 27001:2022 Annex A, ISO/IEC 27002:2022, OWASP Web Security Testing Guide and NIST SP 800-115, so the coverage can be checked rather than taken on trust, and the report maps to what your auditor or your enterprise customer already recognises.

This page is one part of our compliance and audit service. Where a finding needs a different kind of engagement to answer properly, we say so in the report rather than selling you the test we happen to be running.

// faq

Common questions

Does ISO 27001 require a penetration test?

Not in those words. There is no clause mandating one. Annex A 8.8 requires technical vulnerabilities to be identified and acted on, and clauses 9 and 10 require monitoring and improvement. A penetration test is the most straightforward way to evidence all three, which is why certified organizations almost always have one - but it is evidence for a control, not a requirement in itself.

How often should we run one?

Annually is the normal rhythm, and it is what most certification bodies expect to see across a three-year cycle. More useful than the interval is testing after significant change, because that is when new technical vulnerabilities actually appear.

Our ISMS scope is the whole company. Does the test have to be?

It has to be representative of it, and the report has to be honest about what was and was not covered. A test of one application presented as evidence for an organization-wide ISMS is the gap auditors find most often.

Can you also help with the certification itself?

We do readiness and gap work - see the compliance and audit page - but we are not a certification body and cannot certify you. Anyone offering both should be asked how they square the independence.

Will this work for ISO 27001:2022 specifically?

Yes. The control mapping in our report uses the 2022 Annex A structure, including the reorganised control numbers. If you are still transitioning from the 2013 version we will map to both.

// start here

Let's protect your business together.

Tell us what you need tested. Our team will reply with a clear scope and quote.

By submitting, you agree to our Terms of Use and Privacy Statement.