ISO 27001 Penetration Testing: Annex A Mapping, Frequency and Auditor Evidence (2026)

Quick answer: ISO/IEC 27001:2022 does not require a penetration test, and it sets no testing frequency. The standard's normative clauses are 4 to 10, and the ISO catalogue entry and Online Browsing Platform show that none of them names penetration testing. Neither does any of the 93 Annex A control titles: the complete reference set, published as ISO/IEC 27002:2022, contains no control whose title includes the word "penetration". What ISO 27001 requires is that you compare the controls you determined necessary against the Annex A reference set at clause 6.1.3 c), produce a Statement of Applicability at clause 6.1.3 d), and then decide at clause 9.1 what gets monitored and measured, by what method, and when (IAF MD 26:2023, section 2.3). A penetration test is the strongest evidence most organisations have that A.8.8, A.8.29, A.8.25, A.5.35 and A.5.36 are operating. It is evidence, not a mandate, and the cadence is yours to set and yours to be held to.

That is where most programmes go wrong: they write a testing policy more ambitious than the one they fund, and then collect a nonconformity against their own words. The failure mode scales with the organisation. A single-product startup has one application and one answer. A mid-market or enterprise ISMS spans business units, acquired entities, several products and a shared platform team, and the question stops being "do we test" and becomes "which entities, which products, in which certification year, with what evidence for each". This guide is written for that second case, with startups treated as one segment of it rather than the default reader.

For the test itself, Stingrai is a global CREST-accredited penetration testing services company founded in Toronto, Canada in 2021, trusted by companies from startups to enterprises to meet audit requirements for SOC 2, ISO 27001, CMMC, PCI DSS and HIPAA. OSCE³, OSWE, OSEP, CREST CRT certified pentesters, who are also world-class security researchers and bug bounty hunters. Choose from fully human-led or hybrid (AI agents plus human penetration testers) engagements across web, API, mobile, AI and LLM, cloud, network, Active Directory and social engineering penetration tests and red team engagements, delivered as one-time annual engagements or as continuous programmes through its PTaaS platform, with published pricing at US$3,000 per assessment for one web application and associated APIs (pricing) and every other scope quoted.

What ISO 27001 actually says, clause by clause

ISO/IEC 27001:2022 is the third edition, published in October 2022, and it runs to 19 pages of requirements plus the Annex A reference table. It sits under ISO/IEC JTC 1/SC 27 and carries one amendment, ISO/IEC 27001:2022/Amd 1:2024 on climate action changes (ISO catalogue page). Nineteen pages is not much room for prescription, and ISO spends none of it on test types. The scope clause is explicit that the requirements are generic and apply to all organizations "regardless of type, size or nature".

Four clauses do the work that buyers usually attribute to a testing mandate.

Clause 6.1.3 c) and d). The International Accreditation Forum states the relationship plainly in its mandatory transition document: "The requirements in ISO/IEC 27001 that use the reference control set in Annex A are the comparison process between the information security controls determined by the organization and those in Annex A (6.1.3 c)) and the production of a Statement of Applicability (6.1.3 d))." Annex A is a checklist against omission, not a menu you must implement in full. You determine controls from risk, then check them against the reference set so that nothing necessary was left out by accident.

Clause 9.1, Monitoring, measurement, analysis and evaluation. This is the clause that creates a cadence obligation, and it creates it from your own answers. You determine what is monitored, by what method, when, and by whom, and documented information must evidence the results. If your method list names penetration testing, your answer to "when" becomes an auditable commitment.

Clause 9.2, Internal audit, and clause 9.3, Management review. Where test results get consumed. A report that never reaches a management review is a report the ISMS did not use.

Clause 6.3, Planning for changes. New in the 2022 edition, and the clause that makes change-triggered testing an ISMS question rather than an engineering preference.

Why North American companies certify, and what changes at scale

ISO 27001 is not a domestic requirement in Canada or the United States. No federal or provincial regulator compels it, which is precisely why a North American certificate is almost always customer-driven rather than regulator-driven. Three demand patterns account for most of it.

