Repère Security Guides Reading an audit report
Reading an audit report, and deciding where to start
Receiving a report and knowing what to do with it are two different things. Here is how a finding reads, what a severity scale actually says, and how to choose when the whole list looks urgent.
The anatomy of a finding
A finding you can act on answers three questions, in this order. If one is missing, the report has left you interpretation work it should have done itself.
-
What it is
A description of what was observed, in plain language, and the evidence of the observation. Not “non-compliant configuration”, but what was seen and where.
-
What it means
The concrete consequence for your site. This is the part that separates a finding from a line of tool output: it requires knowing the context.
-
What to do
A remediation a developer can apply as written. Not a general recommendation, but the specific action to take.
External references often come with it: a public vulnerability identifier where one exists, or the weakness category the finding belongs to. Those are for your developer, not for you. You do not need to understand them to decide.
What severity says
Reports usually rank findings on a scale running from critical to informational. Many rely on CVSS, a standardized vulnerability scoring system that produces a score from technical criteria.
It is worth knowing what that score measures and what it does not. It rates the characteristics of the weakness: how easy it is to exploit, what privileges are needed, the technical impact. It ignores what is at stake for you.
A weakness rated high on a newsletter signup form and the same one on a client area holding patient files carry the same score and nothing like the same urgency. You are the one who supplies that information, and a well-made report asks for it rather than assuming.
Worth remembering
Technical severity is a starting point, not a work order. The work order is built by crossing severity with what the data in question represents for your business.
Choosing when everything looks urgent
A first report often contains more findings than you can handle at once. Three questions settle it, in this order.
What is reachable from outside?
A weakness exploitable with no prior access is not comparable to one that already assumes an account. The first is open to anyone, the second to a small circle.
What touches people's data?
Customer records, contact details, purchase histories. Beyond the risk, that data carries obligations: in Quebec, Law 25 requires security measures proportionate to its sensitivity. Anything touching it moves up the list.
What can be fixed in an hour?
Some findings need a rebuild, others a setting. Handling the quick ones first is not laziness: it is reducing the number of open doors while the long work is being prepared.
There is a fourth question people forget: what will come back? A component you removed does not return. An account you closed can be reopened by someone who does not know why it was closed. The second fix needs a change of habit, not only a technical action.
Following it over time
A report is not a document you read once. Every finding moves through states: open when it is raised, acknowledged when you have taken it in, fixed when the action has been taken and verified.
Two other states matter just as much. Accepted describes a finding you choose not to address, because the fix would cost more than the risk. That is a legitimate decision, provided it is written down. False positive describes a flag that was not a problem in your context.
A report whose findings are all still “open” six months later has not served its purpose. That is not a tooling question, it is a question of who is responsible: someone has to keep the list.
Who to share it with
The report is yours. You can give it to your developer, to a prime contractor who requires it before signing, to a client larger than you, or to an insurer.
One precaution: an audit report describes weaknesses. Until they are fixed, it is a document to circulate with judgement. Send it to whoever has to act, rather than attaching it to a general email.
And one limit worth knowing: a report is not a certification. It records a state, on a date, within a given scope. Nobody can conclude from it that a site is safe six months later.
At Repère, every finding is reviewed by a person before it reaches you, and the remediation can become a second mandate if you would rather not carry it yourself. The report stays written so that any competent developer can apply it: see how an audit runs.