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 last sentence is the whole post in miniature, and it is where most ISO 27001 programmes go wrong: they write a testing policy more ambitious than the one they fund, and then get a nonconformity against their own words.

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. Its full title is Information security, cybersecurity and privacy protection. Information security management systems. Requirements, it sits under ISO/IEC JTC 1/SC 27, and it carries one amendment, ISO/IEC 27001:2022/Amd 1:2024 on climate action changes, published at no cost. All of that is on the ISO catalogue page.

Nineteen pages is not much room for prescription, and ISO does not spend any of it on test types. The scope clause is explicit that the requirements are generic: "The requirements set out in this document are generic and are intended to be applicable to all organizations, regardless of type, size or nature. Excluding any of the requirements specified in Clauses 4 to 10 is not acceptable when an organization claims conformity to this document."

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 needs monitoring and measuring, the methods that produce valid results, when the monitoring is performed, who performs it, when the results are analysed, and who analyses them. Documented information must be available as evidence of the results. If your answer to "what do we monitor" includes the effectiveness of technical controls, and your answer to "by what method" includes penetration testing, then your answer to "when" becomes an auditable commitment.

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

Clause 8.1, Operational planning and control, and clause 6.3, Planning for changes. Clause 6.3 is new in the 2022 edition, and it is the clause that makes change-triggered testing an ISMS question rather than an engineering preference.

The Annex A control to test type to evidence map

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

Two of those rows are usually missed, and both are cheap points.

A.5.35 is the independence row. If your only testing is done by the same team that builds the systems, you have evidence of testing but weak evidence of independence. A third-party engagement closes that gap in one artifact.

A.8.34 is the row that protects you. Auditors like seeing that testing against operational systems was planned and authorised rather than improvised. A one-page rules-of-engagement document, signed before the test starts, is the artifact. It is also the document that keeps a production test from becoming an incident.

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 a test from a system inventory or, worse, from last year's scope. The SoA is a 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 four passes.

Pass one: mark the controls a test can evidence. Walk the applicable controls and flag every one 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 is applicable 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 that pass 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". The specificity is what makes the SoA line auditable, and it is 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.

The SoA penetration testing scoping worksheet

Copy this into your SoA as extra columns, or keep it as a companion register that the SoA points at. Either way, an auditor who asks "how do you know A.8.29 is operating" 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. This is the strongest and the most self-inflicted. If your information security policy or your testing standard says "penetration testing is performed quarterly", then A.5.36 Compliance with policies, rules and standards for information security 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. Clause 9.1 requires you to determine when monitoring and measurement is performed. If your plan names penetration testing as a method, the "when" is a commitment with documented information behind it.

3. Your risk assessment and risk treatment plan. A risk treatment 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. If you also take card payments, PCI DSS Requirement 11.4 imposes a real 12-month clock that ISO does not, and that clock will end up governing your 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 are the triggers worth naming explicitly in the policy, because each one changes the attack surface in a way an annual test would miss:

• 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.

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. That 2024 edition matters in 2026: ANAB-accredited certification bodies had until 31 March 2026 to transition to it, so audits from this year are being 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 being planned and performed. Stage 1 is where a missing testing policy gets flagged as an area of concern, which is exactly the point at which fixing it is cheap.

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

Surveillance audits run in the years between. They are on-site audits but not full system audits, and each one reviews internal audits and management review, actions taken 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 certification within six months provided the outstanding recertification activity is completed, and 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. A report dated the week before a surveillance audit is a report with open findings. Our own engagement data says the closure work is not instant: across 55 penetration tests and 1,206 verified findings, the median Critical took 10.5 days to fix and the median High took 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.

Anchor the test to the certification year, not the calendar year. Certification years run from the certification decision date. A December test and a March audit can look like a 15-month gap on a certificate that was 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 do not have a house style for penetration testing evidence, because the standard gives them nothing to standardise against. What they consistently look for is that the claim you made in your own documents is matched by a record. These are wordings that survive an audit, drawn from how the underlying clauses are written.

Statement of Applicability justification for A.8.29. "Applicable. The organisation develops and operates customer-facing applications. Security testing is performed as 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."

