iso27001pentest.com

ISO/IEC 27001 · testing and audit evidence

Scope a test

ISO/IEC 27001:2022 · Annex A evidence

ISO 27001 does not require a penetration test. Your auditor will still ask for one.

Nothing in clauses 4 to 10, and nothing in Annex A, names penetration testing. What puts a test report in your Stage 2 evidence pack is the chain from your risk assessment to A.8.8, A.8.29 and clause 9.1. This reference sets out which controls a test genuinely evidences, which it cannot, and what the report has to contain to survive an audit.

Plan certification testing Open the evidence mapper

Clause and control references follow ISO/IEC 27001:2022. The normative text belongs to the standard and is not reproduced here. Every figure on this page is sourced at the foot of the page.

§ 01 The plain answer

What the standard requires, and what it never says

This is the question that brings most people here, so it is answered first and without hedging. The honest answer is more useful than the marketing one, because it tells you what to buy and what not to.

Not required

No clause of ISO/IEC 27001:2022 and no Annex A control requires a penetration test, sets a frequency for one, or names a methodology. Every page that says the standard mandates an annual pentest is wrong.

In the text

What the standard does require

  • That you assess information security risk and decide, on that basis, which controls are necessary. The decision is recorded in the Statement of Applicability.
  • That the controls you declared applicable are actually implemented, including A.8.8 on technical vulnerabilities and, if you build software, A.8.29 on security testing in development and acceptance.
  • That you determine what needs to be monitored and measured and evaluate the performance and effectiveness of the ISMS, under clause 9.1.
  • That an internal audit programme runs and stays objective and impartial, under clause 9.2, and that management reviews the result under clause 9.3.
  • That findings feed a risk treatment plan with owners and dates, and that improvement is evidenced rather than asserted.

Not in the text

What the standard never says

  • It never says “penetration test”. There is no control that obliges you to buy one.
  • It sets no testing frequency. “At least annually and after significant change” is common practice and a certification body expectation, not a clause.
  • It does not require the tester to be external, certified, or a member of any scheme.
  • It does not require a scanner, a specific tool, a CVSS score, or a particular report format.
  • It does not let you skip the evidence either. If you cannot show A.8.8 works, the nonconformity is raised against the control, not against the missing test.

The practical consequence: an auditor cannot raise a nonconformity because you have no penetration test. They can raise one because you cannot demonstrate that a control in your own Statement of Applicability is implemented and effective. For most technological controls, an independent test is simply the cheapest and most legible way to demonstrate that. The rest of this page is about doing that deliberately instead of by reflex.

§ 02 The chain that produces a test

Six references, in the order an auditor follows them

Testing is not an obligation in ISO/IEC 27001. It is a consequence of decisions you made earlier in the standard. These are the references that produce it, in the sequence an auditor walks.

  1. 6.1.2 / 6.1.3 Origin Risk assessment and risk treatment You identify risks, choose treatment options and determine which controls are necessary. The output is the Statement of Applicability: every Annex A control marked applicable or excluded, with a justification for each. Everything downstream is measured against that document, not against the standard in general. Produces the Statement of ApplicabilityAuditor asks why a control is excluded
  2. A.8.8 Primary hook Management of technical vulnerabilities The control almost nobody excludes. Once it is applicable you have to show that technical vulnerabilities in your systems are being found, assessed and acted on. A scanner and a patch log are the floor. An independent test is what shows something other than your own scanner is looking, and it is where exploitability, chained findings and business-logic flaws come from. Evidence vulnerability register, scan cadence, patch records, independent test reportENISA maps IR 2024/2690 point 6.10 to A.8.8
  3. A.8.29 Primary hook Security testing in development and acceptance Applicable to anyone who develops software, including software assembled from libraries and low-code platforms. Security testing has to be part of development and acceptance, with results retained. A release-gated application test is the natural evidence; a once-a-year infrastructure scan is not. Evidence test plans, acceptance criteria, retained results per releaseENISA maps IR 2024/2690 point 6.5 to A.8.29, A.8.33 and A.8.34
  4. 9.1 Effectiveness Monitoring, measurement, analysis and evaluation You decide what to measure and then evaluate whether the ISMS and its controls are actually effective. A test report is a measurement of control effectiveness expressed in findings, which is why it lands so cleanly in this clause. It is also why a report with no severity scale and no retest is weak evidence: it measures nothing you can trend. Evidence measurement plan, results, trend across the cycleAuditor asks what changed since the last measurement
  5. 9.2 Independence Internal audit The internal audit programme must check the ISMS against your own requirements and against the standard, and auditors must be objective and impartial. Clause 9.2 is the clause that allows an outsourced internal auditor: an external, independent specialist is easier to defend than the team that built the system. It is not a route to certification, and it cannot be your certification body. Evidence audit programme, reports, nonconformities and closureCommon error asking the certification body to also audit internally
  6. A.5.35 / A.8.34 Governance Independent review, and protecting systems during audit testing A.5.35 asks for an independent review of the approach to managing information security. A penetration test is an input to that review, never the review itself. A.8.34 governs how tests on operational systems are planned and agreed so they do not disrupt the business, which in practice means your signed rules of engagement. Very few competitor pages mention it; auditors do. Evidence independent review report, signed rules of engagementENISA maps IR 2024/2690 point 2.3 to 9.2, 10.1, A.5.35 and A.8.34

