ISO 27001 penetration testing: what auditors expect in 2026

ISO 27001 penetration testing is a scoped, authorised test in which a qualified person tries to exploit your application, API or infrastructure, and writes down what worked. ISO/IEC 27001:2022 does not name it as a mandatory activity. But Annex A controls 8.8 and 8.29 ask you to find and fix technical vulnerabilities, and a penetration test report is the evidence teams most often hand over for them.

Below: what the standard says, which controls a test supports, how often to test, how to scope it and what to hand the auditor. Then the step most guides skip, which is what to do with the findings.

What is ISO 27001 penetration testing?

ISO 27001 penetration testing means running a penetration test whose scope, schedule and results feed your information security management system (ISMS). The test itself is ordinary. The difference is the paperwork around it: the scope ties to your ISMS scope, the findings flow into your risk treatment, and the report becomes audit evidence.

The NIST Computer Security Resource Center glossary, quoting NIST SP 800-115, defines penetration testing as testing in which evaluators imitate real attacks to find ways around a system’s security features. The wording matters: a penetration test is an attempt to get past your controls, not a list of software versions.

Penetration test, vulnerability scan and audit are different things

Teams often hand an auditor one when the auditor expected another. This table shows what each activity produces and what it can prove.

If you want the background on the terms, see our guide to what VAPT is and the Knowledge Hub entries on vulnerability scanning and manual pentesting.

Does ISO 27001 require penetration testing?

No, not by name. ISO/IEC 27001:2022 sets requirements for an ISMS and lists 93 Annex A controls, and none of them says “you must commission a penetration test every year”. What the standard requires is that you manage technical vulnerabilities and test security in development, using methods that fit your risks. For most software companies, a penetration test is the most defensible way to do both.

What the standard says

The ISO/IEC 27001 management clauses require you to assess risks, choose treatments, and record your choices in a Statement of Applicability. You decide which Annex A controls apply and how they are implemented. If you mark 8.8 and 8.29 as applicable, which almost every company that ships software does, you must be able to show how they operate.

The companion standard, ISO/IEC 27002:2022, gives implementation guidance. Its guidance for control 8.29 lists three methods: code review to find security flaws, vulnerability scanning to find insecure configurations, and penetration tests to detect insecure code and design. Guidance is not a requirement, but auditors read it as the benchmark for “what good looks like”. Both standards are paywalled, so read the licensed text, not summaries like this one.

Four clauses connect a test to the management system: 6.1.3 (risk treatment), 9.1 (monitoring and measurement), 9.3 (management review) and 10.2 (nonconformity and corrective action). A report that reaches none of them is a document, not evidence.

What auditors do in practice

An accredited certification body audits in two stages: a documentation and readiness review, then an assessment of whether controls operate. Surveillance audits follow, with recertification at the end of the three-year cycle. In each, the auditor samples evidence.

When the auditor reaches vulnerability management, expect questions such as these.

How do you find technical vulnerabilities in your applications?

An answer of “we run a scanner weekly and commission an annual penetration test” is concrete and checkable. An answer of “our developers are careful” is not.

Show me the last test and what you did with the results

The report is the start. The auditor wants to see tickets, owners, dates, retest results and, for anything not fixed, a documented risk acceptance.

How do you decide when to test?

Written triggers (a major release, a new integration, an architecture change) show a process rather than a habit.

Which Annex A controls does a penetration test support?

A penetration test mainly supports control 8.8 (management of technical vulnerabilities) and control 8.29 (security testing in development and acceptance). It also produces evidence for several neighbouring controls on secure development, configuration, change and incident handling. The table maps them. Control numbers follow the 2022 edition; the 2013 edition used a different numbering, so older guides cite A.12.6.1 and A.14.2.8 instead.

Control-to-evidence mapping

The Knowledge Hub has short entries on ISO 27001 and Annex A if you need the terms first.

Control 8.8: management of technical vulnerabilities

This control is about a loop: learn of vulnerabilities, judge your exposure, then act in time. A scanner tells you about known flaws in components. A penetration test tells you about flaws in your code and configuration that no feed has heard of, such as a missing ownership check on an invoice endpoint. Auditors who see both have a fuller answer to “how do you learn of vulnerabilities?”.

ISO/IEC 27002 guidance for 8.8 also says to resolve vulnerabilities in good time and to treat high-risk and business-critical systems first, so rank your test scope the same way. Keep the other half visible too. The control is judged on what you did next. A report with 20 findings and no ticket trail is weaker evidence than one with 5 findings and a clean fix history. See remediation SLAs and the vulnerability remediation process.

