Self-Hosted or Cloud Pentest Reporting: The Third Option

Self-hosted pentest reporting keeps client findings in your own account and hands you every job that comes with them; shared cloud reporting takes those jobs away and usually puts your findings in a database with every other customer's. A third arrangement splits the difference: the vendor runs the application and the data sits in a database your firm owns. The right choice depends less on "cloud or not" than on who holds the data, who can reach it and who patches what.

What you are choosing between

The usual framing, cloud against self-hosted, hides the question that matters. Most self-hosted tools run in a public cloud anyway. What actually differs is whose account holds the data, who runs the software, and what an attacker gets by breaching each party.

• Shared multi-tenant SaaS. One application and, usually, one database for every customer, with a tenant identifier on each row. The vendor runs everything.
• Self-hosted software. You install the application and its database on a server you control, in your office or your own cloud account. You run everything.
• A hosted application on your own database. The vendor runs the application; the data lives in a database your firm creates in its own account and region, and access is enforced inside that database.

Shared SaaS: convenience and blast radius

Shared SaaS is the easiest model to start and to run. Someone else patches, backs up, monitors and answers the pager, and a new firm can be writing findings in an afternoon. For most business software that is the right trade.

Pentest findings change the arithmetic. A shared database of reporting customers is a database of many organisations' unfixed weaknesses, which makes it a target worth real effort. Separation between customers usually rests on application code adding the right tenant filter to every query, and the NCSC makes separation between customers one of its 14 cloud security principles. One missed filter or one stolen vendor credential can expose every customer at once, and vendor staff with production access can, in principle, read your findings. Your residency options are the vendor's regions, deletion is a request you take on trust, and leaving means an export.

Self-hosted: control and upkeep

Self-hosting takes the vendor out of the blast radius. Your findings sit beside nobody else's, residency is wherever you put the server, and you can run it with no internet exposure at all, which some classified and regulated work requires.

The price is that you become the vendor. Someone in the firm patches the operating system, runtime, database and application; tests each upgrade against your templates; takes backups, copies them off the box and proves they restore; renews certificates; watches the logs; and is on call the night before a big delivery when the service will not start. If the tool lacks multi-factor authentication or single sign-on, you put them in front of it. If clients need to log in, the box faces the internet, and the most valuable server in your estate becomes the most exposed one. We count those hours in what open-source pentest reporting actually costs, and they come to far more than the server bill.

A hosted application on your own database

The third model separates running the software from holding the data. The vendor deploys and updates the application. Your firm creates the database in its own cloud account or on its own server, in a region it chooses, and, done properly, access is decided inside that database by policies evaluated on every query, so a request without a valid session from one of your users gets nothing back.

The vendor's blast radius shrinks to what the vendor holds, typically your account, subscription and domain details, not your clients' findings. Residency becomes a fact about your account rather than a paragraph in someone else's terms. Backups follow your policy, and most managed database services take them automatically. If you leave, the data is already in your account.

It has trade-offs of its own. You own a cloud account, its bill and the people with administrator rights on it, and those need multi-factor authentication and access reviews like anything else holding client data. The vendor's application still works on your data on behalf of signed-in users, so the quality of its code and its update process still matter. An outage can now sit with either party. Our guide to creating your database shows what owning one involves in practice.

The three models side by side

What clients and auditors ask

The questions arrive in security questionnaires, data processing agreements and accreditation assessments, and they are the same whichever model you choose. What changes is how short your answers can be.

• Which country is our data in, and in whose account?
• Who can read our findings, including your vendor's staff, and is what stops them a policy or a mechanism?
• Which sub-processors touch our data?
• Is multi-factor authentication enforced for every user, including ours?
• When did you last restore from a backup?
• How and when is our data deleted, and how would you prove it?

Two rules shape the answers. UK GDPR does not require data to stay in the UK, but a transfer outside it needs adequacy regulations, an approved safeguard or an exception, and many clients go further in contract and require UK or EEA storage. This is not legal advice, and a client's contract can be stricter than the law. And if you want CHECK membership, the NCSC requires Cyber Essentials Plus on every system that stores or processes engagement information, which puts your reporting platform firmly in scope. Our post on answering a security questionnaire about your pentest platform covers the rows reviewers read most closely.

Questions for any vendor

1. Is our data in a database shared with other customers, and if so, what enforces the separation?
2. If you were breached tomorrow, exactly what of ours would the attacker get?
3. Can your staff read our findings, and is the answer a policy or a mechanism?
4. Which region holds our data, and can we choose it?
5. Who holds the encryption keys and the secrets we store, such as AI and mail credentials?
6. How do we get everything out, in what format, and what happens to our data when we stop paying?
7. Does AI see our data, and under whose account and terms?

A vendor that answers in mechanisms rather than adjectives has usually thought about the questions before you asked them. The wider buying checklist is in choosing pentest reporting software.

Matching the model to your firm

• Shared SaaS suits a firm whose clients do not ask where findings live, that has no appetite for running anything, and whose vendor answers the questions above specifically. Revisit it when the first regulated client arrives.
• Self-hosting suits work that must stay off the internet or inside a client's environment, and firms with someone who genuinely enjoys running servers and has the hours to do it properly.
• A hosted application on your own database suits firms whose clients ask residency and vendor-access questions, who want short answers to them, and who would rather not patch an application server.

Whichever you pick, write down why. The reasoning is what an auditor wants to read, and it is what you will need when the answer changes.