AI in Pentest Report Writing: A Policy Clients Will Accept

Use AI to draft prose from evidence your testers captured, never to decide whether something is a finding, how severe it is or what was in scope, and let nothing it writes reach a client until a named person has signed it off. The question clients actually ask is where their data goes: a local model keeps it on your hardware, your own API key keeps it under your firm's agreement with the provider, and a consumer chat tool puts it under terms written for individuals. Write that down as a one-page policy before the first client asks.

What AI should write and what it should not

The line is judgement. A model is good at turning evidence into readable prose and poor at knowing what it does not know. It will put forward a vector with confidence, so treat it as a suggestion. It will cite an advisory that does not exist or a version that was never released, so check every reference against its source. And it knows nothing about the client beyond what you give it, which means any sentence about business impact you did not supply is invention.

What counts as client data

More than the findings. Treat everything that came out of the engagement as client data:

• the client's name, and the fact that you tested them at all
• hostnames, IP addresses, URLs, internal domain names and network ranges
• usernames, email addresses and staff names, which are personal data as well
• screenshots, which carry all of the above and usually more than you noticed
• tool output, configuration extracts, code, and request and response pairs
• credentials, session tokens and keys, which go to no model on any route

Redaction helps less than people expect. A finding with the hostnames removed still describes a specific weakness at a specific organisation, and a screenshot redacted by hand misses the browser tab, the clock or the email address in the corner. Decide the route for the whole engagement, not for the sentence you are about to paste. Handling evidence and client credentials safely covers the rest of the evidence trail.

Local model, your own key or a consumer chat tool

The local route, for example a model served through Ollama on a machine you run, settles the question by architecture: nothing leaves, so there is nothing to disclose. The cost is hardware and an afternoon of setup, covered in running a local model for report writing.

The difference between the other two routes is the one that matters. As of October 2026, OpenAI says it does not train on business or API data by default and may keep API inputs and outputs for up to 30 days to provide the service and identify abuse, with zero data retention available for eligible uses. For its services for individuals, it says it may use content to train its models unless the user opts out. Anthropic says it does not use inputs or outputs from its commercial products for training by default, while users of its consumer plans choose whether their chats are used, with retention extended to five years if they agree. Terms change, so keep a dated copy of your provider's current business terms on file.

The real risk is rarely the provider's policy. It is a tester pasting a finding into a personal account late at night because the firm offered nothing better. The NCSC has advised since March 2023 against including sensitive information in queries to public LLMs. A sanctioned route that is easier than the unsanctioned one is the control that actually works.

The clauses clients are adding

AI wording now turns up in master services agreements, data processing agreements and supplier questionnaires. These are the clauses we see most, and what satisfies each:

• No third-party AI processing without consent. Satisfied by a local model, or by written consent that names the provider route.
• No use of our data to train models. Satisfied by a local model or by business terms that exclude training. Never by a consumer account.
• Disclose AI use in deliverables. A sentence in your methodology section and a straight answer when asked.
• Data stays in the UK or the EU. This covers AI processing too, so check where your provider processes requests, or keep it local.
• Tell us about new sub-processors. An AI provider handling personal data for you is likely to be one. Under UK GDPR Article 28(2), a processor needs the controller's prior written authorisation, specific or general, to engage another processor, and under a general authorisation must tell the controller about intended changes. A new provider is not something to add quietly.
• Human review of all deliverables. Your sign-off record answers this.

This is not legal advice, and a solicitor should review your own terms and how you respond to these clauses. Commercially, the firms that negotiate least are the ones whose tooling can run on a local model or with AI switched off, because they can say yes to the strictest version of each clause.

Review and sign-off

Every sentence in a report has an owner, and AI does not change who. The tester owns the finding, the reviewer owns the check, and the person who approves the report owns what the client reads. Reviewers should read AI-drafted text harder in five places:

• references and version numbers, checked against the source
• remediation that fits the technology in the evidence, not a generic fix
• severity that matches the vector and the evidence rather than the confidence of the prose
• details that belong to this client, since a draft built on library text can carry another client's names
• claims about exploitability or impact that nobody tested

Record who approved each report and when. Whether you label AI-drafted passages is a choice. What matters is that a client who asks can be told how the report was produced and who checked it, and a QA process that survives a busy month is where that record comes from.

Answering the AI question in a security questionnaire

Expect some version of five questions, and answer each with a mechanism rather than an adjective.

1. Do you use AI to process our data? Name the route: "report drafting uses a model on our own hardware", or "uses [provider] under our firm's API agreement". Add that you can deliver their engagement without AI if they require it.
2. Is our data used to train models? "No", with the reason: the model runs locally, or the provider's business terms exclude training by default. Attach the dated terms.
3. Where is it processed, and for how long is it kept? The region and retention period for the route you use.
4. Who reviews AI output? "Every finding is checked by a second tester, and a named person approves the report before release."
5. What stops staff using other AI tools? "Our AI usage policy prohibits client data in personal or consumer tools. Staff read it at induction and it is reviewed every six months."

Keep these with the rest of your answers to security questionnaires about your platform, dated, and update them whenever a route changes.

A one-page AI usage policy

Adapt this to your firm and keep it to one page, so people read it.

1. Purpose. AI may draft and edit report text from evidence our testers captured. It is not used to test, to decide whether something is a finding, or to set severity.
2. Approved routes. [Local model on firm hardware] and [named provider] through the firm's own account and key. No other AI service may receive client data.
3. Prohibited. Client data in personal accounts, consumer chat tools, browser extensions or any tool not named in point 2.
4. Never sent to any model. Credentials, session tokens, keys, or personal data beyond what the finding needs.
5. Client terms come first. Before testing starts, the engagement lead checks the contract for AI clauses and records which route, if any, the engagement may use.
6. Human review. The tester owns every AI-drafted sentence, a reviewer checks it, and a named person approves the report before release.
7. Verification. References, versions and identifiers are checked against their source before release.
8. Disclosure. Our methodology states that AI-assisted drafting may be used and how it is reviewed, and we answer client questions about it in full.
9. Keys. Provider keys belong to the firm, are stored encrypted, and are rotated when someone with access leaves.
10. Records. We keep a dated copy of each approved provider's terms and review the route when they change.
11. Incidents. Client data sent to an unapproved service is reported to [role] the same day and handled as a data incident.
12. Ownership. [Role] owns this policy and reviews it every [six] months.