For consultancies
You are holding several clients’ attack surfaces at once
A firm running engagements has a problem an internal team does not: the data is not yours, the report is the deliverable, and the same estate comes back in six months expecting to hear what changed. Those three facts drive most of how this is built.
Six problems
What actually goes wrong between the test and the deliverable
None of these are AI problems. They are bookkeeping problems that a drafting model makes faster and worse if you put it on top without fixing them first.
The report takes longer than the test
Exporting a scanner’s findings, cleaning them in a spreadsheet, writing the same remediation paragraph for the eleventh time and rebuilding the risk matrix by hand is where the days go. The engine assembles the deliverable from the findings themselves, so the analyst is editing judgement rather than retyping data.
March’s report and June’s report do not know about each other
Two disconnected documents cannot tell a client what got fixed. Findings persist in an engagement with a history, so the second report can say new, persisting, reappeared or fixed — with each classification traceable to the scan that produced it.
Two scanners, one estate, three counts of the same weakness
Findings get a fingerprint stable across scanner versions, so the same weakness from Nessus and Qualys collapses into one finding retaining both sources. The client stops being handed a total that is inflated by tooling.
Nobody can prove where a sentence in the report came from
When a client challenges a finding six weeks later, the answer has to be better than “the tool said so”. Every narrative claim links to the findings behind it and every finding to the scan row it was parsed from, kept at write time rather than reconstructed under pressure.
A junior’s report and a partner’s report do not read alike
Structure is asserted by the engine — executive summary, methodology, scope, risk matrix, findings, remediation roadmap — so the fifth report of the month has the same spine as the first. What varies is the analysis, which is what you are actually being paid for.
Client data is sitting in whatever the analyst had open
Scan artifacts are attack maps. In this system they are encrypted with per-organisation keys, reached through short-lived signed URLs, deleted on a retention policy, and every read and export is recorded with actor, address and timestamp.
The floor, not a feature
Isolation is architecture here, not configuration
A platform holding several clients’ vulnerability data in one undifferentiated pile is a breach that hands an attacker a pre-written plan for every one of them. So the separation sits in the data layer, underneath everything that could forget to ask for it.
- Scoping enforced in the data layer, never in a route handler someone can forget to guard.
- A cross-tenant read, list, search or download all denied — and denied with “not found”, so the existence of another firm’s engagement does not leak.
- Per-organisation encryption keys on scan artifacts and evidence, not one bucket key for everybody.
- Roles that match how a firm actually works: owner, lead, analyst, read-only — and a client role scoped to a single engagement.
- Multi-factor authentication that cannot be skipped by any role able to read a finding.
An engagement, end to end
Five steps, and the one in the middle is the point
- 01
Scope
A client, an engagement, its kind and its rules of engagement, with the assets in scope recorded rather than remembered.
- 02
Ingest
Scans uploaded as the test runs, each accounted for row by row — including the rows that could not be read.
- 03
Triage
The analyst’s work: false positives, accepted risk, severity overrides with reasoning, evidence attached to what matters.
- 04
Generate and review
The deliverable assembled from triaged findings, read against its own provenance, then signed by a lead who is not the author.
- 05
Hand over
DOCX or PDF for the client, an XLSX register for their tracker, and an engagement that still knows all of it when you come back in six months.
Said plainly
Built for the firm, not sold up to it
Tenancy, per-client keys, white-labelled output and a read-only client view are not enterprise upsells here — they are what running engagements on somebody else’s estate requires, so they are part of the floor. If your work does not look like the six problems above, tell us where this page is wrong about it; that is worth more to us than agreement.
Tell us where it is wrongRunning engagements for other people’s estates?
This is built for the firm holding several clients’ estates at once — which also makes you the person best placed to tell us where it is wrong about your work.
Get in touch
Talk to the people building it
No chatbot and no ticket queue. Tell us what your security reporting actually looks like — which tools you live in, how long a deliverable takes, what a client has sent back — and someone who works on the software will reply.
info@legosphere.com