What a Cybersecurity Audit Should Actually Produce

There is a version of a cybersecurity audit that is essentially theatre. Someone runs a scanner, exports the output, adds a cover page with your logo, and delivers two hundred findings sorted by a severity score that a tool assigned without knowing anything about your business.

It is not useless, exactly. It is just not worth what it costs, and it creates a dangerous feeling of having done something.

Here is what to expect instead.

An audit should start with what you care about

Before any tool runs, someone should ask what would actually hurt.

For one company it is customer data. For another it is being unable to operate for a day. For a third it is a regulator. These lead to completely different audits, and an audit that does not begin with that conversation is going to grade you against a generic checklist.

If the first meeting is about scheduling scans rather than about your business, you are buying the theatre version.

Findings need to be about you

The difference between a real finding and a generated one is context.

A generated finding says: this library has a known vulnerability, severity high. A real finding says: this library has a known vulnerability, it is reachable from an unauthenticated endpoint, and exploiting it would expose the customer table.

Same technical fact. Completely different urgency. The second one tells you whether to fix it this afternoon or this quarter.

If every finding in your report could have been written without seeing your architecture, the audit did not really look at your architecture.

The three things that should always be checked

Regardless of scope, an audit that skips any of these has skipped the common ground where most breaches actually happen.

Access. Not who has access, which is a list. Who has access and no longer needs it. Permissions accumulate. Almost nobody ever asks for less.

The external surface. What is reachable from the internet right now. Forgotten test environments and old subdomains are a favourite starting point precisely because nobody is watching them.

Recovery. Not whether backups exist. Whether a restore has been performed, into a clean environment, and how long it took. An untested backup is a hope with a schedule attached.

The output should be a plan, not a list

A useful audit ends with a sequence: fix these three things this month, these five this quarter, and here is why in that order.

That ordering is the expensive part and it is what you are actually paying a human for. It requires understanding which findings compound, which are cheap to close, and which look alarming but are not reachable in practice.

A report that hands you two hundred items sorted by generic severity has moved the hardest work back to you.

What to ask before signing

Ask to see a redacted report from previous work. You are looking for three things: findings written in terms of the client's system rather than generic descriptions, a prioritised remediation plan rather than a sorted list, and an explicit statement of what was not tested.

That last one is a genuine quality signal. Every audit has boundaries. A report that pretends to have covered everything is either dishonest or the author did not think carefully about scope.

After the audit

The audit is a photograph. It describes one day.

What keeps it accurate is the continuous layer underneath: dependency scanning wired into your build, external surface monitoring, and access reviews on a schedule. Without those, you will need the same audit again in a year and it will find largely the same things. Most of that continuous layer is automated by definition, which is what makes it affordable to run between audits.

This is the shape our cybersecurity work takes, and where the findings point at how systems are built or operated rather than at a configuration, they usually belong with the development or infrastructure work rather than with a security tool.