Bring Your Own Database Your Database. In Your Account. In Your Region. Actually.

Most platforms hold your clients' vulnerabilities in a database they control. Pental inverts that: you create the database, in your own cloud, on a server of yours or on Supabase Cloud, and that is where everything lives, from the findings your clients read in your portal to every comment in QA. We run the software. You hold the data. This page is the machinery.

Start free trial Watch demoSetup guideBook live demo
121row-level security policies
99tables protected
107MFA freshness gates
0copies held by Pental
The Split

What Sits Where.

The trust boundary is short enough to state in full. Pental's side holds what is needed to bill you and route your domain. Your side holds the business.

Pental Holds
Account
Your account email and subscription state.
Billing
The Stripe customer record for the Pental subscription itself.
Routing
Your subdomain or custom domain and its DNS status, so requests reach your portal.
Limits
The number of testers your subscription is for. That is the end of the list.
Your Database Holds
The Work
Clients, assessments, phases, scopes, findings, evidence, files, reports, retests.
The Firm
Users, sessions, MFA enrolments, roles, checklists, the library.
The Identity
Branding, colours, templates, email settings and every secret, encrypted in place.
The Record
The full engagement timeline and history, queryable by you directly.

Product demo

See Your Own Database in the Demo

This is in the demo as “Your Own Database”, from 8:35, with the rest of the platform a chapter away.

  • 8:35 · Your Own Database
Three Homes

Guided Setup, No DBA Required.

Owning the database does not mean administering it. Pick where it lives: the same portal and the same policies run in all three, the setup checks each step from your browser as you go, and each home has a full written guide.

PostgreSQL in Your Cloud

Your cloud’s own PostgreSQL, or a server of yours, with the small Pental gateway beside it. Nothing from Supabase.

SuitsFirms standardised on Azure, AWS or Google Cloud that want the data in their own tenancy, on their provider’s managed database.

Pros
  • Your cloud’s own managed database (Azure Database for PostgreSQL, Amazon RDS or Cloud SQL), under the contract and controls you already have, with daily backups on from the first command.
  • One command creates the database, deploys the gateway and prints what the setup asks for.
  • On Azure the database has no public address, and on AWS it sits in private subnets.
  • Updates apply themselves every day, only when Pental has signed them, and your dashboard applies one at once.
Cons
  • Your cloud bills you for the database and for a gateway that is always running.
  • The setup token is yours to keep safe: it applies an update on demand, and a move needs it.
  • The gateway is one more service to keep current: a new version is the same command, pasted again.
Read the full guide

Self-Hosted Supabase

Supabase’s open-source stack on a server you run, from a kit we give you.

SuitsFirms that must keep everything on infrastructure they run, in their own cloud account or their own office.

Pros
  • Everything runs on your own server, in your Azure, Google Cloud or AWS account or on your own hardware.
  • It sets itself up: on first start the stack builds the portal’s database, with no SQL to copy anywhere.
  • Updates apply themselves every day, only when Pental has signed them, and one command takes an update straight away.
  • The same open-source Supabase software, Studio dashboard included.
Cons
  • You run the server: the operating system, Docker, disk space, monitoring and backups are yours to look after.
  • It needs a Linux server with Docker, a DNS name pointed at it and ports 80 and 443 open to the internet.
  • It is one server, so the portal is up when that server is.
Read the full guide

Supabase Cloud

A managed Postgres project in your own Supabase account, in the region you pick.

SuitsTrying Pental out, or a firm that would rather not run a server: the quickest start, and it moves to your own cloud later with everything in it.

Pros
  • Nothing to install, patch or keep running: Supabase runs the database, and its dashboard is where you look after it.
  • The quickest of the three to set up, and every step is checked from your browser as you go.
  • On a paid Supabase plan it is backed up every day, in the region you chose when you created it.
Cons
  • Updates are one paste rather than automatic: when a release changes the schema, an administrator copies the SQL into the project’s SQL editor and runs it.
  • The free tier is for trying it out: Supabase keeps no restorable daily backups on it, so a firm working on it for real wants a paid plan.
  • The data sits with Supabase as your hosting provider, in your own account. A client who needs it in your own cloud or on your own servers may prefer one of the other two.