Selling into Europe and the United Kingdom. European enterprise procurement and public-sector frameworks treat ISO 27001 as the default proof of an information security management system in a way that SOC 2 is not. A Toronto or New York vendor closing its first large EU account usually meets the certificate as a contract condition rather than as a strategy.

Enterprise procurement at home. North American enterprise buyers increasingly ask for ISO 27001 alongside SOC 2 in the same security questionnaire, because the two answer different questions. SOC 2 reports on whether controls operated over a period. ISO 27001 certifies that a management system exists, has a scope, and is audited on a cycle. Holding both shortens the security review, and most mid-market vendors end up holding both for that reason alone.

Multi-entity groups. Once a company has acquired, or operates in more than one country, ISO 27001 becomes the framework that can carry a group-level scope statement. That is a genuine advantage over a single-entity SOC 2 report, and it is the point at which the ISMS stops being a compliance project and starts being an operating structure.

What changes at mid-market and enterprise scale is not the standard. It is the arithmetic. Scope becomes a set rather than a system: several products, a shared platform, a corporate network, sometimes an acquired estate still being integrated, each needing a defensible answer to "what evidences A.8.8 here". Ownership is distributed, so remediation lands on product teams that do not report to the person holding the certificate, which is why the findings register and its owner column matter more than the report. Procurement becomes a gate that adds weeks between a scoping call and a test date. And the audit calendar is fixed, so testing has to be planned backwards from surveillance dates across every entity in scope.

The Annex A control to test type to evidence map

The left column uses the control numbers and exact titles ISO publishes in the reference set. The middle column is the test type that produces evidence for that control. The right column is the artifact a certification body will accept in the audit room.

Two rows are usually missed. A.5.35 is the independence row: if all testing is done by the team that builds the systems, you have evidence of testing but weak evidence of independence. A.8.34 is the row that protects you: a one-page rules-of-engagement document, signed before the test starts, shows that testing against operational systems was planned and authorised rather than improvised.

Scoping from the Statement of Applicability

The Statement of Applicability is where your test scope should come from, and almost nobody uses it that way. Most organisations scope from a system inventory or, worse, from last year's scope. The SoA is the better starting point because it is already the document the auditor reads, and it already records which controls you claimed and why.

Work the SoA in five passes.

Pass one: mark the controls a test can evidence. Flag every applicable control where the honest evidence is "a competent person tried to break it". In practice that is the eleven rows in the table above, plus whichever access control and cryptography controls your architecture makes testable.

Pass two: attach an asset to each flagged control. A control applies to the whole ISMS scope, but a test runs against a system. For A.8.29 the asset is the release pipeline and the applications passing through it. For A.8.8 it is the external estate and the internal estate as separate assets, because they need different test types.

Pass three: name the test type, not the vendor. Write "authenticated web application test" or "external network test" rather than "annual pentest". That specificity is what makes the SoA line auditable, and what stops a scope from silently shrinking to whatever was cheapest that year.

Pass four: record the trigger, not just the date. A date expires. A trigger does not.

Pass five, for a multi-entity ISMS: record the entity and the product against every applicable control. A group-level SoA that says "A.8.29 applicable" without naming which products the gate fires on is the single most common finding in a multi-business-unit certification. Two workable structures exist. Either run one SoA with an entity column, so that each applicable control lists the entities and products it covers and the testing evidence for each, or run a group SoA with per-entity annexes that inherit the group controls and add local ones. Either is defensible. What is not defensible is a group SoA with a single testing record from whichever business unit tested most recently. If an entity is inside the ISMS scope but outside the testing scope this year, write the reason and the compensating evidence into the risk treatment plan before the auditor asks.

The SoA penetration testing scoping worksheet

Copy this into your SoA as extra columns, or keep it as a companion register the SoA points at. An auditor who asks "how do you know A.8.29 is operating" then gets a one-row answer instead of a story.

