What is a pentest scope document and how to write one

If you have ever commissioned a penetration test, you have probably been handed a blank page and asked to define the scope before anyone will give you a quote. It is one of those steps that sounds simple and turns out to be the thing that most determines whether the test is actually useful. A poorly scoped pentest either misses the parts of your product that matter most, or balloons in cost because nobody drew a boundary. This article explains what a scope document actually is, what belongs in it, and how to write one, with particular attention to what changes when the product being tested is built on AI.

What a pentest scope document actually is

A scope document is the agreement between you and the testers that defines exactly what will be tested, how, when, and what is off limits. It exists because a penetration test without a defined boundary is dangerous in both directions. Too broad, and testers could disrupt production systems, rack up unnecessary hours, or wander into territory you never intended, such as a third party service you do not control. Too narrow, and you pay for a test that never touches the parts of your product an attacker would actually target.

Think of it as the specification for the test itself. Everyone, you, the testers, and anyone else with a stake in the outcome, should be able to read it and understand precisely what will happen, without ambiguity.

What belongs in the document

A good scope document is not long, but it needs to be precise. Here are the sections that matter.

• Objectives. Why you are running the test. This might be to satisfy a specific enterprise buyer's requirement, to prepare for a compliance certification, or simply to find out where you are exposed before a bigger customer asks. The objective shapes everything else, because a test aimed at satisfying a buyer's questionnaire looks different from one aimed at genuinely stress testing a new feature.
• In scope assets. The specific systems, applications, APIs, and environments to be tested, named precisely. Vague descriptions like the platform lead to disputes later about what was and was not covered. List actual domains, IP ranges, application names, and API endpoints.
• Out of scope assets. Just as important as what is in scope. Explicitly exclude anything testers should not touch, such as production databases holding live customer data, third party infrastructure you do not own, or systems under a separate agreement.
• Testing type. Whether this is black box, where testers start with no internal knowledge, grey box, where they are given some access or documentation, or white box, where they have full access to code and architecture. This materially changes both cost and depth, and it should be a deliberate choice, not a default.
• Timing and environment. When the test will run, and critically, whether it runs against production or a staging environment. Testing production carries real risk of disruption. Testing staging only is safer but only useful if staging genuinely mirrors production.
• Rules of engagement. The specific constraints on how testers may operate, including permitted testing hours, prohibited techniques such as denial of service attacks that could take systems offline, and the process for handling anything found that constitutes an active, ongoing compromise rather than a theoretical vulnerability.
• Data handling. What testers are permitted to access, copy, or extract during the test, and how any sensitive data they encounter must be handled and eventually destroyed.
• Points of contact and escalation. Named people on both sides, and a clear process for what happens if testers find something severe enough that it needs immediate attention rather than waiting for the final report.
• Deliverables and timeline. What you will receive at the end, typically a report with findings ranked by severity and remediation guidance, and by when.

What changes when the product is built on AI

This is where a generic scope template falls short, because the standard sections above were written for traditional web applications and infrastructure, and an AI product has an attack surface those categories do not fully capture. If you are scoping a test for an AI product, a few additions are worth including explicitly.

• The AI and agent layer as its own in scope asset. Do not assume that scoping your application automatically covers your AI components. Explicitly list your model integration, any agents with tool access, and your prompt handling as assets to be tested, or they may be treated as out of scope by default.
• Prompt injection testing, stated explicitly. A traditional pentest scope will not naturally include testing whether crafted inputs can manipulate your AI into ignoring its instructions. If this matters to you, and for most AI products it should, say so directly in the objectives and in scope sections, because not every testing firm tests for this by default.
• Data flow to third party model providers. If your product sends data to an external model provider, decide and state whether that flow is part of the test, since testers cannot attack infrastructure they do not own, but they can and should assess how your application handles that data on its way out.
• Tenant isolation in the AI and data layer. If you are multi tenant, explicitly scope testing for whether one customer's data can surface in another's results through the model or vector database layer, not just through the traditional application layer.
• Rate and cost abuse. AI API calls cost money per use in a way traditional infrastructure often does not. Consider whether you want testers to probe whether your product can be abused to run up provider costs, and set clear limits if so, since this is a real and AI specific business risk.