Read the full guide

Not sure which? How to choose, side by side

  1. 01Create the database in your own account, in your own region. London, Frankfurt, Sydney, wherever your data-residency story needs it to be.
  2. 02Apply the setup SQL. We give you the script: on your own PostgreSQL the wizard applies it through your gateway, the self-hosting kit applies it itself, and on Supabase Cloud you paste it into your project’s SQL editor, compressed only so it fits there, with the readable file and its SHA-256 beside it to check against. It creates the tables, the 121 policies, the functions and the buckets. Nobody at Pental runs it on your behalf.
  3. 03Register one auth hook on a Supabase project, so it stamps its own session tokens with the claims its policies read. Two dropdowns in your project settings; the kit and the gateway do it for you.
  4. 04Hand Pental the address and a publishable key. Publishable, not secret: it is safe to hold precisely because every table is behind the policies you just installed. The setup token of a gateway stays with you; Pental never sees it.

And you can change your mind: Move your database on the dashboard copies everything between any two homes, in your own browser (or on your own computer, with the same code), with your own credentials. Saving pauses while it runs (reading and signing in carry on), so nothing is lost, and the portal switches over only once every count matches. How a move works

Enforcement

Six Mechanisms, None of Them a Policy Document.

“We take your privacy seriously” is a sentence. These are constraints the database enforces on every request, including requests from us.

  • Physical isolationOne firm, one database. There is no shared table holding several firms’ rows, so there is no tenant filter to get wrong and nothing else in the database to reach. The usual multi-tenant arrangement rests on every query remembering a where-clause; here the separation exists before any query runs.
  • Row-level security121 policies, with row-level security enabled on 99 tables, evaluated by Postgres on every query. Application code cannot wave a request through and neither can a bug in it. A request that fails a policy receives zero rows, not an error describing what it was denied.
  • Freshness-gated MFAEvery data-access policy also requires that the session has recently proved possession of a second factor, required by 107 of them. A token lifted off a laptop is not enough to read a finding, because possession of a token is not the question the database asks.
  • Per-project signing keysYour project signs its own session tokens with its own keys. A token from any other environment does not fail an authorisation check against your data, it fails to validate at all.
  • Secrets encrypted at restSMTP passwords, AI keys and integration tokens are encrypted on write, inside your database, with a key generated in that same database. The plaintext column is nulled. Nine secret columns get this treatment, and the encryption key never leaves your project.
  • Dual-signed server callsThe narrow set of operations Pental’s servers can ask your database to perform is signed twice, by two parties holding their keys separately, bound to a single operation and tenant, with nonce-based replay protection. The most sensitive reads refuse server credentials entirely and require a signed-in user of your firm.
The Claim, Walked Through

Why “We Cannot Read Your Data” Is Architecture, Not Marketing.

Follow what a read of your findings actually requires, and where each requirement leaves Pental.

  1. 01The row lives in your project, not on a server of ours, so there is no internal database for a Pental employee to browse.
  2. 02Reading it requires passing row-level security, which Postgres evaluates on every query. Those policies demand an authenticated user of your firm.
  3. 03They also demand a recent second-factor check. Resetting or enrolling a factor requires an administrator signed in to your portal, and that administrator is one of your people, not one of ours.
  4. 04Sessions are signed with your project's keys, so a credential from anywhere else fails validation outright.
  5. 05The server-side operations that do exist are dual-signed, single-purpose and replay-protected, and the most sensitive reads refuse server credentials entirely. There is no general-purpose read path to misuse, which is what “no code path in” means.
The Honest Summary

Control of access to your data rests on people signed in to your own portal with fresh second factors, under policies enforced by your own database. That is a stronger position than any promise we could make, because it does not depend on you believing us.

What a Breach of Pental Would Reach

This is the question worth asking any platform in this space, so here is ours answered precisely.