The last two columns are the ones auditors chase. A report with open Highs and no retest record is weaker evidence than a report with fewer findings and a complete closure trail, because the control being evidenced is the management of vulnerabilities, not the discovery of them.

Frequency: where your cadence actually comes from

ISO sets no number, so the number comes from somewhere else. There are exactly four sources, and it is worth knowing which one you are standing on.

1. Your own documented policy. The strongest source, and the most self-inflicted. If your testing standard says "penetration testing is performed quarterly", A.5.36 makes quarterly testing auditable. Not because ISO asked for it, but because you did. Write the cadence you will fund.

2. Your clause 9.1 monitoring plan. If your plan names penetration testing as a monitoring method, the "when" is a commitment with documented information behind it.

3. Your risk assessment and risk treatment plan. A plan that reduces a high risk by "annual independent testing" has created an annual obligation for as long as that risk stays open at that treatment.

4. Contracts and other frameworks. Customer security schedules, insurance conditions, and any other framework you hold. This is the dominant driver at enterprise scale, where a single large customer contract can set a cadence the ISMS then has to meet across every entity. If you also take card payments, PCI DSS Requirement 11.4 imposes a real 12-month clock that ISO does not, and that clock ends up governing the whole programme. Our PCI DSS penetration testing guide works through the sub-requirements, and the cross-framework requirements matrix shows which of your frameworks is actually setting the pace.

Change triggers worth writing down

A calendar cadence alone leaves an eleven-month blind spot after a major change. These triggers are worth naming explicitly in the policy:

• A release that changes authentication, authorisation, session handling or tenancy isolation.

• A new externally reachable system, or an existing system newly exposed to the internet.

• A cloud account, region or platform migration, including a move between identity providers.

• A change to network segmentation or to the boundary between environments, which is the A.8.31 case.

• An acquisition, or the integration of an acquired estate into the ISMS scope.

• A significant security incident, where testing is part of demonstrating the corrective action under clause 10.2 worked.

• A new third-party integration that is granted trusted access to in-scope data.

Write the triggers as conditions, not as examples. "Any change that alters an authorisation decision" is auditable. "Major changes" is not. In a multi-entity ISMS, say which entities each trigger binds.

The certification cycle, and where testing lands in it

ISO 27001 certification runs on a three-year cycle operated by an accredited certification body under ISO/IEC 17021-1, with ISMS-specific rules in ISO/IEC 27006-1:2024. ANAB-accredited certification bodies had until 31 March 2026 to transition to it, so 2026 audits are run under the newer certification-body rules.

Stage 1 is a readiness audit. Per the published summary of ISO/IEC 17021-1 clause 9.3.1.2.2 by the International Accreditation Service, its objectives include reviewing your documented management system, evaluating "the client's preparedness for stage 2", reviewing scope, and evaluating whether internal audits and management reviews are planned and performed. Stage 1 is where a missing testing policy gets flagged, which is the cheapest point to fix it.

Stage 2 evaluates "the implementation, including effectiveness, of the client's management system". This is where the report gets read, along with the findings register and the closure trail.

Surveillance audits run in the years between. They are on-site but not full system audits, and each reviews internal audits and management review, actions on previous nonconformities, complaints, effectiveness, continual improvement, operational control and changes. European Accreditation's published answer on ISO/IEC 17021-1 clause 9.1.3 puts the calendar rule simply: "In each calendar year, at least ... there shall be an audit, whether surveillance or recertification."

Recertification happens in year three, planned "in due time to enable for timely renewal before the certificate expiry date". If the certificate lapses, a certification body can restore it within six months once the outstanding recertification activity is completed. After that, at least a Stage 2 has to be run again.

Practical timing

Three rules make the testing lane line up with the audit lane.

Test early enough to close findings. Across 55 penetration tests and 1,206 verified findings, the median Critical took 10.5 days to fix and the median High 38.0 days (State of Penetration Testing 2026). Six to eight weeks of clearance before the audit is the difference between showing a closed register and explaining an open one. In a multi-entity scope, sequence the entities so the slowest remediating team tests first.