Statement of Applicability justification for A.8.8. "Applicable. Technical vulnerabilities are identified through continuous scanning of the internal and external estate and through independent penetration testing. Findings are recorded in the vulnerability register with severity, owner and target remediation date, and are retested to confirm closure."

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."

Clause 9.1 monitoring entry. "Measure: proportion of High and Critical penetration test findings closed within the target remediation window. Method: extract from the vulnerability register. Frequency: reported quarterly, analysed at management review. Owner: Head of Security."

Rules of engagement statement for A.8.34. "Testing against operational systems was authorised in advance by the system owner and the ISMS manager, was 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 one bundle rather than one 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 it is the one that converts a technical document into ISMS evidence.

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 and a full published spread of £480 to £1,600. On the fixed-fee side, published price lists put a single web application penetration test between £3,750 and £18,000 depending on scope.

Translating that into an ISO 27001 programme:

• A single in-scope web application, tested once per certification year. One engagement of roughly 3 to 5 tester days at the index rates, which is 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.

• The retest. Budget it explicitly. It is the most common gap between a quoted number and an invoice, and it is 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, and pricing publishes fixed package prices for one web application and its APIs.

Combining ISO 27001 and SOC 2 evidence

Most companies that need ISO 27001 also need SOC 2, and testing twice for the two of them is a self-inflicted cost. The overlap is close to total, because both frameworks accept the same artifact for the same reason: neither one mandates the test, and both read it as evidence that a control you selected is operating.

Three 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 lists findings is a technical document. A report that also states the tested scope, the dates, the tester independence and the method is evidence that maps to A.8.29 and to the SOC 2 control description without translation.

Mind the different clocks. ISO 27001 has no clock at all, and SOC 2 Type 2 has an audit period rather than a date. A single annual test gives a Type 2 auditor a population of one, so one missed or 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.

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

What the engagement data says about scoping

The point of a penetration test inside an ISMS is not to produce a certificate-shaped document. It is to find the things your controls did not stop. 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, that 67.2% of all findings were High or Critical, and that the false-positive rate across the set was 0.74%. Remediation is where the ISMS earns the audit: the median Critical closed in 10.5 days and the median High in 38.0 days, which is the real reason to book testing well ahead of an audit rather than against it.

Two implications for ISO 27001 scoping. First, a test that comes back clean is much more likely to be a scoping problem than a security result, given how rarely a test surfaces nothing. Second, if two thirds of what a test produces is High or Critical, then the vulnerability register, not the report, is the ISMS artifact that matters, because it is the thing that shows A.8.8 operating over time.

What this means for defenders

• 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, not from last year's scope. The SoA already lists the controls you claimed. The test should evidence the ones a test can evidence.

• Buy the retest with the test. The control being evidenced is the management of vulnerabilities. Without a closure record you evidenced discovery only.

• Get independence on the record. A.5.35 is free points if the engagement letter names an independent party, and it is a gap if all testing is done in-house by the build team.

• Sign rules of engagement before testing production. A.8.34 exists for exactly 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.

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. In practice, 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 a defensible position because it can be evidenced every certification year and it covers the changes that an annual calendar would otherwise 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 Configuration management, A.8.26 Application security requirements, A.8.28 Secure coding, A.8.31 Separation of development, test and production environments, A.8.32 Change management, and A.8.34 Protection of information systems during audit testing. 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.8.8 is about identifying and acting on technical vulnerabilities and a scan identifies some of them. A scan cannot evidence A.8.29 in any meaningful way, because security testing in development and acceptance is about whether the application behaves securely rather than whether its components are patched. The practical split is that scanning gives you coverage and frequency, and testing gives you 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.

Do I need a penetration test before my Stage 2 audit?

Not as a requirement, but it is the practical answer if your Statement of Applicability claims A.8.29 or A.5.35. Stage 1 evaluates your preparedness for Stage 2 and reviews whether internal audits and management reviews are being planned and performed, per the published summary of ISO/IEC 17021-1 clause 9.3.1.2.2. Stage 2 evaluates implementation and effectiveness. If your own documents commit you to testing, Stage 2 is where the absence of a report becomes a nonconformity against clause 9.1 or A.5.36.

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.

Does the ISO 27001 penetration test scope have to match the ISMS scope?

