Skip to content
Invadel

Compliance

ISO 27001
Penetration Testing

Component tests from $4,200, free retest. See all pricing →

Get a fixed quote

Reply in one business day

Full scoping questionnaire 
Senior certified testers, manual-first185+ years combined experienceOnboarding within 24 hoursFree retest includedOur methodology

When you need it

When you need ISO 27001 penetration testing

The situations that bring teams to this engagement, and where it fits alongside the rest of your program.

  • Your Stage 2 audit is one to three months out and the auditor’s document request includes penetration testing evidence.
  • A surveillance or recertification audit is approaching and the last test is older than a year.
  • Your risk treatment plan lists penetration testing as the control for technical vulnerabilities, and the evidence is missing.
  • You are transitioning from ISO 27001:2013 to the 2022 edition and need evidence for the reworded technical controls.
  • Enterprise customers ask for your certificate and a recent penetration test in the same security review.

Annex A

Where penetration testing sits in ISO 27001:2022

The standard never says “penetration test,” but four Annex A controls are difficult to evidence without one.

A 8.8 Management of technical vulnerabilities

Information about technical vulnerabilities must be obtained, exposure evaluated, and measures taken. The penetration test is the evaluation; the retest is the measure. This is the control auditors ask about first.

A 8.29 Security testing in development and acceptance

Security testing processes must be defined and implemented in the development life cycle. A penetration test of the application before release, and after major change, is the clearest evidence that the process exists.

A 5.35 Independent review of information security

The approach to managing information security must be reviewed independently at planned intervals. An external penetration test is an independent review of the technical controls.

A 8.25 Secure development life cycle

Rules for secure development must be established and applied. Pairing the test with a secure code review evidences the rules, not just the outcome.

The requirement

ISO 27001 penetration testing requirements: what the standard and the auditor actually ask for

The standard never uses the words “penetration testing” as a mandatory control, and yet you effectively need one to certify and stay certified. Two parts of the standard explain why, and four things decide whether your auditor accepts the result.

Annex A 8.8 and Clause 9

Annex A 8.8 requires you to obtain information about technical vulnerabilities, evaluate your exposure, and act on it. Clause 9 requires you to evaluate the effectiveness of the ISMS, and a control that looks correct on paper is not the same as one proven under attack. Scanning contributes to 8.8; a penetration test is how you find the exploitable, chained, and logic-level flaws that represent real risk, and how you prove the controls hold. Put together, the standard requires you to find your technical vulnerabilities and prove your controls work, and testing is the recognized method for both.

The four things the auditor checks

That testing happened, independently and competently, against a scope that matches the certified boundary. That findings entered the risk process: each one assessed, risk-rated, and remediated or formally accepted, with a record. That remediation was verified, ideally by a retest. And that it recurs, as part of a cycle rather than a one-off before the certification audit. A test whose findings went nowhere is a finding against you, because the auditor cares as much that the report drove action through the risk-treatment process as about the report itself.

Scope the test against your Statement of Applicability and asset inventory. Testing outside the boundary wastes budget; leaving an in-scope system untested is a hole the auditor may find. Our ISO 27001 checklist walks through Clauses 4 to 10 and Annex A for the rest of the audit.

What we assess

What your ISO 27001 test covers

We test the systems inside your ISMS scope and map every finding to the Annex A controls, giving your auditor evidence of control effectiveness rather than a raw scan.

Technical Vulnerability Management

The Annex A 8.8 control auditors most often want penetration testing to evidence.

We test for

  • Known-vulnerability identification
  • Patch and update verification
  • Exploitability confirmation
  • Remediation and retest evidence

Access Control & Identity

Whether access to in-scope systems is restricted the way your ISMS says it is.

We test for

  • Access control and least privilege
  • Authentication and MFA
  • Privileged access management
  • Account lifecycle checks

Network & Infrastructure

The perimeter and internal infrastructure supporting your ISMS scope.

We test for

  • External perimeter testing
  • Internal segmentation
  • Secure configuration review
  • Exposed service testing

Applications & Data

The applications and data flows your scope statement covers.

We test for

  • Application security testing
  • Encryption in transit and at rest
  • Data handling and leakage
  • Logging and monitoring coverage

Scope

Which test your ISMS scope needs

The scope statement decides the test. These are the engagements that map to common ISMS boundaries.

Web application

For a SaaS product or customer portal inside the scope statement.

API

For the integrations and services the application depends on.

External network

