A long findings list is easy to produce and easy to sell. It is also, on its own, close to worthless. A hundred low-severity items sorted by scanner category tells you what a tool noticed, not what would actually hurt you.
A useful audit answers four questions
- What is the worst thing that can happen to this system, and how would it happen?
- Which of those paths are currently open?
- What is the smallest change that closes each open path?
- What will you do differently so it does not reopen?
Everything else is supporting evidence. If a report does not let you answer those four in a paragraph, it has not reduced your risk — it has transferred a reading task to you.
Categories worth checking first
Access control and authority boundaries, because that is where real breaches live. Data-layer enforcement, because interface checks are not enforcement. Secret handling, because a leaked key is instant and total. Input validation on anything reachable without authentication. Privileged operations, which should be narrow, server-side and logged.
Severity is not a property of a finding. It is a property of a finding in your system, with your data, and your users.
Fix the category, not the instance
When an audit finds one endpoint missing a check, the finding is rarely one endpoint. The right response is to enumerate every sibling path that shares the assumption and close them in the same pass, then add the check to whatever gate stops the next one being written.
That is the difference between an audit that produces a document and an audit that produces a safer system.