Anchor the test to the certification year, not the calendar year. Certification years run from the certification decision date, so a December test and a March audit can look like a 15-month gap on a certificate issued in January.

Keep the retest in the same evidence bundle. The retest is the part that evidences A.8.8 rather than merely evidencing that you paid for a test.

What certification bodies accept as evidence, with wording

Certification bodies have no house style for penetration testing evidence, because the standard gives them nothing to standardise against. What they consistently look for is that the claim in your own documents is matched by a record. These are wordings that survive an audit.

Statement of Applicability justification for A.8.29. "Applicable. The organisation develops and operates customer-facing applications. Security testing is a defined gate in the release process, and an independent application penetration test is performed on the production release at least once per certification year and on any release that changes authentication, authorisation or tenancy isolation."

Testing policy clause that sets a defensible cadence. "Independent penetration testing of systems in the ISMS scope is performed at least annually, and additionally on the occurrence of any defined change trigger. Testing scope, method and provider independence are recorded before testing begins. Findings are risk-rated, tracked to closure in the vulnerability register, and reported to management review."

Rules of engagement statement for A.8.34. "Testing against operational systems was authorised in advance by the system owner and the ISMS manager, performed within the agreed window, excluded destructive techniques, and had a named escalation contact available throughout."

The evidence bundle to hand over

When the auditor asks about testing, hand over a bundle rather than a report:

1. The testing policy or standard that states the cadence and the triggers.

2. The scope statement and rules of engagement, signed and dated before the test.

3. The report itself, with methodology and dates visible.

4. The findings register entries, with severity, owner and dates.

5. The retest confirmation, or a documented risk acceptance for anything not fixed.

6. The management review minute where the results were discussed.

Item 6 is the one most organisations do not have, and the one that converts a technical document into ISMS evidence. In a multi-entity ISMS, produce the bundle per entity and a single index across them.

What a mid-market or enterprise ISO 27001 buyer needs from a penetration testing vendor

A startup buying its first test is buying a report. A mid-market or enterprise ISMS owner is buying a repeatable evidence supply for an audit cycle that will outlast the current security team. These are the nine criteria worth writing into your own vendor selection, in roughly the order they decide a shortlist.

1. Evidence written against A.8.8 and A.8.29, not against a generic template. Ask for a redacted sample report before you buy, and check that it states the tested scope, the dates, the method, the tester identity and the provider's independence on its own pages. A report that does those five things maps to A.8.29 and to the A.5.35 independence claim with no translation work by your compliance team. One that opens with a severity pie chart and nothing else costs you a week of writing cover notes for the auditor.

2. A findings register you can feed into the risk treatment plan. The audit artifact for A.8.8 is the register with severity, owner, discovery date, target date and closure date, plus the risk treatment plan entries that reference it. Ask whether findings arrive as a structured export, whether severity uses a published scale such as CVSS, and whether risk acceptance can be recorded against an individual finding rather than in an email thread.

3. Retest included, with its own dated artifact. The retest is what turns discovery into management of technical vulnerabilities. Confirm it is in the fee rather than an add-on, how long the retest window stays open, and that it produces its own dated document rather than a line edit inside the original report. Stingrai includes retests in its published packages (pricing).

4. Named penetration testers, with firm-level accreditation behind them. Certification bodies are increasingly explicit about tester competence when assessing A.5.35 and A.8.29, and enterprise procurement asks for it outright. Ask for names, certifications, and whether the people quoted are the people who will run the test. Ask for the firm's own accreditation too: firm-level accreditation speaks to methodology, quality assurance and complaints handling, individual certification speaks to the person, and an enterprise questionnaire usually wants both. Stingrai is a CREST-accredited penetration testing service provider at firm level and names the two penetration testers on each engagement, drawn from a team holding OSCE³, OSCP, OSWE, OSEP, CREST CRT and CISSP.

