Table of contents
28
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)
Read this in 30 seconds: You have been told ISO 27001 penetration testing is mandatory, or that it is optional. Both answers are wrong.
- ISO 27001 never names a pentest, but it never lets you ignore technical weaknesses either. None of the 93 Annex A controls in ISO/IEC 27001:2022 mentions penetration testing, yet control 8.8 (management of technical vulnerabilities) expects you to obtain vulnerability information, evaluate your exposure and act, and control 8.29 covers security testing in development.
- The guidance lists a pentest as one option, not the only one. As reproduced by consultancy and vendor pages, ISO/IEC 27002:2022 says “penetration tests or vulnerability assessments” by “competent and authorized persons”, with no frequency attached.
- Sellers say auditors demand a pentest, but no certification body we quote says so. DQS, an ISO 27001 certification body, says pentests “can be planned and performed” and treats scanning tools as acceptable too.
- The timing is not in the standard, and sellers contradict each other. Astra says a report no older than 12 months, 10x Pentest says within six months of the Stage 2 audit, and High Table argues that a once-a-year test is the least you can do, not best practice.
- Almost every ISO 27001 penetration testing price comes from a seller. Scrut, which sells compliance software rather than pentests, reports USD 5,000 to USD 20,000. XHack publishes fixed tiers from $2,500 with the retest included, and scopes differ between quotes, so neither figure is a like-for-like benchmark.
ISO 27001 penetration testing is not a requirement written into ISO/IEC 27001:2022, but it is a common way to show that control 8.8 (management of technical vulnerabilities) and control 8.29 (security testing in development and acceptance) actually work. The standard asks for a working vulnerability management process, and a pentest is one way to show that the process finds real problems.
This guide covers what the standard says, what only vendors say, and what to hand an auditor. It sits inside our wider look at penetration testing for compliance, which compares how major frameworks treat the test.
Not by name. ISO/IEC 27001:2022 does not name a penetration test in any of its 93 Annex A controls and sets no testing frequency, but control 8.8 still expects you to find, evaluate and fix technical vulnerabilities.
That means a working process: gather information about weaknesses, evaluate your exposure, and take appropriate measures. ISO 27001 penetration testing is one common way to prove part of it.
So both popular answers fail. “ISO 27001 requires an annual pentest” is not in the standard. “It is optional, skip it” ignores control 8.8 and the risk assessment you must run.
Our answer: not named, but your risk assessment will probably point to one, so do it properly.
As of September 2026 the current certifiable edition is ISO/IEC 27001:2022, and the current controls guidance is ISO/IEC 27002:2022. Amendment 1:2024 added climate change wording to clauses 4.1 and 4.2 and changed nothing in Annex A.
The move from the 2013 edition ended on 31 October 2025. IAF MD 26:2023 Issue 2 says certifications based on ISO/IEC 27001:2013 “shall expire or be withdrawn at the end of the transition period”, so we use 2022 numbering throughout.
Several controls connect to ISO 27001 penetration testing, but only two come near naming it. The table gives the 2022 title and the 2013 number, since searchers use both.
| 2022 control | Title | 2013 equivalent |
|---|---|---|
| 8.8 | Management of technical vulnerabilities | A.12.6.1 and A.18.2.3 |
| 8.29 | Security testing in development and acceptance | A.14.2.8 and A.14.2.9 |
| 8.34 | Protection of information systems during audit testing | A.12.7.1 |
| 5.36 | Compliance with policies, rules and standards for information security | A.18.2.2 and A.18.2.3 |
| 5.35 | Independent review of information security | A.18.2.1 |
| 8.9 | Configuration management | None, new in 2022 |
| 8.16 | Monitoring activities | None, new in 2022 |
ISO’s own text is paywalled, so the wording below comes from consultancy pages that copy the ISO/IEC 27002:2022 guidance. That is why we say “as reproduced by”.
The control sentence, as reproduced by Pretesh Biswas, High Table and Aviso, reads: “Information about technical vulnerabilities of information systems in use should be obtained, the organization’s exposure to such vulnerabilities should be evaluated and appropriate measures should be taken.” The stated purpose is “To prevent exploitation of technical vulnerabilities.”
The guidance on finding vulnerabilities, as reproduced in full by Pretesh Biswas and in part by Aikido (a pentest vendor), lists “conducting planned, documented and repeatable penetration tests or vulnerability assessments by competent and authorized persons to support the identification of vulnerabilities.”
What that wording does and does not say about ISO 27001 penetration testing:
The same guidance, as reproduced by Pretesh Biswas, asks you to keep an audit log, monitor the process for effectiveness, and after remediation “test to confirm if the remediation or mitigation is effective”. That last line is the retest.
The control sentence, as reproduced by Pretesh Biswas, High Table and Aviso, is “Security testing processes should be defined and implemented in the development life cycle.” The guidance, as reproduced by Pretesh Biswas, lists code review, vulnerability scanning to find insecure configurations, and “performing penetration testing to identify insecure code and design”.
This control covers new systems, upgrades and new versions during development and acceptance. It is not a standing annual test of production, and the extent of testing should be in proportion to the importance and nature of the system and the potential impact of the change.
The reproduced wording of controls 5.35, 5.36, 8.9 and 8.16 does not mention pentests, but a pentest gives each something to point at.
The claim that auditors expect a pentest mostly comes from vendors that sell pentests. No certification body page we quote says a pentest is required or expected.
Two claims, quoted exactly, from sellers of testing:
The second is checkable. The guidance, as reproduced above, lists “penetration tests or vulnerability assessments”, so ISO 27001 penetration testing is one option and not the mechanism.
Four myths are worth clearing out:
Certification runs on a three-year cycle, according to ISOQAR (a UKAS-accredited certification body) and A-LIGN. The initial audit has Stage 1 (documentation review) and Stage 2 (in-depth), annual surveillance audits follow in years one and two, and recertification comes in year three.
During surveillance audits, auditors test a sample of controls rather than everything, according to A-LIGN, and “annual” describes the audit cycle, not testing.
Who decides? The IAF FAQ describes certification as a third-party attestation, and IAF MD 26:2023 says accreditation bodies accredit certification bodies “to issue certificates against ISO 27001”. An accredited certification body’s auditor decides, and a pentest company does not.
What do certification bodies, and one ISO consultancy, say about pentests? Very little, and none we quote makes it a demand.
There is one fair reason an auditor may push harder. Once your risk assessment marks internet-facing systems that hold sensitive data as significant, Iseo Blue (a consultancy, not a pentest seller) says an auditor may raise a finding if the treatment plan includes no independent technical testing. That is a judgment about your risk decision, and not a rule about pentests.
What does a working 8.8 process leave behind? This is our reading of the control sentence and the guidance:
This table is our advice, not the standard’s. It starts from the risk assessment, where ISO 27001 wants the decision to come from.
| Your situation | Our advice |
|---|---|
| Internet-facing app or API holding customer data | Do ISO 27001 penetration testing. This is where a skip is hardest to defend. |
| Mostly internal tools, low-sensitivity data | Scans plus patch records may be enough. Document the decision. |
| You build software, or ship major changes | Test before release, which lines up with control 8.29. |
| A customer contract or your certification body names a test | Do it, and ask exactly what they mean and who they accept. |
Our guide to vulnerability assessment vs penetration testing explains where the line falls. It is blurry, since the 8.8 guidance lists vulnerability assessments beside pentests.
Scope is where ISO 27001 penetration testing is won or lost. The chain runs from your ISMS scope statement to your asset list, to test targets, to documented exclusions.
Clause 6.1.3 requires a Statement of Applicability (SoA) listing the necessary controls, why they are included, whether they are implemented, and why any Annex A control is excluded. A pentest is not on that list. How you meet 8.8 and 8.29 is a risk-based choice you document: scans, a pentest, code review, or a mix.
Clause 8.2 asks for risk assessments “at planned intervals or when significant changes are proposed or occur”, with documented results. Your ISO 27001 penetration testing scope should follow them.
Here is an illustrative example with a fictional company, not a real engagement.
| Step | Example: Larkspur Ledger, a fictional bookkeeping SaaS |
|---|---|
| ISMS scope statement | The production customer platform, its cloud hosting and the staff identity provider |
| Asset list | Customer web app, public API, cloud accounts, identity provider |
| ISO 27001 penetration testing targets | Web app, API and cloud configuration |
| Documented exclusions | Third-party marketing site, with the reason noted in the risk register |
| SoA link | 8.8 and 8.29 marked implemented, with the pentest report named as one piece of evidence |
Write down what you left out and why, because a documented exclusion is easier to defend than a silent gap. For how ISO 27001 penetration testing runs from kickoff to report, see our penetration testing checklist.
The standard sets no pentest frequency. Its interval wording is “planned intervals” in clause 8.2, which you define, and the 8.8 guidance asks that the process be “regularly monitored and evaluated”. Vendors disagree with each other, and none cites a certification body:
| Source | What it says |
|---|---|
| Astra | A report “no older than 12 months”, tested “6-8 weeks before any scheduled audit” |
| 10x Pentest | “within six months of the Stage 2 audit” |
| High Table (sells ISO toolkits) | Argues that testing once a year is the least you can get by with, not best practice |
Our advice for ISO 27001 penetration testing, and it is advice: test annually, test again after a major change, and finish before Stage 2 with the retest closed. Our published sample report recommends the same cadence: “Annually, or on major change”.
Control 8.34 is often called the pentest control, and it is not. As reproduced by Pretesh Biswas, High Table and Aviso, it reads: “Audit tests and other assurance activities involving assessment of operational systems should be planned and agreed between the tester and appropriate management.”
The guidance says to agree the scope of technical tests, limit tests to read-only access where possible, run tests that could affect availability outside business hours, and log all access.
Our reading: a commissioned pentest on a live system is an assurance activity, so 8.34 tells you how to run it safely. It does not require a pentest. Of the consultancy pages that reproduce 8.34, only Aviso names penetration testing, and “rules of engagement” is pentest vocabulary, not the standard’s words.
Agree these in writing before ISO 27001 penetration testing starts:
For ISO 27001 penetration testing the guidance wording is “competent and authorized persons”, as reproduced by Pretesh Biswas and Aikido. It names no certification, no accreditation and no independence.
Your own staff can run ISO 27001 penetration testing if they are competent and authorized. Independence is good practice, especially for control 5.35, and the 8.29 guidance, as reproduced by Pretesh Biswas, asks for independent acceptance testing after the developers’ own tests, but it does not say that tester must be an outside firm.
If a buyer or your certification body names an accreditation such as CREST, ask which one and check the provider’s status. Our guide on how to choose a pentest provider covers the vetting questions. That is different from FedRAMP, which names who may test, as we explain in our FedRAMP penetration testing guide.
What about AI-run testing? The standard is silent on it. Our view is that what counts is a competent human verifying the findings and the work being documented, and we cover it in does AI penetration testing satisfy compliance requirements.
ISO 27001 sets no required contents for a pentest report. The anchor is the 8.8 guidance wording: planned, documented, repeatable, competent and authorized persons, an audit log, and a retest. The rest is what vendors say auditors commonly look for, and the Basis column shows which is which.
| Element | Why it matters | Basis |
|---|---|---|
| Scope matched to your ISMS scope and SoA | Shows you tested what you certified | Logic from clauses 6.1.3 and 8.2, and vendors agree |
| Dates and test window | Shows currency against the audit period | Convention, no standard says 12 months |
| Methodology | “planned, documented and repeatable” | 27002 8.8 guidance wording, as reproduced |
| Findings with severity and evidence | Shows exposure was “evaluated” | 8.8 control sentence, with CVSS as convention |
| Remediation owner and target date | “appropriate measures should be taken” | 8.8 control sentence, and the guidance adds “defining a timeline to react” |
| Retest confirming closure | “test to confirm if the remediation or mitigation is effective” | 8.8 guidance |
| Link into risk register and treatment plan | Shows the loop closes | Clauses 6.1.3 and 8.2, and Strobes, a pentest platform, calls an unlinked report the most common nonconformity |
| Tester competence and authorization | “competent and authorized persons” | 8.8 guidance, with CREST or OSCP named only by vendors |
| Signed scope and agreed windows | “planned and agreed between the tester and appropriate management” | 8.34, our reading |
| Real testing evidence, not scanner output | Separates a pentest from a scan | Vendor position, and the line is blurry |
Our published sample VAPT report is a sample with a redacted client, not a real engagement.
It carries a compliance mapping page and a finding-to-control table, and the ISO/IEC 27001 box reads: “A.8.8, A.8.25, A.8.29. Technical-vulnerability management & secure development.” The report writes controls with an “A.” prefix, but they are the 2022 controls.
The 12 sample findings map to Annex A controls like this:
| Control | Title | Findings mapped |
|---|---|---|
| 8.28 | Secure coding | 4 |
| 8.5 | Secure authentication | 3 |
| 8.24 | Use of cryptography | 2 |
| 8.9 | Configuration management | 2 |
| 8.3 | Information access restriction | 1 |
The document control page shows the other elements:
The report says its retest output is suitable for audit evidence. That is our claim, and the auditor decides.
An ISO 27001 penetration testing report that sits in a folder is weak evidence. The loop an auditor can follow runs from finding to risk register entry, treatment decision, retest and management review. Here it is as an illustrative example with the same fictional company, Larkspur Ledger.
| Stage | Illustrative example |
|---|---|
| Finding | A logged-in user can read another customer’s records through a broken access check |
| Risk register entry | Added as a new risk, with an owner and a target date |
| Treatment decision | Mitigate: fix the access check in the next release |
| Retest | The tester repeats the same steps and records the fix as confirmed, with a date |
| Management review | Closed finding and the time it took are reported at the next management review |
Every row leaves a document behind, which is what an auditor samples. The retest is the easiest row to skip, and the 8.8 guidance names it.
Then you show the process another way. DQS and Advisera both accept scanning as a way to identify weaknesses, so going without ISO 27001 penetration testing does not automatically break the standard.
A fail is not automatic. Iseo Blue’s point stands, though: if your risk assessment flags sensitive internet-facing systems and your treatment plan has no independent technical testing, an auditor may ask why.
What to show instead:
The two frameworks ask for different things. ISO 27001 scopes to your ISMS and Statement of Applicability, while SOC 2 scopes to a system boundary. One round of ISO 27001 penetration testing can still produce evidence for both if the scopes overlap and the report maps to each. The Assurance card on our pricing page says as much for our own reports: “Evidence mapped to PCI DSS, SOC 2, ISO 27001, HIPAA and GDPR”.
Our SOC 2 penetration testing guide covers that side. PCI DSS names the test and ISO 27001 does not, as our PCI DSS penetration testing requirements article explains.
Every ISO 27001 penetration testing price below is published by a seller, except Scrut, which sells compliance software. The quotes cover different scopes and countries, so read them as ranges, not a like-for-like comparison.
| Source | Sells pentests? | Reported price |
|---|---|---|
| Scrut (updated 22 Aug 2025) | No, compliance software | “between USD 5,000 and USD 20,000” |
| DeepStrike (updated 14 Sep 2026) | Yes | A basic external network test “might start around $6,000”; a full multi vector test “could reach $20,000 or more” |
| Cyphere (UK, updated 8 Sep 2026) | Yes | “£3,000 and £10,000” for limited scope; “£8000-£20000” company-wide |
| DSecured | Yes | “starting at 5,000 euros” |
Three sellers report that compliance work raises a standard quote: Software Secured by about 5 to 15 percent for ISO 27001 mapping, Fortbridge by 10 to 20 percent and Budget Security by 10 to 25 percent for compliance-driven tests.
The pentest is one line in the whole journey. High Table, which sells toolkits, budgets “£3,000 and £8,000 per year” for a pentest and reports audit fees of “£6,250 for small organisations (1-10 employees) to £36,875 for large enterprises (8,500+ employees)”, at about £1,500 per UK auditor day.
XHack publishes fixed prices, with the retest included: Essential from $2,500, Assurance from $5,000, Comprehensive from $12,000, and Enterprise custom. Most pentest sellers’ ISO 27001 pages publish no price at all.
We are not claiming to be cheaper, since ISO 27001 penetration testing scopes differ. Our VAPT services buyer guide shows how to compare quotes.
So yeah, here is where we talk about XHack, limits included.
XHack does not certify, approve or issue an ISO 27001 certificate. An accredited certification body issues that, and its auditor decides. What we deliver is a penetration testing report built to give an auditor the technical-testing evidence they look for. In our published sample, the ISO/IEC 27001 box names A.8.8, A.8.25 and A.8.29, and each of the 12 findings is mapped to its own Annex A control.
XHack combines three things most providers sell separately: human-led penetration testing, the XHack AI agent, and a company platform that keeps scanning between tests.
Every engagement includes certified human testers: on Essential, AI agents lead and one certified tester verifies, and Assurance has two OSCP-certified testers working with AI agents. The AI agent runs only with your explicit permission, at no extra cost, and its pentest chats and session data stay on your own machine, where you can delete them any time.
The tier that fits most ISO 27001 penetration testing is Assurance, from $5,000. Its card names “SOC 2, ISO 27001 and PCI DSS cycles, and annual testing obligations” and lists “Evidence mapped to PCI DSS, SOC 2, ISO 27001, HIPAA and GDPR”.
It covers up to 3 unauthenticated web apps, 1 low-complexity authenticated web app, or up to 100 host IPs. Essential suits one small app or up to 50 external host IPs, and Comprehensive suits larger estates and cloud configuration review.
Our certificate of assessment (the pricing page calls it an “attestation letter”) confirms that a pentest was completed. It is not an ISO certificate.
Where we are not the answer: if your buyer or certification body demands a CREST-accredited firm, XHack is not that, since we list OSCP+ and OSCP credentials and do not claim CREST. And if you only need a scan, a scanner or our company platform (from $560 a month) may be enough to evidence the identification side of 8.8.
Our compliance consulting covers gap analysis, policy development, audit preparation and ISMS support.
Want a fixed-price quote? Request one and expect a reply within 24 hours. Brutal honesty is kind of our thing.
No. ISO/IEC 27001:2022 does not name penetration testing in any Annex A control. It requires a working vulnerability management process under control 8.8, and ISO 27001 penetration testing is one common way to show part of it.
Controls 8.8 (management of technical vulnerabilities) and 8.29 (security testing in development and acceptance) are the closest. Controls 8.34, 5.36, 5.35, 8.9 and 8.16 connect more loosely.
The standard sets no frequency, and vendors disagree with each other. Our advice for ISO 27001 penetration testing is annually, after a major change, and before your Stage 2 audit with the retest closed.
Sometimes. DQS and Advisera both accept scanning as a way to identify vulnerabilities, and the guidance lists “penetration tests or vulnerability assessments”. ISO 27001 penetration testing adds depth, and if your risk assessment flags sensitive internet-facing systems, an auditor may expect more than a scan.
The guidance, as reproduced by consultancies, says “competent and authorized persons”, so ISO 27001 penetration testing can be run by an internal team or an outside firm. If a buyer names an accreditation such as CREST, check the provider holds it.
Not automatically, and no certification body we quote says you will. An auditor may raise a finding if your risk assessment points to independent technical testing and your treatment plan has none, so document your decision either way.
No. XHack never certifies, approves or issues ISO 27001 certificates. Only an accredited certification body does that, and our ISO 27001 penetration testing reports are built to give the auditor technical-testing evidence.
ISO 27001 penetration testing is not required by the standard, but skipping technical vulnerability work is not an option either. Control 8.8 asks for a process that finds weaknesses, evaluates exposure and fixes what matters, and in our view a pentest is the most convincing way to show it.
The real work is the paper trail: scope ISO 27001 penetration testing to your ISMS, agree the rules in writing, link findings to your risk register, and retest to confirm the fix.
If you want ISO 27001 penetration testing with a report mapped to the controls an auditor asks about, see the fixed-price tiers. We will tell you honestly if a scan is all you need.
Categories
Related articles
