Who Built It

Built by People Who Break Platforms Like This.

Every vendor in this category says it was built by practitioners. The claim only means something if you can point at the decisions, so this page does that: the choices in Pental that a team without a tester in it would very reasonably have made the other way, and what each one costs us.

Start free trial Book a demo
The Short Version

A Working Tester Wrote It for the Job in Front of Him.

Pental was built by a practising penetration tester in the UK, because the existing options each asked for a compromise nobody in this trade should have to make: hand your clients' vulnerabilities to somebody else's database, put another company's name in front of your customers, or send your findings through a model you do not control.

  • Used on real engagementsThe person building it is also delivering testing on it, so a workflow that is technically complete but annoying at four in the afternoon gets fixed rather than filed.
  • Built for consultancies, from the tester's side of the deskThe customers are firms serving their own clients. It was written by somebody doing the testing rather than somebody running the business, which is why the parts that get the most attention are the ones a tester touches every day. That is also why nothing in setup requires a repository, a config file or a terminal: your people have a browser and a login.
  • Small enough to answerA technical question about the architecture gets a technical answer from somebody who wrote the code, rather than a ticket number.
The Evidence

Six Decisions a Non-Tester Would Not Have Made.

Each of these makes the product harder to build, harder to support, or harder to monetise. They are here because the alternative is something we would flag in a report if we found it at a client.

Architecture
One Database Each
Every firm gets its own Postgres project rather than a row in ours. It is more moving parts and more support, and it means a breach of Pental reaches no client data at all. A shared database with a tenant column would have been far easier and is exactly the design we would attack first.
No Support Login
There is no break-glass account that lets someone here read your data, which makes support harder and removes the credential an attacker would go after. Resetting a factor happens inside your own portal, by your own administrator.
Freshness, Not Enrolment
Most platforms treat MFA as something you did once. Every data-access policy here asks whether this session has recently proved a second factor, because a token lifted off a laptop is the realistic attack and enrolment does nothing about it.
Product
Your AI Key
Findings are drafted on your provider account or a model on your own hardware. Proxying it through us would be simpler, cheaper to support, and would mean your client's unpatched estate travelling through a third party nobody agreed to.
Every Feature, Every Plan
Nothing sits behind a higher tier, including the security machinery. Selling MFA policy or audit trail as an upgrade is standard in this industry and is the thing we would refuse to pay for ourselves.
Scans Kept Apart
Scanner output stays out of the penetration test report by construction. Blending them would make demos look better and would quietly sell automated output as tested work.

The fastest way to check any of this is to create an account and look at what the database actually enforces.

Start free trial Read the security model
How It Gets Tested

Attacked as It Is Built, Not Audited Once a Year.

The people writing this spend their working weeks finding the flaws that end up in reports like yours, and the product is built against that list rather than against a compliance checklist.

  • Authorisation is the first questionThe failure we find most often at clients is an object reference nobody checked. Here the check is a database policy evaluated on every query, so application code cannot wave a request through and neither can a bug in it.
  • Denial is silentA request that fails a policy gets zero rows rather than an error describing what it was not allowed to see. Enumerating through error messages is a technique, not a theory.
  • Sessions are assumed stolenThe design starts from a token already being on an attacker's machine and asks what it can still do. The answer is nothing that reads client data.
  • Server calls are signed twiceThe narrow set of operations our servers can ask your database to perform is signed by two parties, bound to one operation, with replay protection, and the most sensitive reads refuse server credentials outright.
  • Sign-in is a code, never a linkMail security products fetch every URL in an email to detonate it, which spends a single-use sign-in link before the recipient ever sees it. A code has to be typed, so a scanner cannot spend it.
The Question Worth Asking Any Platform in This Space

If your vendor were breached tomorrow, what would the attacker have of your clients? Our answer is an account email, a subscription record and a domain name, because that is all we hold. A platform keeping every customer in one database it controls cannot give that answer, whoever built it. See exactly what an attacker would get

The Unglamorous Parts

The Problems Only Somebody Doing the Job Would Bother Solving.

These are not the features that sell a demo. They are the ones that decide whether the platform survives contact with a real engagement week.

  • The report comes backEveryone generates a document. What actually happens next is that it gets edited in Word and delivered, and the platform is then wrong about what the client received. Pental reads the edited document back in, field by field, and shows you every difference before writing any of it.
  • Formatting held on a styleWord keeps a great deal of formatting on the style rather than on the text. Reading a document back correctly means handling that, which is tedious, invisible when it works, and the reason your appendices survive the round trip.
  • The same weakness twiceA finding found externally and internally is two findings with different exposure, not one, and the phase it came from travels with it into the report.
  • Scanner output merges itselfTwenty-nine rows that are really two issues across fourteen hosts get merged by title, keeping the worst severity and every host's own evidence, because the alternative is a client opening a report with the same paragraph nine times.
  • Version numbers are never foldedTwo similar TLS titles are two different vulnerabilities. Merging them would put one under the other's heading in a client's report, and there is no undo for that, so the matching is deliberately not fuzzy.
  • Evidence keeps its hostMerged findings carry a table of which host produced which output, because eleven hostnames without saying what was seen on each is weaker than eleven separate findings.
Fit

It Already Speaks the Way Your Firm Works.

Generic project tooling makes you translate your job into its vocabulary. This one starts from the shape of the work and then gets out of the way of your methodology.

  • Phases, not tasksAn engagement is phased the way you actually sell it, each with its own dates, testers, checklist and findings, under one report.
  • CVSS that cannot disagree with itselfThe vector is derived as you toggle metrics, so the score and the string always match, and a finding is never handed a severity nobody chose.
  • Your fields and your sectionsRename anything, add what your methodology carries, decide what the report contains, and write the prompt behind each one. There is no hidden prompt anywhere in the product.
  • Your testing addressesYour public source IPs are on file and appear on proposals and reports automatically, because whitelisting is a conversation every engagement has.
  • Coverage you can produceChecklists and runbooks attach per phase and record what was covered, which is the answer when a client's auditor asks what was tested.
Restraint

What This Product Deliberately Does Not Claim.

Knowing the trade also means knowing which claims are hollow, and refusing to make them is part of being built by people who would have to defend them.

  • It does not test anythingPental never contacts a target and runs no scanner of its own. Where scanning happens it is your licence, your credentials and your authorisation.
  • It does not replace a testerThe AI drafts from evidence you captured and is edited by a human before anything ships. The judgement is the product your clients are buying, and automating it would be selling them something else.
  • It does not invent severityWhere a scanner asserts nothing, nothing is asserted. A column appears only when a result actually fills it.
  • It does not hold your data to keep youEverything is exportable at any time, and the database is directly queryable by you regardless. Cancelling ends the software, not your access to your own records.
Keep Reading
SecurityThe mechanisms behind every claim on this page.Your databaseWhat we hold, and what we cannot reach.The platformThe engagement, from first email to paid invoice.

Judge It the Way You Would Judge a Client's Application.

Create an account, look at what the database enforces rather than what the marketing says, and send the awkward questions to the people who wrote it. Seven days free, no card.

Start free trial Read the security modelBook a demo