Uncharted Dynamics
← All insights

We're security engineers, not report-writers — why the report is the easy part

Gabriel Conlon

A firm pays for a security assessment. Back comes a thick report, full of red and amber findings, an executive summary, a risk matrix. Everyone nods. The consultant invoices and leaves. And then nothing happens. The report goes in a drawer, and the gaps it named are exactly as open as they were the week before, except now they’re documented.

If you’ve bought one of these, this isn’t aimed at you. It’s aimed at the model that sold it to you.

The report is the product, and that’s the problem

Here’s the position, flat. A great deal of small-business security consulting is assess, invoice, leave. The report is the deliverable. Fixing what it found is “out of scope”: a separate engagement, a separate quote, or more often somebody else’s problem entirely.

The model persists because it’s a good business, not because it makes anyone safer. An assessment is easy to sell, easy to scope, and easy to deliver on a schedule. You run the tooling, you interview a few people, you format the output. Implementation is none of those things. It’s hands-on, it’s specific to the client’s actual systems, and it needs people who can do the work rather than describe it.

So a whole industry sells the easy part and calls it security. A gap report is the cheap 20%. The fix is the hard 80%. Selling the 20% and stopping there is the thing that gets under my skin, because the client walks away believing they’ve done something, when all they’ve done is pay to have the same risks written down.

What the hard 80% actually looks like

Let me make this concrete with one engagement. I’ll keep it anonymous: it was a client platform, a multi-tenant SaaS system, and the details stay theirs.

Multi-tenant means many customers share one system, each walled off so they only ever see their own data. The wall is the entire promise of the product. On this platform, the wall had a gap. An authenticated, perfectly ordinary user of one tenant could reach another tenant’s data: financial records, identifiers, things that belonged to a different company entirely.

Sit with that for a second, because it’s the part that matters and the part a report reduces to a line item.

Nobody had broken in. There was no attacker. A legitimate logged-in user, someone who had every right to be in the system, was able to see across a boundary they should never have been able to cross and into records that weren’t theirs. That is precisely the kind of flaw a security questionnaire never catches and an automated scan rarely flags, because from the outside everything looks authorized. It is authorized. It’s just authorized for the wrong data.

A report-writer documents this as “tenant isolation gap — HIGH,” files it under Broken Access Control (the category that has topped the OWASP Top 10 for years), and moves to the next finding. All true. All useless on its own, because the door is still open when they leave.

Here’s what we did instead. We found it, then we worked out why the isolation was failing, not at the surface but at the data layer where the system had been trusting the application to remember which tenant it was serving on every single query. Trust like that holds right up until one code path forgets. So we moved the enforcement underneath the application, row-level access control, so the database itself scopes every query to the right tenant, server-side, whether or not the app remembers to ask. The wall stops being a promise the code makes and becomes a rule the data enforces.

And then — this is the whole point of the post — we proved it. We built a large suite of automated tests that assert the isolation actually holds, across the platform’s data layer, and wired them into a standing check that runs on every future change. So the day someone’s unrelated edit quietly reopens the hole, the build fails and the change never ships. Nobody has to remember. Nobody has to notice.

That’s the difference between a report and engineering. A report tells you the door is unlocked. We lock it, test that it’s locked, and install an alarm that trips if it’s ever unlocked again. The fix isn’t finished when the code changes, it’s finished when it can’t silently come undone.

What we don’t do, and why

If I’m going to be sharp about what other people sell, I owe you the same honesty about what we don’t.

We don’t run a helpdesk. We don’t do break-fix, we don’t reset passwords, and we won’t take over managing all of your IT. Not because those jobs are beneath anyone; they’re real work and they matter. It’s that doing the hard engineering well means protecting the time it takes. A two-person firm that says yes to everything does everything at half depth. The refusal is what makes the promise credible. We take on the work that needs someone who can actually close a gap and prove it stays closed; we don’t dilute that by becoming your everything.

It also means the people who assess are the people who fix. There’s no handoff to a junior, no “the findings team is separate from the remediation team.” The person who found the tenant-isolation gap is the person who closed it and wrote the test that keeps it closed.

The one question that sorts real help from paperwork

If you’re hiring anyone to look at your security, you can cut through most of the sales gloss with a single question:

“When you find gaps, do you fix them, or just list them?”

Then follow it: who actually does the remediation, you or someone I hire next? Will you re-test after the fix to prove it worked? And when you leave, do I own the fixes, or just the report?

The answers sort the field fast. Plenty of good assessment-only firms exist, and sometimes a report really is all you need, but you should know which one you’re buying before the invoice, not after.

You don’t want a report. You want to be more secure.

That’s the whole thing. A report is a description of your problems. Being more secure is the resolution of them, tested, and fenced so it stays that way. One of those is the job.

This is the discipline underneath answering a customer’s security questionnaire honestly rather than hopefully, the questionnaire lists the gap — the work is closing it. It’s the same “real discipline, not theater” thread running through what a decade of defense-grade security taught me. If what you want is to actually be more secure, not just to know precisely how you aren’t, that’s the work we do.

References & further reading

Sources cited in this post:

Related reading on this site: