Read the report before you buy.
Security testing is sold on trust because the buyer rarely sees the product before paying for it. This is the format we deliver, and a worked finding taken all the way through — summary, reproduction, evidence, impact, fix, retest.
This example is illustrative. The practice, the hostname, the matter IDs and the finding are invented for this page. We do not publish client findings, sanitized or otherwise — a redacted real report is still a real report, and the industry it describes is small enough that details identify people.
What is in the document.
Six sections, always in this order. The executive summary is first because the person who signs the invoice should not have to read a findings table to learn whether the engagement went well.
- Executive summary
- One page. What we tested, what we found, what it means commercially, and what we would fix first. Written for the partner or practice manager who has to decide what to fund, and readable by someone who will never open the rest.
- Scope and rules of engagement
- The exact hosts, applications and accounts in scope, the testing window, what we agreed not to touch, and the escalation path if we found something critical mid-engagement. Copied verbatim from the signed scope so there is no drift between what you bought and what we did.
- Method
- Which standards the work ran against and to what level, so a reader can tell a tested requirement from an untested one. An assessment that does not state its coverage is not reproducible.
- Findings
- One entry per issue, each with reproduction steps, evidence, business impact and remediation. Ordered by what we think you should fix first, which is not always the same as the highest score.
- What we could not test
- The parts of the surface we did not reach, and why — out of scope, unavailable during the window, or blocked. A report that implies total coverage it did not have is worse than no report.
- Retest record
- What was fixed, what was verified, and what remains open, with dates. Issued after the 30-day retest at no extra cost.
One finding, all the way through.
An authorization gap, chosen because it is the kind of flaw no scanner reports: every request is well-formed, the endpoint behaves exactly as written, and nothing in the response looks like an error.
- Finding
- PD-2026-014
- Title
- Any authenticated user can read another practice's matter documents
- CVSS 3.1
- 6.5 Medium — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
- Business impact
- High — see note below
- Mapping
- OWASP ASVS V4.2.1 (IDOR) · MITRE ATT&CK T1213
- Status
- Fixed; verified at retest on day 12
Summary, as the client reads it
A logged-in user at one practice can retrieve documents belonging to a different practice by changing a number in a web address. No password is needed beyond the user's own, no software is required, and the application records the access as normal activity. We reached two documents on a matter that did not belong to the account we were using, including an executed engagement letter.
Reproduction
- Authenticate to the application as a standard user belonging to Practice A.
- Open any matter owned by that practice and note the numeric matter ID in the URL.
- Call the document listing endpoint directly, substituting a matter ID belonging to Practice B.
- Observe a 200 response containing document metadata and signed download URLs for the other practice's matter.
- Fetch one of the returned URLs. The document downloads with no further authorization check.
Evidence
GET /api/v1/matters/8814/documents HTTP/1.1
Host: app.example-practice.test
Cookie: session=<redacted>
HTTP/1.1 200 OK
Content-Type: application/json
{
"matter_id": 8814,
"practice_id": 27, <-- session belongs to practice_id 14
"documents": [
{ "id": 41902, "name": "Engagement letter (executed).pdf",
"url": "https://.../41902?sig=<redacted>" },
{ "id": 41913, "name": "Deposition transcript - draft.docx",
"url": "https://.../41913?sig=<redacted>" }
]
}Redacted for publication. In a real report the session token and signed URLs are replaced the same way, and the full transcript is supplied separately.
Why the two ratings differ
CVSS scores this 6.5, Medium. We record the business impact as High, and we say so in the same row rather than quietly overriding the number. CVSS measures the technical characteristics of the flaw; it has no way to know that the records are client-confidential, that the practice owes a notification duty if they were disclosed, or that an opposing party obtaining a draft deposition transcript is a different category of problem from a data-protection ticket. A report that hands you only the score has done the arithmetic and left you the judgment.
Remediation, and what happened next
Enforce the authorization check server-side, on the practice ID carried by the session rather than the one supplied in the request, and apply it to the document-fetch endpoint as well as the listing endpoint — fixing only the listing leaves the signed URLs reachable. Add a regression test that asserts a cross-practice request returns 403.
This one was reported the afternoon we found it rather than held for the report, because a live cross-tenant disclosure is not a finding to save for a meeting. It was fixed in nine days and verified at retest on day twelve, inside the 30-day window included in the price.
What you will not find in it.
- Raw scanner output pasted in as findings. Tool results are triage input, not a deliverable.
- Severity inflated to justify the invoice. An informational finding is labeled informational.
- Padding — no forty pages of generic advice about password policy wrapped around six real issues.
- Findings without reproduction steps. If your engineer cannot reproduce it, we have not finished writing it.
- A separate charge to check whether the fix worked.
The method behind it is on the services page, and the engagement model is on how we work.