This site may contain affiliate or referral links. If you buy through one, we may be compensated. How we make money

ISO 27001 penetration testing: what's required and what to buy

By The PenTest Index · Requirements and offer terms checked October 9, 2026

ISO 27001 penetration testing is not a named requirement: the word "penetration" does not appear anywhere in ISO/IEC 27001:2022. What can hold you to a test is what you wrote in your own Statement of Applicability and policies, plus applicable legal, regulatory or contractual obligations. Your certification auditor may ask you to show evidence that those requirements and controls work. Check those sources before you buy anything.

Is ISO 27001 penetration testing mandatory?

No. The standard never tells you to run a penetration test, and it sets no testing schedule. It tells you to work out your risks, choose controls that deal with them, and show that those controls work. A penetration test is one way to show that. It is a common way, and often the right one, but the standard leaves the choice to you.

Here is what the text says, in our words. We read the clauses listed on October 9, 2026.

Table columns: Where; What it says; What that means for you.
Where	What it says	What that means for you
ISO/IEC 27001:2022, clause 6.1.3	Decide which controls you need to treat your risks. Compare them with the list in Annex A so you don't miss any. Write the result in a Statement of Applicability.	You choose the controls. The standard calls Annex A "a list of possible information security controls" and says it is "not exhaustive."
Annex A, control 8.8, Management of technical vulnerabilities	Find out about weaknesses in the systems you use, judge your exposure and act on it.	If this control is necessary for your risks, you need a working way to find and fix weaknesses. No method is named.
Annex A, control 8.29, Security testing in development and acceptance	Define security testing and carry it out as part of building software.	If this control is necessary for software you build, you need a testing process you actually follow.
ISO/IEC 27002:2022, guidance for 8.8 and 8.29	This companion document gives advice, not rules. It suggests considering "penetration tests or vulnerability assessments by competent and authorized persons," and lists scanning and penetration testing among ways to test software.	A penetration test is one recognised option. It is not the only one.

A Statement of Applicability is your own list of which controls you chose, why you chose them, whether they are in place, and why you left any out.

So where does a real requirement—or a demand for more evidence—come from? Three places, and you can check all of them this week.

Table columns: Source; Where to look; What it does to your purchase.
Source	Where to look	What it does to your purchase
Your own words	Statement of Applicability, risk treatment plan, vulnerability and development policies	If your policy says "annual penetration test by a third party," a certification audit can assess you against that requirement. Most real requirements start here.
Your certification audit	Audit criteria and written evidence requests	The auditor assesses your evidence against the audit criteria. Their answer on automated testing can show whether that evidence supports your selected controls, but it does not create a new ISO rule.
Customers and other rules	Contracts, security questionnaires, SOC 2, PCI DSS	Often the strictest. A contract that says "penetration test" creates a separate requirement whatever ISO says.

Three questions to send your auditor today:

"Is automated testing on its own acceptable evidence for the controls we selected?"
"How recent does the testing need to be when you audit us?"
"Do you need proof that findings were fixed and checked again?"

One version check while you have your files open. The current edition was published in October 2022, with a 2024 amendment about climate that does not add a penetration-testing requirement or schedule. Accredited certificates covered by IAF MD 26 had to complete the transition by October 31, 2025, and certifications still based on the 2013 edition had to expire or be withdrawn then. The control numbers changed between editions. If a provider's report or sales page still cites "A.12.6.1," it is using the retired numbering. We found exactly that in one widely read vendor guide on October 9, 2026 (Blaze's guide). Ask for 2022 numbering.

Do you need a new test, a top-up or nothing?

Pick your next step by the gap between what you are required to show and what you can show today. Many readers do not need a full new test.

Table columns: Your situation; What we'd do; What could change it.
Your situation	What we'd do	What could change it
You have a recent test that covers the systems in your ISMS scope, and fixes were checked	Buy nothing. Keep the report, the fix record and a note of when you will review it.	Big changes since the test, or a policy that sets a shorter gap.
You have a useful test, but you have since added an API, changed login or launched something new	Ask the firm that did it for a top-up covering the changes.	The auditor or customer wants one current report, not two.
The only thing missing is proof that a fix worked	Ask for a fix check (a retest). Don't pay to repeat the whole test.	The fix changed other parts of the system.
A test is required and you have nothing suitable. Your scope is one web app and its API	Buy a human-led web app and API test with a fix check included.	Your auditor and customers say in writing that automated testing is fine.
Your scope also covers internal networks, cloud accounts or offices	Get a scoped quote from a firm that tests those.	Your risk assessment gives a recorded reason to leave them out.
Nobody can tell you what the test is for	Don't buy yet. Ask the question below.	A written answer.

ISMS means information security management system: the set of policies, people and controls your certificate covers.

The question to send whoever asked for the test: "Which requirement does this evidence need to meet, which systems must it cover, and what do you need to see by what date?"

Already know the test and scope you need? Compare published penetration testing offers. Not sure which kind of test you need? See which penetration testing service fits.

Can you reuse a penetration test report you already have?

Yes, but only for what it actually covers. A report proves that certain systems were tested on certain dates. It does not cover things you built later, and a ticket marked "fixed" is not a checked fix.

Here is how that plays out. This example is invented. The company, documents and deadlines are not real, and no provider quoted for it.

Say you run a 35-person SaaS company. An outside firm tested your web app four months ago. A month later you launched a public API and changed how login works. One finding from the old report is marked fixed in an engineering ticket, but nobody has checked it. Your policy says "annual penetration test by an independent third party." A customer wants proof of third-party testing of the current app and API within the last 12 months, plus proof the old finding was fixed. Your certification audit is 12 weeks away.

Our read: you may not need to start over, and the old report alone is not enough. Ask the firm that did the first test for a written proposal covering the new API, the login change and a check of the old fix. Ask the customer whether an older report plus a top-up will do.

Table columns: What's required; What you have; Finding; What settles it.
What's required	What you have	Finding	What settles it
Testing within the last 12 months	Report shows testing four months ago	Supported, for the date only	Reissuing the report with a new cover date does not change when testing happened.
Covers the current app and API	Report was written before the API existed; login has changed since	Mismatch	Testing of the API and the changed login paths.
Done by an outside party	Old report names an outside firm	Supported for the old test; open for new work	Who will do the top-up?
Earlier finding fixed and checked	A ticket says "fixed"	Unresolved	A dated fix check from a tester.
Old report plus top-up is acceptable	No written answer from the customer	Unresolved	Ask. If the answer is no, buy one test of the whole current system.

"Supported" here means that one condition is met by that one piece of evidence. It is not a quality score and it does not promise anyone will accept the report.

ISO 27001 testing evidence plan

Your testing evidence plan

Copy this into your own document and fill it in. It works for an audit, a customer request or a renewal. Leave any answer you don't have as "Unknown, confirm with [name]." Don't guess.

The decision. What needs deciding, who owns it, and by when?
Where the requirement comes from. Policy, contract or evidence request. Paste the exact wording and the date.
System and purpose. Which system, and what question must the evidence answer?
Your control choice. What your Statement of Applicability or risk treatment plan says. Don't assume a test from a control number alone.
Evidence you already have. Report name, actual test dates, version or environment tested, method, what was left out.
What changed since. New features, APIs, login, permissions, integrations, hosting.
Findings. What was found, who owns each one, where it stands, what has been checked.
What the evidence covers and what it doesn't. One line each, with the reason.
Work still needed. Nothing; missing paperwork; a top-up; a fix check; a different kind of testing; or a full new test.
Buying conditions. Must-haves and nice-to-haves for scope, who tests, the report, timing, fix-check terms, full price and exclusions.
Sign-off and review. Who confirmed what against which requirement, what is still open, and what date or change triggers a review.

This is our worksheet, not an ISO form, and it is not permission to test. Get written authorization covering the actual targets and activities before any testing starts. Keep passwords, keys and details of weaknesses out of it.

Prepared with The PenTest Index: https://thepentestindex.com/iso-27001-penetration-testing/

Which offers fit an ISO 27001 buyer who has to buy?