5. Multi-entity and multi-product scoping in one commercial relationship. If your ISMS covers four products and two acquired entities, four separate procurements means four vendor risk assessments and four report formats to reconcile. Ask whether the provider can run a programme across entities under one master agreement, with per-entity scopes and reports in a shared format, and a group-level summary for management review.

6. A portal, not an email thread. Findings that arrive as a PDF attachment on a Friday do not get triaged. A platform that shows findings as they are confirmed, lets product owners comment on the ones they own, tracks status to closure and exports the register for the auditor is the difference between an ISMS artifact and a document. It is also the surface your internal auditor will use under clause 9.2.

7. Procurement and questionnaire fit. Enterprise vendor onboarding will want the provider's certificates and insurance, a completed security questionnaire, a data processing agreement, confirmation of where testing data is stored and under which jurisdiction, and background check attestations for the testers. For a Canadian or US buyer carrying data residency commitments to its own customers, jurisdiction is the question that stalls deals. Raise it on the first call rather than in legal review.

8. Both annual and continuous cadence, from the same provider. Most certified organisations commit to one independent test per certification year plus change-triggered testing, which is defensible. The fast-moving customer-facing product is usually better served by continuous testing that fires on releases. A provider that sells only one model forces your policy to match its commercial shape. Stingrai delivers both one-time annual engagements and continuous programmes, so the cadence in the policy can be the cadence you actually buy.

9. Availability against your surveillance audit dates. Testing capacity is finite and certification calendars cluster. Give the provider your Stage 2, surveillance and recertification dates at scoping and book backwards from them, leaving clearance time for remediation. A provider that commits to a test window in writing is worth more in an audit year than one that is marginally cheaper.

Once the shortlist is down to two or three, ask how findings are quality-assured before they reach you, and ask what the provider expects from you. A vendor that sends a scoping questionnaire covering user roles, tenancy model, test environment, credentials and rate limits has run enterprise engagements before.

What it costs

ISO does not price your testing, and neither does your certification body, but published market data does. Stingrai's Penetration Testing Price Index 2026 reads 30 public-sector rate cards on the UK Government's G-Cloud framework and puts the median published day rate at £1,000, with a central band of £800 to £1,200. Published fixed-fee price lists put a single web application test between £3,750 and £18,000 depending on scope.

North American price bands

UK rate cards are the most transparent published data available, but a Canadian or US buyer needs numbers in their own currency. Published 2026 North American ranges by scope, as collected in Stingrai's penetration testing cost guide and the Canadian provider ranking, fall out like this.

The ranges are wide because scope, not geography, drives the number, and global consulting firms typically quote several times these figures for comparable scopes. A published figure beats a band: Stingrai publishes fixed prices of US$3,000 one-time or US$650 per month for one web application and associated APIs, and US$6,800 for its hybrid engagement, with every other scope quoted (pricing).

Translating that into an ISO 27001 programme:

• A single in-scope web application, tested once per certification year. Roughly 3 to 5 tester days, the most common shape for a SaaS company certifying one product.

• An external network plus one application. Two engagements, or one blended engagement, typically 6 to 10 tester days.

• A larger ISMS scope with internal estate. Internal network testing adds days rather than multiplying them, and it is usually where the highest-severity findings sit.

• A multi-entity group. Budget per entity rather than per certificate. The shared platform can often be tested once and referenced by each entity's evidence bundle, but anything with its own authentication boundary needs its own test.

• The retest. Budget it explicitly. It is the most common gap between a quoted number and an invoice, and the artifact that evidences A.8.8.

For a number against your own scope rather than a market band, the pentest cost calculator shows its assumptions alongside its output.

Combining ISO 27001 and SOC 2 evidence

Most North American companies that need ISO 27001 also need SOC 2, and testing twice is a self-inflicted cost. The combined pattern is now the default for mid-market vendors on both sides of the border: SOC 2 Type 2 answers the questionnaire from US enterprise buyers, ISO 27001 answers the one from European and UK buyers, and one well-scoped penetration test per certification year feeds both evidence files. The overlap is close to total, because neither framework mandates the test and both read it as evidence that a control you selected is operating.