The Annex A mappings above are taken from the ENISA technical implementation guidance mapping table for Commission Implementing Regulation (EU) 2024/2690, version 1.2. ENISA states plainly that the table “should not be interpreted as a measure of equivalency among different standards or frameworks”, so treat it as corroboration of which ISO references are in play, not as a substitute for reading your own Statement of Applicability.

§ 03 Signature tool

Annex A evidence mapper

Set your ISMS scope, mark which controls sit in your Statement of Applicability, and see what an auditor will want as evidence for each one. The tool exists to tell you where a penetration test is the right instrument and, more often, where it is not.

Interactive mode is not available. You can read the full reference content below. No answers are assessed and no result is calculated.

The interactive mapper needs JavaScript. The full control register is reproduced below. ISO/IEC 27001:2022 does not require a penetration test anywhere; these are the Annex A controls where one is, or is not, the evidence an auditor will accept.

Controls where an independent test is the primary evidence:

  1. A.8.8 Management of technical vulnerabilities – a vulnerability register, scan cadence and patch service levels, plus an independent test that found what the scanner did not.
  2. A.8.29 Security testing in development and acceptance – test plans, acceptance criteria and retained results tied to specific releases. Applicable to anyone who writes or assembles code.
  3. A.8.5 Secure authentication – authentication design and MFA coverage, evidenced by attempts to bypass session handling and account recovery.
  4. A.8.22 Segregation of networks – the segmentation design, plus a test that deliberately tries to cross every boundary it claims.

Controls where a penetration test proves nothing, and what to buy instead:

  • A.6.3 awareness and training – training records and phishing exercise results, not a test report.
  • A.8.25 secure development life cycle – the lifecycle definition and evidence its gates were applied. A test evidences the output, not the process.
  • A.8.1 user end point devices – device-management baselines and compliance reporting.
  • A.5.19 and A.5.22 supplier controls – a supplier register, due-diligence records and service reviews.
  • A.7.1 and A.7.4 physical controls – site plans, access records and, if you want them tested, a physical intrusion assessment.

Controls in the middle band, where a test supports evidence you still have to produce yourself, are A.5.35, A.8.2, A.8.9, A.8.15, A.8.16, A.5.23, A.8.20, A.8.28, A.8.31, A.6.7 and A.5.21.

Scope an SoA-based test
Your ISMS scope covers

Scope decides which controls are in play. Untick anything your certified scope genuinely excludes.

Result for this profile

4 controls where an independent test is the evidence

11 where the test supports other evidence

5 where a penetration test proves nothing

20 controls applicable in this profile

No test case

On this profile, a penetration test buys you nothing

You have excluded every control a test would evidence. That is a legitimate position if your Statement of Applicability justifies it. Spend the budget on the records the remaining controls actually need, and expect the auditor to test the justification hard.

Narrow case

One control carries the whole test

A single applicable control makes the test worthwhile. Keep the scope tight and the price proportionate, and do not let a vendor sell you a platform-wide engagement to evidence one control.

Standard case

A focused annual test is the proportionate answer

This is the typical certified organization: two controls where an independent test is the primary evidence, and a longer list where it only supports records you have to produce anyway. Scope the test to the two, and stop.