If you need a new test of one web app and its API that includes manual human testing, with proof of fixes before your audit, Astra's Pentest Expert plan is the closest published fit, but confirm in writing that the API falls within Astra's one-target definition, the quote covers both user roles and what dated evidence you receive after a rescan. Of the offers we checked, it is the only one that publishes a price, says the APIs consumed by the app are included, and publishes a manual fix check. The catches are a 30-day clock for requesting that rescan and Astra's requirement that at least 50% of the Critical and High findings be fixed before the request.

We took the buyer from the example above and assumed they had to buy new work: one web app and its API, two user roles, people doing the testing, and a dated fix check before the audit. Then we read each provider's own published terms against those needs. We have not bought or run these tests, and no provider quoted for this example. Prices are in US dollars.

Table columns: Offer; Published price and what it covers; Fix check; Finding for this buyer.
Offer	Published price and what it covers	Fix check	Finding for this buyer
Astra · Pentest Expert	$5,999 a year for one target. Astra says one web or SaaS app counts as one target, including the APIs it uses. The plan lists a manual pentest by certified experts alongside automated agents. (pricing, checked October 9, 2026)	Two manual rescans, reviewed by Astra's security engineers. Before requesting one, Astra requires at least 50% of the Critical and High severity vulnerabilities to be fixed, the request to fall within 30 days of the date the findings were reported, and an available manual rescan to remain. Astra says manual rescans are typically completed within 3–9 business days and update vulnerability statuses. Extensions require approval. (rescan rules, request instructions and extension rules, checked October 9, 2026)	Web-app coverage, its consumed APIs and human testing: supported by the published terms. Whether this buyer's public API is consumed by that app or counts as a separate target, and coverage of two user roles: unresolved. Manual fix verification: supported if an unused manual rescan remains, you fix at least 50% of the Critical and High findings and request it within 30 days of the findings being reported; the dated document is unresolved. A later request mismatches the published window unless Astra extends it in writing.
Pentest-Tools.com · Grey box web app test	Starts at $3,400 plus $900 per user role. For two roles that is $5,200 as a starting amount (our sum: 3,400 + 2 × 900). Manual testing, 4 or more working days. (service page, checked October 9, 2026)	Not mentioned on the page.	Human testing: supported. API coverage and fix check: unresolved. The $5,200 does not price either one, so the real total is not known yet.
Cobalt · Standard or Premium	Quote required. Credits are sold in annual packages; the number of tests depends on the credits required for each scope. (pricing, checked October 7, 2026)	For Agile and Comprehensive pentests, free retesting is available for 6 months (Standard) or 12 months (Premium) while the contract is active. Requests close at the earlier of the tier period's end or 10 days before the contract ends. (retest policy, checked October 7, 2026)	Published tier duration: 6 or 12 months, subject to the active-contract cutoff, and longer than Astra's 30-day published duration. The duration's trigger, this buyer's actual cutoff, dated retest output, price and commitment: unresolved until quoted.

How to choose between them:

You can meet Astra's manual-rescan prerequisites inside 30 days and want a published annual price. Astra Pentest Expert, once Astra confirms the API counts inside the app target, both user roles and the dated rescan evidence. Astra requires at least 50% of the Critical and High findings to be fixed before a manual rescan request and an unused manual rescan to remain, so plan your engineers' time now.
You want a one-off project, not a yearly plan. Pentest-Tools.com, but only once they confirm in writing that the API is in scope and what a fix check costs.
Your fixes will take months, or you need an annual testing program. Get a Cobalt quote for the longer published tier duration, and have the window trigger and active-contract cutoff confirmed.
Your scope is wider than a web app and API. Astra and Cobalt both list wider target or service categories, but this comparison does not establish the full scope or total price. Get a scoped quote.

What about AI-led tests? Some publish lower prices and faster stated reporting than the offers above that include human testing. Whether one counts depends on your policy and other requirement wording, and on whether its evidence satisfies the audit criteria. Intruder's page promises, "If your auditor rejects the report, we refund the test in full" (Intruder, checked October 9, 2026). That is a refund. It is not acceptance in advance, and its process starts with connecting your code repository.

Questions to send before you pay:

To Astra: "Does our API count inside the app target or as another target? If our fixes take 45 days, will you extend the rescan window, and what does that cost? What dated document do we get after a rescan?"
To Pentest-Tools.com: "For one web app, its API and two roles, what is the full price including one manual retest and a written retest result?"
To Cobalt: "How many credits does this scope need, and what is the smallest contract you'll sell?"
To all three: "Will the report use ISO/IEC 27001:2022 control numbers? Does your company or group also certify ISO 27001 systems?"

See Astra's Pentest Expert plan

See the grey box web app test

See Cobalt's packages

We go deeper on each in our Astra, Pentest-Tools.com and Cobalt profiles.

Your scope is probably not identical to our example. Find My PenTest Match asks a few quick questions, shows which of the offers we compare fit your answers, and gives you a brief to send to the providers you pick. It's free, needs no email or sign-up, and nothing is sent to providers. It compares web app and API offers, so it helps less with network or cloud scopes.

Find My PenTest Match

When should you book before the audit?

Work back from the audit date. You need time to scope, test, fix and check the fixes. A provider's stated testing time covers only part of that timeline.

A worked example, with our own placeholder numbers where a provider publishes none:

Table columns: Stage; Time; Where the number comes from.
Stage	Time	Where the number comes from
Scoping and access	1 week	Our placeholder
Testing	4 weeks	Astra's help pages gave up to 20 working days for a manual test when we read them on October 7, 2026; its pricing FAQ says 10 to 15
Fixing findings	3 weeks	Your own estimate goes here
Fix check and final report	2 weeks	Astra says a manual rescan typically takes 3–9 business days; two weeks is our conservative calendar conversion. Final report or certificate timing remains unresolved.
Total	10 weeks

For an audit on March 1, 2027, ten weeks back is December 21, 2026. That is the latest sensible booking date, with no slack for holidays.

Two things the table hides. A stated testing time is not a reserved slot, so ask for the start date and final report date in writing. And Astra's 30-day rescan window starts when the vulnerabilities are reported, not when the test ends. A three-week fix estimate may fit only if at least 50% of the Critical and High findings are fixed and the rescan request is still inside that window; five weeks exceeds the default window. Astra says the manual rescan itself typically takes 3–9 business days.

Is a vulnerability scan or an AI pentest enough?

Sometimes, and it is not the standard that decides. The applicable requirement does: your own policy wording, customer obligations and the audit criteria.

A vulnerability scan is software that checks your systems for known weaknesses. A penetration test goes further: a tester tries to break in and shows what an attacker could really do. The ISO guidance mentions both. It suggests "vulnerability scanning tools" in one place and "penetration tests or vulnerability assessments" in another, and it ranks neither above the other.

Two checks settle most cases:

Read your own words. If your policy or a contract says "penetration test," a scan report with a new title does not meet it.
Judge the work, not the label. For any AI-led or automated offer, ask what it tested, what a person reviewed, and what it left out. Then put question 1 to your auditor.

Some vendor guides say a scan is never enough for ISO 27001. That is their view. The text does not say it. More on the difference: penetration testing vs vulnerability scanning.

How often do you need to test?

As often as you committed to. The standard sets no interval for penetration testing.

What it does say (clause 8.2) is that you reassess risk "at planned intervals" or when significant changes happen. That is about risk assessment, not testing. Yearly testing is common practice and many customers ask for it, but it comes from policies and contracts.

Thinking of moving from yearly to every two years? Don't just edit the policy. Look at what changed in your systems, what the last test found, what other security work you do in between, and what your contracts say. If those support a longer gap, record why. If a contract says annual, the contract wins.

One tip: write only what you will do. Put "quarterly penetration test" in a policy and a certification audit can assess you against it.

Who can do the test?

Anyone competent and authorized, as far as the ISO guidance goes. It does not demand an outside firm or a named credential. Your policy, your customer or another applicable requirement might, so check the wording.

For software you build yourself, the guidance suggests the developers test first and that independent acceptance testing follows. "Independent" does not have to mean an outside company.

Can your certification body do it? Safer not to. The rules certification bodies work under say a body "shall not provide internal information security reviews of the client's ISMS" it certifies. That is ISO/IEC 27006-1, clause 5.2.2, as quoted by European Accreditation. The clause does not mention penetration testing, so each body judges its own case. You don't need to win that argument. Buy from a firm with no tie to whoever certifies you and the question goes away. Some audit firms sell both, which is why it is on the question list above.