Four things make one test serve both.

Scope the test to the intersection, then extend. Your ISO 27001 ISMS scope and your SOC 2 system description usually name the same production systems. Test that intersection with a single engagement, then add any ISO-scope-only estate as a separate work package rather than a separate engagement.

Write the report to name the controls. A report that also states tested scope, dates, tester independence and method maps to A.8.29 and to the SOC 2 control description without translation.

Mind the different clocks. ISO 27001 has no clock. SOC 2 Type 2 has an audit period rather than a date, and a single annual test gives a Type 2 auditor a population of one, so one late test is a 100 percent exception rate on that control. Our guides to SOC 2 penetration testing and to SOC 2 Type 2 testing timing work through how to place the test inside the observation window. If you process EU personal data as well, GDPR Article 32 adds a separate "regularly testing" obligation that the same evidence bundle can satisfy.

Run one procurement, not two. Selecting separate providers for the ISO test and the SOC 2 test doubles the vendor risk assessment, splits the report format, and makes the group-level summary for management review a manual merge. If you are shortlisting for both at once, our rankings of penetration testing companies for SOC 2 and, where the scope is an AWS estate rather than an application, cloud penetration testing companies for AWS and SOC 2 apply the same evidence criteria used above. For a provider shortlist by country, see the US and Canadian rankings.

Stingrai's penetration testing supports ISO 27001, SOC 2, PCI DSS and HIPAA programmes by producing exactly this bundle: scope, method, findings, retest.

What this means for defenders

Across 55 penetration tests and 1,206 verified findings, Stingrai's State of Penetration Testing 2026 recorded that 92.7% of tests surfaced a High or a Critical and that 67.2% of all findings were High or Critical. A test that comes back clean is therefore far more likely to be a scoping problem than a security result, which matters most in a multi-entity ISMS where one business unit quietly narrows its scope each year.

• Write the cadence you will fund, then fund it. A.5.36 makes your own policy auditable. Annual with named change triggers survives an audit. Quarterly with two tests a year does not.

• Scope from the Statement of Applicability, and name the entity. In a multi-business-unit ISMS, an applicable control without a per-entity testing record is a finding waiting to happen.

• Buy the retest with the test. Without a closure record you evidenced discovery only.

• Get independence and tester names on the record. A.5.35 is free points when the engagement letter carries both.

• Sign rules of engagement before testing production. A.8.34 exists for this, and the document doubles as incident insurance.

• Test six to eight weeks before the audit. At a 38-day median for Highs, anything closer means showing an open register.

• Start procurement before you start scoping. Vendor onboarding, questionnaires and data processing agreements routinely add weeks between a decision and a test date.

Frequently Asked Questions

Does ISO 27001 require penetration testing?

No. ISO/IEC 27001:2022 does not require a penetration test, does not name penetration testing in any clause, and sets no testing frequency. The ISO Online Browsing Platform shows the normative clauses are 4 to 10, none of which names the practice, and none of the 93 Annex A control titles in the ISO/IEC 27002:2022 reference set contains the word "penetration". A penetration test is accepted evidence that controls such as A.8.8 and A.8.29 are operating, and any frequency you are held to is one you wrote into your own policy, risk treatment plan or customer contracts.

How often does ISO 27001 require a penetration test?

ISO 27001 states no frequency, so there is no ISO answer. The cadence comes from four places: your documented testing policy, your clause 9.1 monitoring plan, your risk treatment plan, and contractual commitments. Most certified organisations settle on at least annually plus defined change triggers, which is defensible because it can be evidenced every certification year and covers the changes an annual calendar would miss. Auditors assess you against your commitment, not against a number in the standard.

Which ISO 27001 Annex A controls does a penetration test evidence?