Broader case

Test scope should cover application and network boundaries

Three controls now depend on a test as their primary evidence, which usually means both an application and an infrastructure component. One engagement can cover both if the scope statement is written from your Statement of Applicability rather than from a price list.

Full case

A release-gated programme, not a single annual test

With development, cloud and segmentation all in scope, a once-a-year test will be stale before your surveillance audit. Move to release-gated application testing plus an annual infrastructure and segmentation test, and keep retest evidence for both.

Scope an SoA-based test

OffSeq scopes the test from your Statement of Applicability and delivers the retest evidence with it. OffSeq does not certify anyone.

Statement of Applicability

Every control below is ticked as applicable by default. Unticking one is exactly what an SoA exclusion is, and the auditor will ask you to justify it in writing.

  • Evidence An independent test is the primary artefact for this control.
  • Supporting The test helps, but the control’s own records are the evidence.
  • Wrong tool A penetration test proves nothing here. The right instrument is named on the row.
  1. Independent review of information security Auditor asks for A dated independent review of how information security is managed, plus the management response to it. A test report is one input to the review. It is not the review, and submitting it as one is a common finding. Supporting Excluded Record the justification in the SoA
  2. Information security awareness, education and training Auditor asks for Training records, completion rates, refresher cadence and the results of any phishing exercise. A penetration test evidences nothing here. The matching instrument is a social-engineering assessment or an awareness programme. Wrong tool Excluded Record the justification in the SoA
  3. Privileged access rights Auditor asks for A privileged-account inventory, an approval trail and periodic access reviews with results. A test can show that privilege escalation is possible, which is powerful. The periodic review record is still the evidence the control is managed. Supporting Excluded Record the justification in the SoA
  4. Secure authentication Auditor asks for The authentication design, MFA coverage figures, and testing of session handling and account recovery. Authentication is behaviour, not configuration. Only an attempt to bypass it shows whether it holds. Evidence Excluded Record the justification in the SoA
  5. Management of technical vulnerabilities Auditor asks for A vulnerability register, scanning cadence, patch service levels, and an independent test that found what the scanner did not. The control the whole industry buys a test for, and the one case where the report genuinely is the cheapest evidence available. Evidence Excluded Record the justification in the SoA
  6. Configuration management Auditor asks for Hardening baselines per platform and drift or compliance reports against them. A test finds drift, which is useful. The baseline and the drift report are what demonstrate the control exists. Supporting Excluded Record the justification in the SoA
  7. Logging Auditor asks for A log inventory, retention settings, protection of logs, and proof that the test activity actually appeared in them. Ask the tester for their timestamps and source addresses, then show the matching log lines. That single exhibit is worth more than a policy. Supporting Excluded Record the justification in the SoA
  8. Monitoring activities Auditor asks for Detection use cases, alerts raised during the test window, and the debrief with whoever watches them. Only if you brief the detection team afterwards. An unannounced test that nobody reviews evidences nothing about monitoring. Supporting Excluded Record the justification in the SoA
  9. Information security for use of cloud services Auditor asks for Cloud service agreements, a shared-responsibility matrix, and a configuration review of the actual tenant. A cloud configuration review is the instrument here, not a network penetration test against the provider’s platform. Supporting Excluded Record the justification in the SoA
  10. Networks security Auditor asks for Current network diagrams, rule-set reviews, and an inventory of what is exposed externally. External testing validates the exposure inventory. The rule-set review is what shows the control is operated. Supporting Excluded Record the justification in the SoA
  11. Segregation of networks Auditor asks for The segmentation design plus a test that deliberately tries to cross each boundary it claims. Segmentation is the classic control that looks perfect on a diagram and fails in practice. Testing it is the evidence. Evidence Excluded Record the justification in the SoA
  12. Secure development life cycle Auditor asks for The documented lifecycle, its security gates, and records showing the gates were actually applied. A test evidences the output, not the lifecycle. Secure code review and pipeline records are the matching instruments. Wrong tool Excluded Record the justification in the SoA
  13. Secure coding Auditor asks for Coding standards, static analysis configuration and results, and code-review records. Test findings show whether the coding standard holds in production, which makes them strong corroboration of a weak standard. Supporting Excluded Record the justification in the SoA
  14. Security testing in development and acceptance Auditor asks for Test plans, acceptance criteria, and retained results tied to specific releases. This is the control that expects testing by name. Release-gated application testing answers it directly. Evidence Excluded Record the justification in the SoA
  15. Separation of development, test and production environments Auditor asks for An environment inventory, the access model for each, and evidence that production data is not copied into test. A test can prove crossover exists. The environment and access design is what shows separation is intended and managed. Supporting Excluded Record the justification in the SoA
  16. Remote working Auditor asks for The remote-working policy, endpoint requirements, and the configuration of the remote-access path. Testing the remote-access path is genuinely useful. The policy and the endpoint baseline are separate evidence you still have to produce. Supporting Excluded Record the justification in the SoA
  17. User end point devices Auditor asks for Device management baselines, disk-encryption and compliance reports, and the joiner and leaver process for devices. A penetration test proves nothing here. Device-management reporting is the instrument. Wrong tool Excluded Record the justification in the SoA
  18. Information security in supplier relationships Auditor asks for A supplier register with risk ratings, due-diligence records and review dates. A penetration test proves nothing here. Supplier assurance is a due-diligence and contractual exercise. Wrong tool Excluded Record the justification in the SoA
  19. Managing information security in the ICT supply chain Auditor asks for A component inventory or software bill of materials, and evidence that vulnerable components are tracked and replaced. A test surfaces vulnerable components in what is deployed, which is corroboration. The inventory and its maintenance are the control. Supporting Excluded Record the justification in the SoA
  20. Monitoring, review and change management of supplier services Auditor asks for Service review minutes, supplier reports and assurance artefacts, and records of changes to the service. A penetration test proves nothing here. This is a supplier-management record, not a technical finding. Wrong tool Excluded Record the justification in the SoA