Need a CREST-accredited firm? Only if someone requires it. If they do, check the provider's exact company name on CREST's own list. Don't rely on a logo on a sales page.

What should you hand the auditor?

A trail, not just a PDF. The auditor wants to see that you found weaknesses, dealt with them and can prove it.

Table columns: Item; What it shows.
Item	What it shows
The requirement and scope	Why you tested, and that the test covered systems inside your ISMS scope
The report	What was tested, when, how, what was left out and what was found
The fix record	Who owned each finding, what was decided and when it was done
The fix check	What was tested again, when, by whom and the result
Open items and next review	What is still open, why, and when you will look again

A penetration test is not your ISO internal audit. The internal audit (clause 9.2) checks whether your whole management system meets the standard and your own rules. A clean test report does not replace it, and a report with findings does not mean you fail.

The auditor evaluates whether the evidence is sufficient against the audit criteria. No provider's "audit-ready" label is your auditor's approval. More on reading and using a report: penetration testing report.

How much does an ISO 27001 penetration test cost?

There is no ISO price. You pay for scope. For one web app, the offers we checked that include human testing publish a starting amount of $5,200 (Pentest-Tools.com grey box, two roles, API and fix check not priced) and $5,999 a year (Astra Pentest Expert, one target, two rescans included).

Be careful with "typical" ranges. One vendor guide gives $6,000 to $25,000 with no source or date. That is the vendor's own claim, not a market figure. For published prices by scope, and what each one leaves out, see penetration testing cost.

Questions buyers still ask

Is an "ISO 27001 pentest" different from ISO 27001 penetration testing?

No. It's shorthand. Neither phrase appears in the standard. Both mean a normal penetration test scoped and documented so it works as evidence for an ISO 27001 audit.

A supplier is ISO 27001 certified. Does that mean their product was pen tested?

No. A certificate covers the scope written on it and says the management system met the standard. It does not say a given product version, API or customer setup was tested. Ask the supplier what was tested, when, and whether you can see a summary.

Can one test serve ISO 27001 and SOC 2?

Often, if you scope it once for both and each recipient agrees. The testing is the same work. What changes is who reads the report and what they ask for. See SOC 2 penetration testing.

Our auditor rejected our report. What now?

Ask for the reason in writing. Then run it through the evidence plan above. The gap is usually one of three things: the test covered the wrong systems, there is no fix check, or the document is a scan. Fix that gap, not the whole test.

Already holding a quote? Check it against the same questions.

Sources and how we checked

We read each source below on the date shown and wrote the explanations in our own words. Provider terms are what each provider publishes. We have not bought the services or tested their quality. The example company is invented. We don't sell or perform penetration tests, and nothing here is your auditor's decision or legal advice. More on our method: how we check offers.

ISO, ISO/IEC 27001:2022 catalogue page: edition, publication date and amendment. Checked October 9, 2026.
ISO/IEC 27001:2022, clauses 6.1.3, 8.2 and 9.2, and Annex A controls 5.35, 8.8, 8.29 and 8.34. Text read October 9, 2026. The standard is sold by ISO.
ISO/IEC 27002:2022, guidance for controls 8.8 and 8.29. Text read October 9, 2026. Sold by ISO.
ISO, conformity assessment and auditing techniques: applicable requirements, audit criteria and audit evidence. Checked October 9, 2026.
International Accreditation Forum, IAF MD 26:2023: transition deadline and the expiry or withdrawal of remaining ISO/IEC 27001:2013 certifications within its stated applicability. Checked October 9, 2026.
European Accreditation, FAQ on ISO/IEC 27006-1 clause 5.2.2. Checked October 9, 2026.
Astra, pricing, rescan rules, rescan request instructions and timing and extension rules. Checked October 9, 2026. Testing time re-read during the factual audit.
Pentest-Tools.com, web application penetration testing. Checked October 9, 2026.
Cobalt, pricing and retest policy. Checked October 7, 2026.
Intruder, pentest pricing: refund promise. Checked October 9, 2026.
Blaze Information Security, ISO 27001 penetration testing guide: control numbering and price range. Checked October 9, 2026.