Control 8.29: security testing in development and acceptance

This control asks you to define security testing processes and run them as software is built and accepted. The words “acceptance” and “development life cycle” matter: a single annual test of production does not by itself show testing runs as part of releases. Pair the annual test with checks in the pipeline, such as static analysis, dependency checks and security gates in CI/CD.

Why do auditors care about application-level testing at all?

Because the flaws a test finds are the ones real incidents are built from. Four public figures show what real incidents are made of:

• Verizon’s 2025 Data Breach Investigations Report examined over 22,000 security incidents, including 12,195 confirmed data breaches, and reported that exploitation of vulnerabilities as an initial attack vector rose 34% and now accounts for 20% of breaches.
• The same report says third-party involvement in breaches doubled to 30%, which is why supplier controls and your own customers’ security questionnaires lean on certificates like ISO 27001.
• The OWASP Top 10:2025 keeps Broken Access Control at number one, mapping 40 CWEs with an average incidence rate of 3.74% and 1,839,701 total occurrences in its data set.
• IBM’s Cost of a Data Breach Report 2026 puts the global average cost of a breach at USD 4.99 million, a 12% increase and a record high.

Scanners find known-component flaws well, but access-control and business-logic flaws depend on how your app decides who may do what. That is where a proof-driven test earns its place. See broken access control and business logic flaws.

The CISA Known Exploited Vulnerabilities Catalog showed 1,734 entries when we read it on 7 October 2026. Each entry has been seen exploited in the wild, so it is a useful input for control 8.8; see the KEV catalog.

How often should you run an ISO 27001 penetration test?

At least once a year and after any significant change is the common expectation, though the standard sets no fixed interval. Your own policy decides, and the auditor checks that you followed it. A written rule such as “annual external test, plus retest after major releases” is easy to defend.

Tie frequency to risk: the more often you ship, and the more sensitive the data, the shorter the gap. Our guide to continuous penetration testing explains how to run a yearly deep test alongside lighter checks between releases.

Triggers worth writing into your policy

• A new customer-facing application or major feature
• A change to authentication, roles, payments or tenant separation
• A new third-party integration or public API

A twelve-month plan an auditor will recognise

How do you scope a penetration test for ISO 27001?

Start from your ISMS scope and your risk assessment, then list the systems that hold or process the information you promised to protect. The test scope should be a subset of the ISMS scope that you can explain, not a convenient slice. Auditors check that systems in the ISMS scope are either tested or have a recorded reason why not.

Six steps to a defensible scope

1. List assets in the ISMS scope. Production applications, APIs, admin tools, cloud accounts, and the identity provider.
2. Rank by risk. Use your risk register: customer data, payments, and anything internet-facing come first.
3. Decide the test depth. Black, grey or white box (next section), and whether to include authenticated testing for several account types.
4. Write rules of engagement. Dates, targets, test accounts, data handling and who to call. Control 8.34 is written for audit testing, but the same habit of agreed access and safe windows applies. See rules of engagement and pentest scope.
5. Name exclusions and reasons. Third-party systems you cannot authorise testing on belong in the record with the reason.
6. Get written authorisation. From the system owner, and from the hosting provider where its rules require it.

Test the application layer, not just the network

Many pentests are scoped as an external network scan because that is easy to describe. If your product is a web or mobile app, the risk lives in the application and its APIs: authorisation, sessions, input handling and business rules. The OWASP Web Security Testing Guide is the open methodology most testers map their work to; its current stable release is version 4.2. Our guides to web application and API testing go deeper.

Include more than one account type

If your app has customers, staff and administrators, give the tester a separate test account for each. Most serious findings in business software are one signed-in account reaching another’s data or functions. Without them, the test sees only what an anonymous visitor sees.

Black box, grey box or white box: which suits ISO 27001?

Any of the three can satisfy an auditor, provided the choice is justified by risk. Grey box is the most common fit for an application inside an ISMS, because it tests behind the login with some knowledge of the system, as a real customer or insider would. The table summarises the trade-offs; our full comparison is in black box vs grey box vs white box testing.

A sound plan for a software company is a grey-box test of the main application and its APIs each year, with white-box depth for the most sensitive components, and a black-box check of the internet perimeter. Cyberlop runs all three modes, and in white-box mode it reads your code while testing the running app, so a finding can point to the file and line. See how it works.

What evidence does an ISO 27001 auditor want from a pentest?

The auditor wants proof that you tested, that the test fit your risks, that you acted on it and that the actions worked. A report alone covers the first claim. Assemble a short evidence pack so the auditor finds the other three in one place.