Nothing in ISO/IEC 27001 requires a penetration test. This mapper shows where a test is the cheapest way to evidence a control you have already declared applicable, and where it is the wrong instrument entirely. It is a scoping aid, not an audit opinion, and it cannot see your risk assessment. Control identifiers follow ISO/IEC 27001:2022 Annex A; the normative text is in the standard.

20 controls applicable in this profile. 4 where an independent test is the evidence, 11 where it supports other evidence, 5 where a penetration test proves nothing.

§ 04 Certification calendar

When a test earns its place in the cycle

Accredited certification runs on a three-year cycle with an audit in every year of it. Knowing the shape of that cycle is what stops you buying a test at the wrong time, which is the most expensive scheduling mistake in an ISMS budget.

  1. Stage 1

    Readiness and documentation review

    The certification body checks that the ISMS exists on paper: scope, Statement of Applicability, risk assessment, policies, internal audit and management review. A penetration test is premature here. Findings you cannot yet treat only create open items to explain.

    Test Not yet

  2. Stage 2 minus 6 to 10 weeks

    The test that actually matters

    Far enough ahead to remediate and retest, close enough that the report is current. The evidence pack an auditor likes shows findings, treatment decisions, owners, dates and a dated retest, not a list of open issues.

    Test Yes

  3. Stage 2

    Certification audit

    The certification body audits implementation and effectiveness against your Statement of Applicability. Stage 1 and Stage 2 together are the initial audit, and they open the three-year certification cycle.

    Test Report in hand

  4. Year 1 surveillance

    First surveillance audit

    Around one third of the initial audit time, and never less than one audit day. The question is what changed and what you did about it. An annual test is how A.8.8 stops looking like a one-off before the badge.

    Test Yes

  5. Year 2 surveillance

    Second surveillance audit

    Same cadence. This is where trend matters: an auditor comparing two reports wants to see severity coming down and repeat findings disappearing, not a fresh list of the same issues.

    Test Yes

  6. Year 3

    Recertification

    Recertification takes roughly two thirds of the audit time an initial audit would take today, and it re-examines the whole ISMS. Widen the test scope here. A scope statement written three years ago will not match the estate.

    Test Yes, wider

  7. Any time

    After a significant change

    A new product, a new cloud region, a new external interface, an acquisition, a migration. Scope a test to the change rather than repeating the annual one, and record the decision either way.

    Test Scoped to the change

