“We need a security audit.” “Our insurer is asking for a vulnerability scan.” “This client requires a penetration test.” These three terms get used interchangeably. They describe three different exercises, answering three different questions, at three very different price points.

Key points

  • Scanning measures breadth, penetration testing proves depth, auditing structures governance.
  • Confusing the three often means paying for a “penetration test” that is really just an automated scan.
  • For an organization starting from scratch: audit first, fix the gaps, then test in depth.
  • The deliverable is what you’re actually buying: ask for a sample report before signing.

What is a vulnerability scan?

It’s a breadth exercise that answers “which known weaknesses exist on our systems?” An automated tool scans your assets and compares them against databases of known vulnerabilities. Fast, inexpensive, and repeatable at will, it’s the thermometer for your environment.

Its limits are structural: it detects but does not demonstrate. It produces false positives (flagged weaknesses that aren’t exploitable in your context) and false negatives, since it won’t catch flawed application logic, a chain of weaknesses, or a subtle misconfiguration.

A scan is an input to vulnerability management, not a security assessment on its own. This is the most common point of confusion, and the one that costs the most for the least value.

What is a penetration test?

It’s a depth exercise that answers “can a competent attacker actually compromise us, and how far can they get?” Within a strict legal and contractual framework, a professional reproduces the techniques of a real attacker: reconnaissance, exploitation, chaining weaknesses together, privilege escalation.

It follows documented methodologies: NIST SP 800-115 for the general approach, and the OWASP frameworks for web applications.

The value lies in the demonstration: not “this server has vulnerability X,” but “by exploiting X and then Y, we accessed your customer database, here is the proof, here is the path, and here is how to close it.” It’s the only exercise that answers the question your clients and your insurer are actually asking: what happens if someone really tries?

A useful point of vocabulary: scope is negotiable. External testing covers what an attacker on the internet can reach; internal testing covers what a compromised workstation or a malicious employee could do; application testing covers your transactional site or customer portal. Testing can run black box (no prior information), grey box (with a user account), or white box (with full documentation).

What is a security audit?

It’s the exercise that answers “are our practices and controls up to a recognized standard, and to our obligations?” It evaluates the organization as much as the technology: policies, access and offboarding management, backups, incident management, compliance.

Everything is measured against a framework: ISO 27001, the international standard for information security management; the NIST framework, organized by function (identify, protect, detect, respond, recover); CIS controls; or Law 25 requirements for the personal information component.

A useful distinction between the two main frameworks: ISO 27001 is certifiable, aimed at a documented, auditable management system, which large clients often require; the NIST framework is more flexible, well suited to structuring an SME’s progress without pursuing certification. The two map onto each other, and onto Law 25.

Which exercise fits which situation?

The table below answers the question as it actually comes up. The general logic for an organization starting from scratch: audit first, fix the gaps, then test in depth.

Your situation The right exercise Why
Never had your security assessed Audit or posture diagnostic Map the terrain before digging in: prioritizing avoids paying for a test that only confirms the obvious
Insurer or client questionnaire to fill out Targeted gap analysis Answer factually, identify blocking gaps, build the remediation plan
Transactional site or portal handling customer data Application penetration test Application logic can’t be scanned, it has to be tested manually
Exposed infrastructure (remote access, servers) External test followed by recurring scans Validate the perimeter the way an attacker sees it, then monitor continuously
After a major change (migration, merger, new management system) Targeted test on the new perimeter Every major change redistributes risk
Program already in place Annual test, monthly scans, periodic audit review Continuous breadth, periodic depth, verified governance

A penetration test on an environment that has never been assessed produces a damning but not very useful report: you already know it will fail. The test delivers its full value when it’s used to validate a level of security you believe you’ve already reached.

What should a good report contain?

Five elements, and their absence is the best warning sign. An executive summary in business language, demonstrated findings with proof, prioritized recommendations, an explicit scope and methodology, and a retest of critical fixes.

The deliverable is what you’re actually buying. Before signing, ask for a sample of an anonymized report.

  • An executive summary in business language: overall risk level, main findings, concrete impacts, readable by a board of directors and not just an IT specialist.
  • Demonstrated findings: for each exploited weakness, the proof, a severity rating, and the business impact in context. The same technical flaw doesn’t carry the same weight depending on whether it exposes your showcase website or your payroll database.
  • Prioritized, actionable recommendations, in a realistic implementation order, not a generic two-hundred-line list.
  • Explicit scope and methodology, frameworks followed, dates, limitations, so the exercise holds up with a client, an insurer, or an auditor.
  • A retest of critical fixes, either included or clearly priced.

The warning signs, conversely: a “penetration test” priced abnormally low whose deliverable is visibly the raw output of a tool; no named methodology; no executive summary; no proof of exploitation; or a provider unable to name the individual certifications of its own team members.

How do you justify the investment?

On four measurable fronts: access to contracts, cyber insurance, Law 25 compliance, and avoided cost. None of the four is abstract precaution.

1. Access to contracts. Large Quebec clients increasingly require proof of security posture from their suppliers: questionnaires, audit attestations, recent test reports. Being able to produce them has become a commercial qualification criterion; their absence, a silent disqualifier.

2. Cyber insurance. Underwriting questionnaires overlap directly with audit findings. A documented posture translates into coverage obtained, a controlled premium, and an uncontested claim.

3. Law 25 compliance. The law requires reasonable security measures. In the event of an incident, a documented audit and test record is tangible proof of your diligence; their absence, an aggravating factor before the Commission d’accès à l’information (Quebec’s access-to-information oversight body).

4. Avoided cost. Published estimates of the full cost of an attack on a Canadian SME vary widely depending on methodology; they’re worth checking at the source rather than relying on as a single figure. An annual assessment program represents a fraction of that cost, and it’s the difference between discovering your gaps in a report or in a ransom demand.

How does RISS conduct these exercises?

With a few firm principles, one of which is surprising: our first recommendation is sometimes not to run the exercise you asked for, if a prior diagnostic delivers more value for the same budget.

  • Certified practitioners and documented methodologies: the methodology’s name appears in the report, and the report stands up to comparison.
  • The right exercise, not the biggest one. Advice that starts by selling you the most expensive exercise isn’t advice.
  • Deliverables written for two audiences: an executive summary for leadership and the board, and reproducible technical detail for your team or your provider.
  • Compliance handled in a single effort: every finding is mapped simultaneously to Law 25, ISO 27001, and the NIST framework.
  • Retesting included on critical fixes: a report that sits in a drawer is a failure, ours as much as yours.

Scanning, penetration testing, auditing: three complementary tools, not three synonyms. An organization doesn’t need all three tomorrow; it needs to start with the one that answers its question right now, with a deliverable it can point to for a client, an insurer, or a regulator.

FAQ

How much does cybersecurity support cost?

No single rate can honestly be posted, because scope depends entirely on your context: number of users and sites, what your existing licenses already cover, applicable regulatory obligations, the real cost of an hour of downtime, the level of support you want, and what your clients and insurer require. Two companies of the same size receive very different proposals for these reasons, and the first conversation exists precisely to establish these variables.

Do we need to do everything at once?

No, and trying to is the surest way to finish nothing. The recommended approach is sequential: diagnose, fix the foundations, then validate with a technical exercise. Many organizations spread this across several budget cycles, addressing whatever reduces the most risk for the budget available each year.

Do you work with our current IT provider?

Yes, that’s the most common case. We are not a managed IT services provider and we’re not trying to replace yours: our role is analysis, advice, and oversight. Since we don’t resell licenses, we have no revenue tied to any product choice, which lets us assess what’s already in place and say when a contractual commitment is missing.

Sources