It has to be defensible against the Statement of Applicability, which is not the same thing. The ISMS scope defines the boundary of the management system. The test scope should cover the in-scope assets where a test is the honest evidence for an applicable control. Where an in-scope asset is excluded from testing, record why in the SoA justification or the risk treatment plan rather than leaving the gap unexplained.

What changed for penetration testing between ISO 27001:2013 and ISO 27001:2022?

Structurally quite a lot, substantively nothing about testing. Per IAF MD 26:2023, the number of controls fell from 114 in 14 clauses to 93 in 4 clauses, with 11 new controls, 24 merged and 58 updated. Testing-relevant controls were renumbered, so 12.6.1 became A.8.8 and 14.2.8 and 14.2.9 folded into A.8.29. Neither edition mandated testing or set a frequency. The transition deadline for certified organisations was 31 October 2025, so any current certificate is against the 2022 edition.

How much does an ISO 27001 penetration test cost?

There is no ISO-specific price, only market rates against your scope. Published UK rate cards put the median penetration testing day at £1,000 with a central band of £800 to £1,200, and published fixed-fee price lists put a single web application test between £3,750 and £18,000, per Stingrai's Penetration Testing Price Index 2026. A common first-certification shape is one application engagement of 3 to 5 tester days plus a retest. Stingrai publishes fixed package prices for one web application and its APIs on its pricing page.

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.

References

1. ISO. ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection. Information security management systems. Requirements. Edition 3, published October 2022, 19 pages, ISO/IEC JTC 1/SC 27. https://www.iso.org/standard/27001. Publisher's catalogue entry, source of edition, publication date, page count and amendment status.

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. Publisher-hosted table of contents and publicly readable scope clause, source of the clause structure and of clause 9.1's title.

3. ISO. ISO/IEC 27002:2022(en), Information security, cybersecurity and privacy protection. Information security controls, on the ISO Online Browsing Platform. https://www.iso.org/obp/ui/en/#iso:std:iso-iec:27002:ed-3:v2:en. Publisher-hosted list of all 93 control numbers and titles, which are the Annex A reference set used in ISO/IEC 27001:2022.

4. International Accreditation Forum. IAF MD 26:2023, Transition Requirements for ISO/IEC 27001:2022, Issue 2. Issued 15 February 2023. https://iaf.nu/iaf_system/uploads/documents/IAF_MD26_Issue_2_15012023.pdf. Mandatory document for accreditation bodies and certification bodies. Source of the publication date, the 93 versus 114 control change, the clause 6.1.3 c) and d) relationship, and the 31 October 2025 transition deadline.

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. An accreditation body's published summary of the certification process clauses, source of the Stage 1 objectives, the Stage 2 purpose, the surveillance audit content and the recertification timing rules.

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/. Source of the rule that an audit, whether surveillance or recertification, falls in each calendar year.

7. ANAB. ISO/IEC 27006-1:2024 Transition. https://blog.ansi.org/anab/iso-iec-27006-1-2024-transition/. Publication of the 2024 ISMS certification-body standard and the 31 March 2026 transition deadline for ANAB-accredited certification bodies.

8. Stingrai. Penetration Testing Price Index 2026. https://www.stingrai.io/blog/penetration-testing-price-index-2026. Median published day rate, central band and published fixed-fee ranges, each linked to the page it was read from.

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, severity mix, false-positive rate and remediation timing by severity.

10. Stingrai. Pentest Evidence Auditors Accept: SOC 2, ISO 27001, PCI DSS and CMMC (2026). https://www.stingrai.io/blog/pentest-evidence-auditors-accept-soc2-iso27001-pci-cmmc. Clause-level comparison of which frameworks mandate testing and which accept it as evidence.

11. Stingrai. Pricing. https://www.stingrai.io/pricing. Published package prices for one web application and its APIs.

Get your ISO 27001 testing evidence in order

If your Statement of Applicability claims A.8.8, A.8.29 or A.5.35 and your evidence folder holds a 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 that names method and independence, a findings register that tracks severity and owner, and a retest that closes the loop. We deliver both one-time annual engagements and continuous testing programmes, and senior penetration testers work the target alongside Snipe, our autonomous web application agent, throughout the engagement.

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.