Cycle facts are from IAF MD 5:2023, the mandatory document that governs how accredited certification bodies calculate audit time: surveillance is “about 1/3 of the audit time spent on the initial certification audit” each year during the initial three-year cycle, recertification is “normally approximately 2/3” of a fresh initial audit, and a surveillance audit is unlikely to be less than one audit day. The testing recommendations in the right-hand column are practice, not requirements, and no clause of the standard sets a testing date.

§ 05 Report specification

What the report has to contain to survive an audit

The standard does not specify a report. Your auditor does, implicitly, by needing to trace a finding from discovery to closure. These ten items are what makes that trace short. Anything missing turns your evidence into a conversation.

  1. A scope statement traceable to the ISMS scope Systems, hostnames, address ranges, cloud accounts and identities, and an explicit list of what was excluded and why. The first thing an auditor compares is the tested estate against the certified estate. Serves ISMS scope · 6.1.3 Failure mode The certificate covers a platform; the report covers one URL.
  2. Dates that are still current The test window and the report date, both visible on the cover. A report that predates your last significant change is evidence about a system that no longer exists. Serves 9.1 Failure mode A two-year-old report presented at surveillance.
  3. A named, versioned methodology For web and API work, the OWASP Web Security Testing Guide v4.2. For the overall process, NIST SP 800-115, which defines the four phases of a penetration test as planning, discovery, attack and reporting, with a loop back from attack to further discovery. Serves A.8.29 Failure mode “Industry standard methodology” with nothing behind it.
  4. Signed rules of engagement Authorization, timing windows, out-of-scope systems, emergency contacts and the handling rules for anything found. This is the artefact that evidences protection of operational systems during testing. Serves A.8.34 Failure mode No written authorization, so the test itself is an unmanaged risk.
  5. Findings on a stated scale, then on yours CVSS v4.0 is the defensible default, with its bands of none, low 0.1 to 3.9, medium 4.0 to 6.9, high 7.0 to 8.9 and critical 9.0 to 10.0. Re-express each finding on your own risk criteria as well, because clause 6.1.2 requires your criteria, not the tester’s. Serves 6.1.2 · 9.1 Failure mode CVSS only, leaving the ISMS manager to redo the rating work.
  6. Reproducible evidence per finding The request and response, the command, the affected asset, a screenshot where it helps. Enough that a third party can see the issue was demonstrated rather than inferred from a version banner. Serves A.8.8 Failure mode A scanner export with plausible findings nobody confirmed.
  7. Remediation guidance a ticket can be cut from Specific to the finding and the platform, not a link to a generic hardening page. If the guidance cannot become a task with an owner, it will not become a risk treatment action either. Serves 6.1.3 · 8.3 Failure mode Advice so general that nothing is ever closed against it.
  8. Dated retest evidence The single most common gap in the packs auditors see. A report with fourteen findings and no retest is evidence of unmanaged risk. The same report with a retest annex is evidence that A.8.8 works. Serves A.8.8 · 10.2 Failure mode Findings closed in a spreadsheet with no technical verification.
  9. A trail into the risk treatment plan Finding, risk register entry, owner, due date, closure record. Auditors follow this trail; the report should make it a short walk rather than an archaeology exercise. Serves 6.1.3 · 10.1 Failure mode The report lives in a folder and never reaches the risk register.
  10. A customer-shareable summary A short attestation or summary letter, separate from the technical report, so procurement questionnaires can be answered without circulating exploit detail. Useful for the audit and immediately useful for sales. Serves A.5.20 · A.5.22 Failure mode The full report is emailed to a prospect, exploit paths included.

§ 06 Why the budget exists

The certificate appears more often in public notices

A full-text search of TED notices finds more mentions of ISO 27001 than of penetration testing. That helps frame a procurement discussion, but it does not establish what a particular buyer requires.

5,241 notices

contain the phrase “ISO 27001”. Widen the query to include “ISO/IEC 27001” and the union reaches 7,540.

TED search API · 2024-01-01 to 2026-09-13 · queried 2026-09-13

24 notices

contain “penetration test” in the same corpus. Add “pentest” and the German “Penetrationstest” and the union reaches 192.

TED search API · same corpus and dates

96,709 valid certificates

ISO/IEC 27001 certificates worldwide across 179,877 sites, every one of them inside an annual surveillance cycle.