The strongest mappings are A.8.8 Management of technical vulnerabilities, A.8.29 Security testing in development and acceptance, A.8.25 Secure development life cycle, A.5.35 Independent review of information security and A.5.36 Compliance with policies, rules and standards for information security. Secondary mappings include A.8.9, A.8.26, A.8.28, A.8.31, A.8.32 and A.8.34. All control titles are as published in the ISO/IEC 27002:2022 reference set.

Is a vulnerability scan enough for ISO 27001, or do I need a penetration test?

A scan can evidence part of A.8.8, because a scan does identify technical vulnerabilities. It cannot meaningfully evidence A.8.29, because security testing in development and acceptance is about whether the application behaves securely rather than whether its components are patched. Scanning gives coverage and frequency. Testing gives depth on authorisation, business logic and chained attack paths. Most certified organisations run both and say so in the Statement of Applicability.

What penetration testing evidence do ISO 27001 certification bodies accept?

A bundle rather than a document: the testing policy that states the cadence, the signed scope and rules of engagement, the dated report with its methodology, the findings register entries with severity and owner, the retest confirmation or documented risk acceptance, and the management review minute where the results were discussed. The last item is the one most organisations lack, and it is what turns a technical report into evidence that the ISMS consumed the result.

Does the penetration tester have to be a third party for ISO 27001?

No. ISO 27001 does not require third-party testing, and no Annex A control title imposes it. Independence becomes relevant through A.5.35 Independent review of information security, where the evidence is stronger when the reviewer is not the team that built the system. An internal team that is organisationally separate from engineering can satisfy that, and a third party makes it unambiguous in a single artifact.

What should a mid-market or enterprise company look for in an ISO 27001 penetration testing vendor?

Evidence that maps to the controls you claimed, and a commercial shape that fits an audit cycle. In practice that means a report stating scope, dates, method, named testers and provider independence, a structured findings register that feeds the risk treatment plan, a retest included in the fee with its own dated artifact, firm-level accreditation as well as individual certifications, the ability to run per-entity scopes across multiple business units under one agreement, a portal rather than an emailed PDF, fast turnaround on security questionnaires and data processing agreements, both annual and continuous cadence options, and a written commitment to test windows that clear your surveillance audit dates with remediation time to spare.

How much does an ISO 27001 penetration test cost in the US and Canada?

There is no ISO-specific price, only market rates against your scope. Published 2026 North American ranges run US$5,000 to US$30,000 for a web application, US$7,000 to US$35,000 for a mid-size SaaS or mobile application, US$5,000 to US$40,000 for network testing and US$10,000 to US$50,000 for a cloud estate. Canadian equivalents run C$5,000 to C$12,000 for a small application, C$12,000 to C$25,000 for a mid-size SaaS application, C$15,000 to C$35,000 for a network test and C$40,000 to C$120,000 for a continuous annual programme with retests. Stingrai publishes fixed prices of US$3,000 one-time or US$650 per month for one web application and associated APIs, and US$6,800 for its hybrid engagement, with other scopes quoted.

Can one penetration test cover ISO 27001 and SOC 2?

Yes, and it usually should. Neither framework mandates the test, both accept it as evidence, and the systems in your ISMS scope and your SOC 2 system description are usually the same. Scope the engagement to the intersection, make sure the report states scope, dates, method and tester independence so it maps cleanly to both, and place the test inside the SOC 2 observation window rather than beside it. See SOC 2 Type 2 penetration testing timing for the placement question.

Related reading

• Penetration testing requirements by framework, the 2026 matrix, which framework mandates testing and which merely accepts it.

• Pentest evidence auditors accept: SOC 2, ISO 27001, PCI DSS and CMMC, the clause-level evidence guide.

• SOC 2 penetration testing and SOC 2 Type 2 testing timing.

• PCI DSS penetration testing: Requirement 11.4 explained, the framework that does impose a clock.

• GDPR Article 32 and penetration testing, the EU "regular testing" obligation.

• Penetration Testing Price Index 2026, published day rates and fixed fees.

• The State of Penetration Testing 2026, 1,206 verified findings across 55 engagements.