For the internet-facing perimeter of the in-scope infrastructure.

Internal network

For office and data-center networks, Active Directory, and segmentation inside the scope.

Cloud

For AWS, Azure, or GCP environments that host in-scope systems.

Timing

Timing across the ISO 27001 certification cycle

When to test

Stage 1 (documentation review)
Not required, but scheduling the test shows the auditor the plan exists
Stage 2 (certification audit)
One to three months before, with the retest complete
Surveillance (annually, years 1 and 2)
Within the twelve months before each visit
Recertification (year 3)
One to three months before, treated like Stage 2

Why

Stage 1 (documentation review)
Stage 1 checks the ISMS design, including how technical vulnerabilities will be managed
Stage 2 (certification audit)
The auditor checks that A 8.8 and A 8.29 operate, and closed findings are stronger evidence than open ones
Surveillance (annually, years 1 and 2)
Evidence must stay current; a stale test is a common minor nonconformity
Recertification (year 3)
The full ISMS is re-examined, and auditors expect a fresh, complete test

Deliverables

What your auditor receives

  • A report with every finding mapped to the Annex A control it evidences, plus an executive summary for the management review.
  • A letter of attestation confirming independent testing, scope, dates, methodology, and remediation, for the audit file and customer reviews.
  • Retest evidence showing findings closed, so the audit sees a working control rather than a list of problems.
  • Inputs for the Statement of Applicability and the risk treatment plan, in the language your ISMS already uses.
  • A scope statement matching your ISMS boundary, so the auditor can see the test covered what the certificate will cover.

Methodology

How we test

Full methodology →

Every engagement follows the Penetration Testing Execution Standard and the relevant OWASP guides.

These are the phases your compliance test runs through.

  1. 01

    Scope the boundary

    The systems your framework actually covers, and nothing you would pay to test twice.

  2. 02

    Test

    The component penetration tests run to PTES and OWASP standards by senior testers.

  3. 03

    Map to controls

    Every finding tied to the requirement or control it evidences.

  4. 04

    Report for the auditor

    Evidence formatted the way your assessor, examiner, or QSA expects to read it.

  5. 05

    Fix & retest

    A free retest so the audit shows closed findings, not open ones.

How it works

How your engagement runs

From scope through the final retest, your team stays in the loop at every step, with findings tracked live in our platform.

  1. 01

    Scope the ISMS

    We scope the systems in your ISMS and align testing to the Annex A controls.

  2. 02

    Test controls

    We test vulnerability management, access, and infrastructure security.

  3. 03

    Annex A report

    Findings mapped to the relevant Annex A controls, with an executive summary.

  4. 04

    Fix & retest

    Close the findings, then a free retest well ahead of your certification audit.

Component tests

The tests behind your ISO 27001 evidence

Compliance testing is built from our standard fixed-scope engagements. Each one is scoped to your boundary and reported against the framework.

Web application penetration testFor applications inside the scope statement, evidencing A 8.8 and A 8.29. From $5,200.External penetration testFor the internet-facing perimeter of in-scope infrastructure. From $4,200.Internal penetration testFor internal networks, identity, and segmentation inside the ISMS. From $6,000.Cloud penetration testFor cloud environments hosting in-scope systems. From $6,800.Vulnerability scanningThe ongoing A 8.8 evidence between annual tests. From $1,500 per scan.
Industries that need thisSaaS & SoftwareLaw FirmsHedge Funds & Asset ManagersReal Estate & PropTechAll industries

Proof

Proof in the field

Every engagement is confidential, so the work below is anonymized to sector and engagement type.

All case studies →

Free

Retest on every penetration test

185+

Years combined experience

14

Senior in-house specialists

24h

Onboarding after signing

HR & Payroll SaaS

Web Application Penetration Test

High risk

Critical: a file-inclusion flaw that let an attacker read sensitive files from the server through the application itself. High: stored cross-site scripting capable of session theft, insecure direct object references, and an authorization bypass that let an administrator create or delete organization owners.

Outcome. Delivered a remediation plan sequenced by real business impact, critical and high findings first, with a complimentary retest to verify every fix.

28

Findings

1

Critical

5

High

Read the case study

Fintech · Payments

Web Application Penetration Test

High risk

Critical: a remote code execution flaw in the application’s web framework that could have given an attacker full control of the server. We escalated it to the development team while the test was still running.

Outcome. The critical RCE was reported and remediated during the engagement via an emergency framework upgrade, which also closed the server-side request forgery, and the remaining findings were retested to confirmation.