The ISO Survey 2024, published September 2025

The mention ratio ranges from roughly 40 to 1 to 220 to 1 with these spellings. Matches count notices, including versions, rather than unique tenders or buyers. They do not establish contractual requirements or account for every language and synonym. Download the queries and count snapshot.

The corpus covers notices published on TED. Procurement not published there, including private procurement, is outside these counts. The ISO Survey 2024 also changed its methodology, collecting data directly from IAF CertSearch across 76 accreditation bodies and more than 2,400 certification bodies. That change limits year-on-year comparisons; the certificate count should not be read as evidence of equivalent market growth.

Commission Implementing Regulation (EU) 2024/2690 points the same way in recital 3: its technical requirements “are based on European and international standards, such as ISO/IEC 27001, ISO/IEC 27002 and ETSI EN 319401”.

§ 07 Impartiality

Who may certify you, and why it cannot be us

This is the paragraph most vendor pages leave out, and it is the one that tells you whether to trust the rest. Certification is a regulated activity with a rule about who is allowed to help you get there.

OffSeq can

Readiness, testing and evidence

Everything that makes you auditable, delivered by people who are independent of your certification body. None of it produces a certificate, and nobody at OffSeq will tell you otherwise.

  • Gap assessment against ISO/IEC 27001:2022 and a prioritized remediation plan
  • Risk assessment, risk treatment plan and Statement of Applicability support
  • Outsourced internal audit under clause 9.2, which explicitly allows an external, independent internal auditor
  • Penetration testing that evidences A.8.8 and A.8.29, with retest
  • A mock Stage 2 that finds the nonconformities before the certification body does
  • Awareness training for A.6.3 and supplier work for A.5.19 to A.5.22

Accredited body only

Issue the certificate

Accredited certification is performed under ISO/IEC 17021-1 by a body accredited for it. That standard bars a certification body, or any body under its organizational control, from providing management-system consultancy to a client it certifies.

  • Conduct the Stage 1 and Stage 2 audits
  • Grant, suspend or withdraw the certificate
  • Run the annual surveillance and the three-yearly recertification
  • Put an accreditation mark on your certificate
  • And, precisely because of that impartiality rule, they cannot also build or audit your ISMS internally for you

Two practical consequences. First, the impartiality rule is a feature, not red tape: it is the reason your customer treats the certificate as worth something. Second, if a supplier offers you certification and consultancy in one package, ask which accredited body issues the certificate and how the separation is maintained. The mandatory documents that govern accredited certification, including the audit-time rules quoted on this page, are published openly by the International Accreditation Forum.

§ 08 The dossier

Four files, written for the auditor’s question

Each one answers a question people ask a week before an audit, with sources you can check and no claim that the standard requires something it does not.

  1. File 01 Does ISO 27001 require a penetration test? No, and the pages telling you otherwise are wrong. Here is the exact chain from your risk assessment to the test report your auditor expects, and what to do if you genuinely do not need one. Open file
  2. File 02 How to scope an ISO 27001 penetration test Scope written from your Statement of Applicability, not from a vendor package. The five inputs, the exclusions you can defend, the wording of the scope statement, and when in the three-year cycle to run it. Open file
  3. File 03 What an ISO 27001 penetration test report must contain The ten sections that let an auditor trace a finding from discovery to closure, why CVSS alone is not enough for clause 6.1.2, and how to produce a customer-shareable summary without circulating exploit detail. Open file
  4. File 04 Who can certify your ISMS, and why it cannot be your consultant Accredited certification, the ISO/IEC 17021-1 impartiality rule, what an outsourced internal audit under clause 9.2 legitimately is, how to choose a certification body, and what a mock Stage 2 actually buys. Open file

§ 09 Questions

The questions asked a week before an audit

Short answers, written to be quoted. The longer versions are in the dossier.