Without these additions, a pentest can complete successfully, produce a clean report, and still have never touched the parts of your AI product that an enterprise buyer's security team will ask about directly. A clean report on the wrong scope gives you false confidence, which is arguably worse than no report at all.

What certifications actually mean, and why they belong in your scope conversation

Before you write the scope document, it is worth understanding the accreditations you will see mentioned by testing providers, because they affect who you should trust with the work.

CREST is the most recognised accreditation for penetration testing providers in the UK. A CREST accredited company has been independently assessed on its methodology, and its individual testers typically hold CREST examinations of their own. Many enterprise buyers, particularly in finance and regulated sectors, specifically ask whether your test was carried out by a CREST accredited provider, so if you know your buyer will ask, build that requirement into your scope document from the outset rather than discovering it after the test is done.

CHECK is a related UK accreditation, run by the National Cyber Security Centre, relevant mainly if you are testing systems connected to government or public sector networks. Most startups will not need it, but it is worth knowing the name if you ever sell into the public sector.

Individual testers also hold their own qualifications, such as OSCP, which is a widely respected hands on certification for the tester personally, separate from whether the company itself holds CREST. A strong test can come from an individually well qualified tester at a company that is not itself CREST accredited, so do not treat the absence of a company level accreditation as an automatic disqualifier, particularly for an early stage company where a specialist AI security firm may bring expertise a generalist accredited firm does not have.

How to find a provider in London

If you specifically want a CREST accredited provider, CREST publishes a public directory of accredited member companies on its own website, searchable by service and location, which is the most reliable way to confirm a firm's status directly rather than taking a claim on trust. It is worth checking this directly, since accreditation status can change and a provider's marketing is not always the most current source.

Beyond the CREST directory, London has a substantial cluster of specialist pentest and AI security firms, and a sensible approach is to shortlist a small number, ask each for a sample report and their specific experience testing AI products, and compare not just their accreditation but whether they have genuinely tested the kind of product you have. An accredited firm with no real AI testing experience may still miss the prompt injection and model layer risks described above, so accreditation and AI specific expertise are two different things worth checking separately.

Common mistakes to avoid

A few mistakes show up repeatedly and are worth naming plainly. Scoping too broadly to seem thorough, which inflates cost without necessarily improving the result. Leaving the AI and agent layer out entirely because the scope template was written for traditional applications. Failing to specify whether the test covers production or staging, which causes confusion later about how representative the findings actually are. And treating the scope document as a formality to get through quickly, when it is actually the single document that determines whether the money you spend on the test produces something useful.

How to actually write one

Start with your objective, because everything else follows from it. If the goal is answering a specific enterprise buyer's requirement, read exactly what they asked for and scope to satisfy it precisely. If the goal is finding your own real exposure before anyone asks, scope more broadly around your actual architecture, including the AI specific items above.

From there, list your assets concretely, decide on testing type and timing with input from whoever is running the test, and write the rules of engagement plainly enough that there is no room for a dispute later about what was permitted. A good testing partner will help you refine the document rather than simply accepting whatever you draft, and that collaborative back and forth is often where the real value of an experienced provider shows up before the testing has even started.

The honest takeaway

A pentest is only as good as its scope. The document is not paperwork to get out of the way before the real work starts, it is the decision that determines what the real work actually covers. For an AI product specifically, the risk is that a scope written from a generic template quietly excludes exactly the things, prompt injection, model data flows, tenant isolation in the AI layer, that a sophisticated buyer or attacker will focus on. Write the scope deliberately, name the AI specific items explicitly, and the test you pay for will actually tell you what you need to know.