• Best penetration testing companies for SOC 2, provider criteria for the framework most often held alongside ISO 27001.

• Best cloud penetration testing companies for AWS and SOC 2, when the in-scope estate is a cloud account rather than an application.

• Top penetration testing companies in the USA and in Canada, country shortlists for North American buyers.

• Best Penetration Testing Companies for ISO 27001 (2026)

• Does ISO 42001 Require Penetration Testing? (2026)

References

1. ISO. ISO/IEC 27001:2022. Edition 3, October 2022, 19 pages, ISO/IEC JTC 1/SC 27. https://www.iso.org/standard/27001

2. ISO. ISO/IEC 27001:2022(en) on the ISO Online Browsing Platform. https://www.iso.org/obp/ui/en/#iso:std:iso-iec:27001:ed-3:v1:en

3. ISO. ISO/IEC 27002:2022(en) on the ISO Online Browsing Platform. https://www.iso.org/obp/ui/en/#iso:std:iso-iec:27002:ed-3:v2:en. All 93 control numbers and titles.

4. International Accreditation Forum. IAF MD 26:2023, Issue 2. Issued 15 February 2023. https://iaf.nu/iaf_system/uploads/documents/IAF_MD26_Issue_2_15012023.pdf. Source of the 93 versus 114 control change and the clause 6.1.3 c) and d) relationship.

5. International Accreditation Service. ISO/IEC 17021-1:2015 Section 9: Process Requirements. https://www.iasonline.org/wp-content/uploads/2021/02/17021-1-2015-Section-9.pdf. Stage 1 objectives, Stage 2 purpose, surveillance content, recertification timing.

6. European Accreditation. FAQ 37.12, ISO 17021-1:2015 clause 9.1.3. March 2019. https://european-accreditation.org/sp_accordion_faqs/question-37-12-iso-17021-12015-clause-9-1-3/. The one-audit-per-calendar-year rule.

7. ANAB. ISO/IEC 27006-1:2024 Transition. https://blog.ansi.org/anab/iso-iec-27006-1-2024-transition/. The 31 March 2026 ANAB transition deadline.

8. Stingrai. Penetration Testing Price Index 2026. https://www.stingrai.io/blog/penetration-testing-price-index-2026. Median published day rate and fixed-fee ranges.

9. Stingrai. The State of Penetration Testing 2026. https://www.stingrai.io/blog/state-of-penetration-testing-2026. 1,206 verified findings across 55 penetration tests.

10. Stingrai. Pentest Evidence Auditors Accept (2026). https://www.stingrai.io/blog/pentest-evidence-auditors-accept-soc2-iso27001-pci-cmmc. Clause-level comparison across frameworks.

11. Stingrai. Penetration Testing Cost Guide 2026. https://www.stingrai.io/blog/penetration-testing-cost-2026. 2026 North American ranges by scope in US dollars.

12. Stingrai. Top Penetration Testing Companies in Canada (2026). https://www.stingrai.io/blog/top-penetration-testing-companies-in-canada-2026-ranked. 2026 Canadian dollar ranges by scope.

13. Stingrai. Pricing. https://www.stingrai.io/pricing. Published package prices.

Get your ISO 27001 testing evidence in order

If your Statement of Applicability claims A.8.8, A.8.29 or A.5.35 across several products or entities and your evidence folder holds one scan export, the gap is worth closing before the next surveillance audit rather than during it. Stingrai's penetration testing supports ISO 27001 programmes with the artifacts certification bodies actually read: a signed scope and rules of engagement, a dated report naming method and independence, a findings register tracking severity and owner, and a retest that closes the loop. We work with organisations across Canada and the United States, deliver both one-time annual engagements and continuous testing programmes, and can run per-entity scopes for a multi-business-unit ISMS under one agreement. Senior penetration testers work the target throughout the engagement, alongside Snipe, our autonomous web application agent, on web application scopes.

Book a free scoping call to map your SoA to a test scope, request a quote for a defined ISMS scope, or see published package prices on the pricing page.