Does ISO 27001 require a penetration test?
No. No clause of ISO/IEC 27001:2022 and no Annex A control names penetration testing, sets a frequency or specifies a methodology. What creates the demand is the chain from your risk assessment to the controls you declared applicable: A.8.8 on technical vulnerabilities, A.8.29 on security testing in development and acceptance, and clause 9.1 on evaluating effectiveness. An independent test is usually the cheapest way to evidence those, which is why auditors expect to see one.
Can a certification body fail us for not having a penetration test?
Not for the absence of a test as such. A nonconformity is raised against a control you cannot evidence. If you can demonstrate that A.8.8 is implemented and effective by other means, say so, show the evidence, and record the reasoning. In practice most organizations find that the alternatives cost more effort than the test.
How often should we test?
The standard sets no frequency. Common practice, and what most certification bodies expect to see at surveillance, is at least annually and after any significant change. The defensible answer is the one your own risk assessment produces, recorded as a decision rather than assumed.
Does the tester have to be external?
The standard does not say so. Clause 9.2 requires internal audits to be objective and impartial, and the same logic makes an external tester easier to defend than the team that built the system. An internal team with genuine independence and demonstrable competence can also work; be ready to evidence both.
What scope should the test cover?
Whatever your ISMS scope and Statement of Applicability say is in scope, minus anything you can justify excluding. If the certificate covers a platform, a test of a single URL is not evidence for the platform. Write the scope statement from the SoA rather than from a vendor price list.
Can our penetration testing provider certify us?
No. Certification is issued by a certification body accredited to ISO/IEC 17021-1, and that standard bars a certification body from providing management-system consultancy to a client it certifies. Your consultant and tester prepare you; an independent accredited body issues the certificate.
Is a vulnerability scan enough instead?
For some estates a scanning programme carries most of the A.8.8 evidence. It does not demonstrate exploitability, chained findings or business-logic flaws, and it will not satisfy A.8.29 for software you develop. Scanning and testing answer different questions, and the report should say which one it is.
Do we have to fix everything before Stage 2?
No. You need a risk treatment decision for every finding, with an owner and a date, and evidence that the process is running. Open findings with a plan are normal. Open findings with no plan, no owner and no date are a nonconformity waiting to be written.
Is a retest required?
No clause requires it. It is still the cheapest way to close the loop, and its absence is the most common weakness in the report packs auditors see. A dated retest annex turns a list of problems into evidence that the vulnerability management control works.
How does this relate to NIS2?
Commission Implementing Regulation (EU) 2024/2690 states in recital 3 that its technical requirements are based on standards such as ISO/IEC 27001 and ISO/IEC 27002, and its Annex point 6.5 requires a documented security testing policy with a defined need, scope, frequency and type of test. Where NIS2 applies to you, security testing stops being a matter of evidence and becomes an explicit legal requirement.

Sources

  1. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 EUR-Lex · 2024 Recital 3 on the standards the requirements are based on; Annex points 2.3 and 6.5 on independent review and security testing.
  2. Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0, and its mapping table version 1.2 ENISA · 2025 Maps each requirement of the implementing regulation to ISO/IEC 27001:2022 clauses and Annex A controls, including 6.5 to A.8.29, A.8.33 and A.8.34, and 6.10 to A.8.8.
  3. IAF MD 5:2023, Determination of Audit Time of Quality, Environmental, and Occupational Health and Safety Management Systems International Accreditation Forum · 2023 The three-year certification cycle, annual surveillance at about one third of the initial audit time, and recertification at approximately two thirds.
  4. IAF mandatory documents International Accreditation Forum · 2026 The published rules that accredited certification bodies operate under.
  5. The ISO Survey of Management System Standard Certifications 2024 ISO, published September 2025 · 2025 96,709 valid ISO/IEC 27001 certificates across 179,877 sites, and the note that this edition collects data directly from IAF CertSearch.
  6. NIST SP 800-115, Technical Guide to Information Security Testing and Assessment National Institute of Standards and Technology · 2008 The four phases of a penetration test: planning, discovery, attack and reporting.
  7. OWASP Web Security Testing Guide v4.2 OWASP Foundation · 2020 The web and API testing methodology to name in a report.
  8. Common Vulnerability Scoring System version 4.0: Specification Document FIRST · 2024 Metric groups and the qualitative severity bands quoted in the report specification.
  9. Directive (EU) 2022/2555 (NIS2) EUR-Lex · 2022 Article 21(2)(e) and (f) on vulnerability handling and on assessing the effectiveness of risk-management measures.
  10. TED search API Publications Office of the European Union · 2026 Search API documentation. The section 6 data download records the exact queries and counts for 1 January 2024 to 13 September 2026.