What buyers actually ask about your reporting platform

Five years ago almost nobody asked a penetration testing firm where its working papers lived. Now a mid-size client will send a supplier assessment before it will let you scan a single host, and a meaningful share of those forms are written by someone who has read a breach report about a vendor.

The forms are long. The part that decides the outcome is short.

1. Who at your firm can read our report

This is the question, and most answers to it are a phrase rather than a mechanism. “Role-based access control” says nothing: every system has roles, and in a small consultancy everybody is frequently an administrator of all of them.

What lands is specificity. Say whether access is limited to the people assigned to the engagement. Say where that limit is enforced: in the interface, in the application, or in the database. A reviewer who has seen a hundred of these can tell the difference immediately, and the difference is the whole risk.

If the honest answer is that everyone at your firm can read everything because there are six of you, say that, and say what compensates for it. Reviewers are used to being told what they want to hear. Being told something true is unusual enough to be worth credibility elsewhere on the form.

2. Could your vendor read it

Every consultancy now has a platform between the tester and the client, and that platform is a party to the engagement whether or not anyone has said so. The question behind the question is what would have to go wrong for a third party to read a finding.

There are broadly two architectures. In the first, the vendor holds your data in a database they administer, alongside every other customer’s, and the separation between you and the firm down the road is a column in a table plus every query forever remembering to filter on it. In the second, the database is in your own account and the vendor has no standing route into it.

Both can be in London. Only one of them lets you answer this question without describing somebody else’s access reviews.

3. Who else sees this

Sub-processor lists used to be a formality. AI changed that, and a lot of firms have not noticed yet.

If your platform drafts finding text through the vendor’s own model account, you have added a sub-processor to every engagement you have run since the feature shipped. Your client’s data protection officer is entitled to know that, your transfer assessment probably needs updating, and you may not be able to say what the retention terms are because the contract is between the vendor and the model provider, not you.

A firm that can say the model runs on its own key, under its own agreement, or locally on its own hardware, deletes an entire section of the review. That is worth more in a procurement cycle than most feature comparisons.

4. What happens when it goes wrong

Give a number and a named person, not a paragraph about your commitment to security. When would you tell them, who would make the call, and what would they get. If you have never had an incident, say that too, and describe the process you would follow rather than implying experience you do not have.

The pattern across all four: a mechanism the reviewer could go and verify, followed by a limit you volunteered before they found it. Nobody expects a ten-person consultancy to have the controls of a bank. They expect you to know precisely which ones you have.

What to do about it this quarter

• Write your four answers down once, properly, with a date on them.
• Check that two different people at your firm would give the same answer to each.
• Find out, specifically, whose account your AI features run under.
• Decide which limits you always disclose, so nobody improvises one under pressure in a call.

None of this requires a certification or a compliance programme. It requires knowing which of your answers are architectural and which are promises, and being straight with the client about which is which.