The evidence pack

What a good report contains

It names scope, dates, method and tester, and lists each finding with severity, reproduction steps, evidence and a fix. Keep severity and confidence separate: an exploited finding differs from a suspected one. Our guide to reading a penetration test report covers this.

What should you do with penetration test findings?

Treat each finding as a risk-register item: assign an owner, set a due date from your severity policy, fix it, then prove the fix. A finding closed without a retest is a claim, not evidence. Auditors can raise a nonconformity if the same weakness keeps appearing, because clause 10.2 expects corrective action that addresses causes.

From finding to closed

1. Triage. Confirm it is real, set severity from impact and exploitability, and note confidence. See severity vs confidence.
2. Assign. One named owner and a due date from your remediation SLA.
3. Fix the cause. Patch the instance and the pattern. If one endpoint lacked an ownership check, look for the others.
4. Verify. Re-run the exact steps that exploited it. See fix verification and closed-loop retest.
5. Accept or defer in writing. If you cannot fix something, record who accepted the risk, why, and when it will be reviewed.
6. Report upward. Feed counts and ageing into management review. Mean time to remediate is a metric auditors like because it shows the loop working.

Cyberlop reports what it actually exploited: each finding carries the request, the response, a screenshot where a person can see it, and the line of code. A fix is proven by re-running the exact exploit against the new code, not by a fresh scan. That gives you the “verified fix” row of the evidence pack. See the evidence we keep.

Who should run the test: internal team or an outside provider?

Either can be accepted, but an outside party gives stronger evidence because it is independent of the people who built the system. Use internal and automated testing continuously, and an external test for annual assurance.

What to ask a provider

• Can they map findings to CWE and OWASP references, and show how they decide severity?
• Do they provide evidence a developer can reproduce, not just scanner output?
• Is a retest included, and how is it done?
• Can the code stay inside your network if it must? Cyberlop offers private scanning for that case.

Our guide to choosing a penetration testing company has a longer list. If your customers or regulators also name specific empanelment, check that separately; see CERT-In empanelled VAPT.

Can one pentest serve ISO 27001, SOC 2 and PCI DSS?

Often yes, if the scope and method meet the strictest framework you answer to. A single well-scoped application test can feed ISO 27001 controls 8.8 and 8.29, SOC 2 vulnerability-management criteria and the testing requirements of PCI DSS. The catch is that PCI DSS sets prescriptive rules on methodology, qualification and retesting that ISO 27001 does not.

Write the scope once, list each framework it serves, and keep one evidence pack. Read SOC 2 penetration testing and PCI DSS penetration testing requirements before you merge. India-based teams can also see DPDP Act security requirements.

What changed with ISO/IEC 27001:2022 and the transition?

ISO/IEC 27001:2022 replaced the 2013 edition, cut Annex A from 114 controls to 93, and regrouped them into four themes. Two controls most relevant here are new or reworked: 8.29 merges the old testing controls, and 8.8 replaces the old technical-vulnerability control. The transition period closed on 31 October 2025.

The NSAI, the Irish certification body, states in its transition policy that after 30 April 2024 all initial certifications must be to the 2022 edition, and that after 31 October 2025 certificates to the previous edition expire and certification is formally withdrawn. In 2026, then, any certificate you hold or are pursuing is against the 2022 edition, and guidance that still cites A.12.6.1 is out of date.

What mistakes do teams make with ISO 27001 pentests?

Mistakes auditors notice

Testing only what is easy to describe

An external IP scan ticks a box but misses the application holding customer data.

Filing the report and stopping

Auditors read the follow-up. No tickets, no retest and no management minutes means the control looks like it exists on paper only.

Writing a policy you cannot keep

“Quarterly full pentest” in the policy and one test in the diary is a nonconformity of your own making. Write the interval you will actually meet.

Letting the report age

A 14-month-old report under a 12-month policy is a nonconformity waiting to be written. Book the next test when the current report arrives.

Where does Cyberlop fit in an ISO 27001 programme?

Cyberlop finds vulnerabilities in web apps and their APIs with black-box, grey-box and white-box pentesting, and keeps the evidence an auditor asks for: what was exploited, the request and response, the code line, severity kept apart from confidence, and a retest that re-runs the exploit. It can run on a schedule or in CI/CD and gate a build, which speaks to control 8.29.

It checks business-logic flaws and cross-account access, the weaknesses that scanners tend to miss. It does not replace your ISMS, your risk assessment or your auditor’s judgement. For what we will and will not claim, read how we describe our limits.