Repère Security Guides Audit, scan or penetration test
Audit, scan or penetration test: which one do you need?
Three different pieces of work, often sold under interchangeable names. They do not look for the same thing, do not cost the same time, and do not answer the same need. Here is how to recognize yours.
The short answer
Worth remembering
A scan looks for known weaknesses, automatically, and hands you a list. An audit examines a defined scope and hands you findings that have been interpreted and prioritized. A penetration test tries to actually exploit weaknesses, to show how far someone could get.
The first answers “what is already known?”, the second “what matters here, on my site?”, the third “how far can someone go?”.
The vulnerability scan
A tool walks the site and compares what it finds against a database of catalogued weaknesses. It spots outdated versions, missing settings, badly configured certificates. It is fast, often free, and a reasonable starting point.
Its limits come from its nature. A scanner only knows what has already been catalogued: it will not see an over-permissive access rule specific to your site, because no database can know who is allowed to see what at your company. It also does not understand the logic of your business: a quote form that accepts a negative amount is a problem for you, not a catalogued vulnerability.
It also produces false positives: flags that are not problems in your context. Sorting them requires knowing the site, which is precisely the work a scan does not do.
Finally, raw scanner output is hard for an owner to act on. It is a technical list, with no useful hierarchy and no indication of what to handle first.
The security audit
An audit starts from a defined scope and works through it methodically. It can use tools, but the substance is the interpretation: what does this finding mean for this site, how serious is it, and where should you start.
A serious audit refers to recognized categories. The OWASP Top 10 groups the main families of web application weaknesses, and it is widely used to structure this kind of examination.
What separates an audit from a scan is not the tool, it is the judgement. A finding with no context helps nobody. A finding placed back inside your site, with what it implies and what to do about it, becomes work someone can act on.
The penetration test
A penetration test, or pentest, goes further: it tries to actually exploit weaknesses, chain them together, and demonstrate what an attacker could obtain. It is a simulated attack, framed and authorized.
It answers a question neither a scan nor an audit asks: is this exploitable, and how far does it go? That is what some prime contractors require, what some sector frameworks require, and what some organizations want before a sensitive launch.
It needs a heavier frame, more time, and a budget of a different order. For many small businesses whose site is a brochure or a small store, it is out of proportion. For others, it is exactly the right thing.
Choosing
| Scan | Audit | Penetration test | |
|---|---|---|---|
| The question asked | What is already known? | What matters here? | How far can someone get? |
| What drives it | A tool | A person, with tools | A person, working offensively |
| Interpretation | None | Central | Central |
| False positives | Frequent, unsorted | Sorted | Ruled out by proof |
| Deliverable | A list | Prioritized findings | Demonstrated scenarios |
| Authorization | Required as soon as a site is contacted | Written scope | Detailed mandate, often stricter |
| Good when… | You want a first signal | You want to know what to fix | You have to prove exploitability |
One remark holds for all three: contacting a site you do not own requires authorization, whatever the depth. A free tool pointed at someone else's address is not harmless just because it is automatic.
Where Repère sits
Repère does audits. Here, the scope and the authorization are put in writing before any check that goes beyond observing what is already public: the authorization names what may be examined, what is excluded, the permitted checks, the limits and the validity period.
We do not do penetration testing in the sense this guide uses. If that is what you need, we will tell you rather than sell you something else, and there are teams in Canada who do exactly that work.
We do not do incident response either. If your site is compromised right now, an audit is not the right move.
Once the audit has happened, Repère can turn the findings into fixes under a second mandate. That is a possible next step, never an obligation: the report is written to be applied by your own developer.