1

Critical (RCE)

Mid-test

Critical remediated

2

High

Read the case study
LatentPerygeeCity National BankAubaDesteiaDTCC
Request a reference 

Resources

Field notes from the offensive side

All articles →

ISO 27001 Checklist: Clauses 4 to 10, Annex A and Audit Readiness

An ISO 27001:2022 checklist: every requirement in Clauses 4 to 10, the mandatory documents, the 93 Annex A controls by theme, and an internal audit checklist.

ISO 27001 vs SOC 2: Which One Your Buyers Want

ISO 27001 vs SOC 2 compared: what each proves, who asks for which, how they overlap, and how one penetration test can evidence both frameworks at once.

Which Compliance Frameworks Require Penetration Testing?

A framework-by-framework guide to penetration testing for compliance: what SOC 2, PCI DSS, ISO 27001, HIPAA, GDPR, NYDFS and CMMC require, and how often.

Want to see a report first?

Read a sample report for a fictional client, or request a redacted one from a real engagement. Our guide explains what a penetration testing report should contain.

See the sample report

FAQ

Frequently asked questions

What teams most often ask before ISO 27001 testing.

Still have questions? 
01Does ISO 27001 require penetration testing?

The standard does not name penetration testing outright, but Annex A control 8.8 requires managing technical vulnerabilities and your ISMS must prove its controls work. Certification and surveillance auditors routinely expect a penetration test as that evidence, and it is the cleanest way to provide it.

02When should we test relative to our audit?

Early enough that findings can be remediated and retested before your certification or surveillance audit, typically one to three months ahead. We build the timeline around your audit date and most clients then test annually to keep evidence current.

03Will the report satisfy our certification auditor?

Yes. Findings are mapped to the relevant Annex A controls with an executive summary for your management review, and they feed directly into your Statement of Applicability and risk treatment plan, so the report drops into your ISMS evidence rather than needing translation.

04How much does an ISO 27001 penetration test cost?

Testing is scoped to the systems inside your ISMS boundary, usually a web application and/or network test (from $5,200 and $4,200), quoted as a fixed price after scoping, with a free retest. Starting prices for every service are on our pricing page.

05Do you provide a letter of attestation for our auditor?

Yes, on request. The letter confirms that independent penetration testing was performed, its scope and dates, the methodology, and that identified findings were remediated and retested, without disclosing the technical detail. Certification bodies and enterprise customers accept it as evidence alongside the executive summary.

06Can we reuse last year’s penetration test for this year’s audit?

Usually not. Auditors expect Annex A 8.8 evidence to be current, and a test older than twelve months rarely reflects the systems in scope today. If the environment genuinely has not changed and the audit is a surveillance visit, some auditors accept a test up to a year old with current scan evidence, but a certification or recertification audit will expect a fresh test. Ask your auditor and we will schedule to match.

07Where are our test results stored and who can see them?

Findings live in your Invadel platform workspace, encrypted at rest and in transit and accessible only to the users you authorize. Reports are delivered through the platform rather than email, retained for the engagement and retest, and destroyed on the schedule agreed under NDA. This matters for ISO 27001 because the test results are themselves confidential information inside your ISMS.

08How often does ISO 27001 require penetration testing?

The standard sets no fixed interval, because it is risk-based. The practical baseline auditors accept is annually, plus a test after any significant change: a major application release, a new system entering the ISMS boundary, a cloud migration, or an infrastructure change that alters the risk profile. That mirrors the surveillance-audit rhythm and keeps evidence current between visits. Higher-risk environments test more often, and a risk-based standard expects a risk-based frequency.

09Can one engagement cover ISO 27001 and SOC 2, PCI DSS, or HIPAA at the same time?

Yes, and it is the efficient way to do it. The underlying technical testing is largely the same; what differs is how findings are mapped and presented. Tell us every framework you hold or are pursuing during scoping and the report is written against all of them, with the Annex A mapping for your certification auditor alongside the criteria your other auditors read. Our guide to which frameworks require penetration testing shows how they overlap, and our comparison of ISO 27001 vs SOC 2 explains which one buyers usually ask for.

Ready to test your defenses?

Talk to our team about what your ISO 27001 compliance requires.

Prefer the full scoping questionnaire? 
RelatedSOC 2 Cyber Essentials+ PCI DSS

Get a Fixed-Scope Quote

Tell us what you need tested. We reply within one business day.