Answering a Security Questionnaire About Your Pentest Platform

Answer a security questionnaire about your pentest platform with mechanisms rather than adjectives: say where your clients' findings are stored, who holds credentials that can read them, and what a breach of your platform vendor would expose. The question arrives inside a two-hundred-row spreadsheet from a procurement team who will not read your answer closely, but will notice if you cannot give one.

It is a fair question. You are asking a client to hand you a map of every weakness in their estate, and that map has to live somewhere. What you are really being assessed on is not your own security posture but the posture of whatever platform you record findings in, because that is where the concentration of risk actually sits.

Why the question got harder

Three things changed at once. Regulators started treating supplier chains as in scope rather than as somebody else’s problem. Cyber insurers began asking where third parties hold sensitive material. And a series of well-publicised incidents at software vendors taught security teams that a supplier’s breach is their breach, particularly when what leaks is a list of their unpatched systems.

So the question is no longer "are you secure". It is "what would an attacker get if the company you use were compromised", and the honest answer depends entirely on an architecture decision you probably made years ago without thinking of it as one.

The three arrangements, and what each one commits you to

Almost every firm is running one of three models. They are not equivalent, and it is worth knowing which one you are defending before you start filling in boxes. The trade-offs are set out at more length in self-hosted or cloud pentest reporting.

None of these is disqualifying on its own. What gets firms into trouble is answering as though they are running the third when they are running the second.

The fields that actually get scrutinised

Most of the sheet is boilerplate. These are the rows a competent reviewer reads properly, and what a strong answer looks like in each.

Data location and residency

They want a country, not a region name from a marketing page. If your platform can tell you which physical region a given client’s findings sit in, say so and name it. If it cannot, that is worth knowing before a client asks rather than during.

Sub-processors

List them, with what each one actually touches. A reviewer is looking for two things: that the list is short, and that you know what is on it. A firm that names its hosting provider, its payment processor and nothing else is in a far stronger position than one that lists fourteen services and cannot say which of them ever sees client data. The data protection side of this is covered in UK GDPR for penetration testing firms.

Access control

The weak answer is "role-based access control". Every product says that. The strong answer describes where the decision is made. Access enforced inside the database, evaluated on every query, is a different claim from access enforced by application code that has to remember to filter, because the second one fails open when somebody forgets a where-clause.

Authentication

Say what the second factor is, and when it is checked. There is a meaningful difference between an account that has multi-factor authentication enrolled and a session that must have proved a factor recently before it can act. The first is a checkbox. The second survives a stolen laptop, and it is the distinction drawn in password and MFA policy that matches the guidance.

Vendor staff access

This is the row where most answers go vague, and it is the row that matters most. "Our staff access customer data only when required for support, under a documented process" is an answer about intentions. "Our vendor has no credential that satisfies our database’s access policies" is an answer about mechanisms. A reviewer can only verify the second.

A policy describes what people intend to do. An architecture describes what they are able to do. Only one of those survives a bad week.

Answers that read badly even when they are true

• "Data is encrypted at rest." True of essentially every managed database on earth, and irrelevant to whether the vendor can read it, since they hold the keys. Say it if asked, but never lead with it.
• "We are ISO 27001 certified." Useful context, not an answer to a technical question. A certificate tells a reviewer you have a management system, not what happens to their findings.
• "Only authorised personnel have access." Authorised by whom, and enforced by what? This phrasing invites the follow-up question rather than closing it.
• "We take security seriously." Every response that contains this sentence is weaker for containing it.

Turning the answer into an asset

Firms that answer these quickly do one thing differently: they write the answers once, properly, and keep them somewhere findable. The sheet changes shape every time, but the underlying facts do not.

1. Write a one-page architecture statement. Where client data lives, in which account, in which region, under whose credentials. Two hundred words, no adjectives.
2. Keep a current sub-processor list. Name, purpose, what it sees. Review it whenever you add a tool, not whenever a client asks.
3. Record your access model in mechanism terms. Where the decision is made, what a failed check returns, what a second factor gates.
4. Prepare the vendor-breach answer. One paragraph on what would be exposed and what would not, with the reason attached.
5. Keep evidence to hand. A screenshot of the region setting, a copy of your access policy, the retention schedule. Attach rather than describe.

What good looks like at the end

• You can name the country your client’s findings are stored in without checking.
• Your sub-processor list fits in a sentence and you know what each one touches.
• Your access answer describes a mechanism, not an intention.
• You can say what a compromise of your tooling vendor would expose, precisely.
• The whole response takes an hour, because you wrote it once and kept it.

The firms winning work on these questionnaires are not the ones with the longest answers. They are the ones whose answers are short because the underlying arrangement is simple enough to describe in a sentence.