If Pental's Systems Were Compromised
What Is Exposed
What runs your account: who you are, your subscription and billing record, how you sign in to pental.io, your portal's address and where your database is, two counts of your users and client records, and what you have sent us. That is the entire inventory on our side, as the privacy policy sets out.
What Is Not
Every client, engagement, finding, piece of evidence, report and credential you hold, because none of it is on our systems to take.
Why Not
Your data lives in a Postgres database in your own account. There is no copy of it on our side and no general-purpose read path into yours.
The Code We Serve
It changes only when Pental's technical director deploys it, from Pental's own computer, behind two-factor sign-in, and updates to your database are signed there with a key that never leaves it. What protects it.
Why a Pental Employee Cannot Read Your Data
Wrong Credentials
Your project signs its own session tokens with its own keys, so nothing we hold validates against it. No support account, no break-glass login, no key of ours in your project.
The Database Decides
Row-level security policies are evaluated by Postgres on every query and also require a recent second-factor check. A request that fails them gets zero rows, whoever made it.
Only You Can Let Anyone In
Adding a user, changing a role and resetting a factor all happen in your own portal, by your own administrators. There is no internal process that ends with one of us holding a valid session.
The same dashboard again, with the theme colours, accent, severity scale and typeface all changed by the firm.
VantrellTheir teamDemonstration portals. The four firms are invented; every screen is the real software.
Practicalities

Region, Backups, and the Day You Leave.

  • Residency you can point atThe region is chosen by you at creation, in your own hosting account. When a client's security questionnaire asks where their data is held, the answer is a fact about your infrastructure, not a paragraph about ours.
  • Backups on your scheduleAzure, Amazon RDS and Cloud SQL back the database up as part of their platform (the gateway's scripts switch it on), as does Supabase on its paid plans, and a self-hosted stack is backed up by you, with the command its guide gives. Because the database is yours, you can also dump, snapshot or replicate it on any schedule your policy requires, with your own tools.
  • Export any timeEverything is exportable from the portal, and everything is also just rows in your Postgres, reachable with psql. No export request, no ticket, no waiting.
  • Cancelling is undramaticEnding the subscription ends your access to the software. Your database carries on exactly as it was, in your account, with every row intact, because it was never in our custody to hand back.
Trust, Then Verify

Every Number on This Page Is a Query Away.

Connect to your own project with your own credentials and count for yourself. The figures we publish are properties of the schema the install creates.

psql, your project
=# select count(*) from pg_policies where schemaname = 'public';
 121row-level security policies
=# select count(*) from pg_tables where schemaname = 'public' and rowsecurity;
 99tables with row-level security on
=# select count(*) from pg_proc where pronamespace = 'public'::regnamespace and prosecdef;
 609definer functions, all 609 with pinned search paths
-- and grep the policy definitions for mfa_is_fresh(): 107 policies

The full layer-by-layer account, including authentication, enumeration resistance and secret handling, lives on the security page

Questions

Questions About Your Database.

No. Every portal runs on a database your firm owns, and the price is per tester with every feature included. The database itself is paid for wherever it is hosted: your own cloud account, your own servers, or Supabase.

Yes, if you want to. Copies of reports and files can also be kept in your firm’s own SharePoint or Google Drive. It is off until you switch it on, and the originals stay in your own database either way.

Yes. A firm can move between PostgreSQL in its own cloud, self-hosted Supabase and Supabase Cloud later, taking everything in it, so the choice made on the first day is not permanent. Each option has its own written guide, and so does the move.

No. Your clients, findings, evidence and reports live in your database, where Pental cannot read them. Pental holds the account, the subscription and the domain routing, and row-level security policies in your own database decide who sees what.

Keep Reading
Built by pentestersWhy one database per firm, and what it costs us.SecurityThe layer-by-layer account of every mechanism.PricingYour own database at any size, from a single tester.Database guidesAll three homes and the move between them, step by step.Free reporting toolRun reporting and pentest management yourself too: free and open source on GitHub, software and data on your own server.

Create the Database. Keep the Database.

Creating the database is a guided step, with a full written guide for each of the three homes and the whole setup recorded. The trial is free, with no card required, and the database you create stays yours either way.

Start free trial Watch demoSee the platformBook live demo Get our free reporting tool