Pen testing

What penetration testing is — and what it is not

Penetration testing is the practice of simulating a real-world attack on your IT environment under a controlled, legally authorized agreement. A qualified tester — or a small team — attempts to breach your defences using the same tools, techniques, and procedures a malicious actor would use, within a defined scope and time window. The goal is not to cause harm but to generate evidence: proof that specific vulnerabilities are reachable and exploitable, documentation of what an attacker could access once inside, and a clear risk-ranked list of findings with actionable remediation steps.

What penetration testing is not: it is not a vulnerability scan alone (a scanner identifies and classifies known CVEs automatically; a pen tester validates whether they are exploitable and what the chain of access looks like), not a security assessment (which evaluates your security program against a framework through interviews and documentation review — a separate but complementary exercise), and not a compliance certification. Passing a pen test does not grant a certificate. It generates evidence that supports compliance with SOC 2, PCI-DSS, PIPEDA, and cyber insurance requirements — but the compliance conclusion is made by your auditor or insurer, not your tester.

The critical distinction from a security assessment: an assessment evaluates your program at a program level. A pen test actively attacks specific technical targets. The CIRA Cybersecurity Survey 2024 found that while 46% of Canadian organizations experienced an incident in the prior twelve months, fewer than one-in-three could confirm they had run a professional penetration test in the preceding two years. That gap matters because many organizations have invested in controls that are misconfigured, partially deployed, or vulnerable to specific attack chains that only active testing reveals.

The value a pen test provides that no automated tool replicates is chaining: an unpatched VPN gateway provides initial access; flat network segmentation allows a pivot from one workstation directly to the domain controller; a forgotten service account with Domain Admin rights — created for a vendor integration two years ago and never decommissioned — is the final escalation. Each finding is medium severity in a scanner report. Together, they yield full active directory access from a single phishing email. Only manual testing reveals the chain.

Vulnerability assessment vs penetration test: choosing the right engagement

The terms vulnerability assessment and penetration test are used interchangeably in many vendor proposals — a confusion that costs Canadian businesses money spent on the wrong engagement or a false sense of assurance from an incomplete one.

A vulnerability assessment uses automated scanning tools — Nessus Professional, Qualys, Tenable.io, Rapid7 InsightVM — to inventory your systems, match software versions against known CVE databases, and output a severity-ranked list. Scan time for a typical SMB environment is measured in hours; report turnaround is 1–3 days. The output is a CVE list with CVSS scores and vendor patch references.

What a vulnerability assessment does not do: it does not verify whether a finding is exploitable in your specific configuration; it does not chain multiple findings into an attack path; and it does not test your people or your application logic (IDOR, authentication bypass, SSRF — vulnerabilities not catalogued in a CVE database). A CA$1,500 scan may surface 200 findings; a pen test on the same environment may find that 4 of them chained together provide full domain administrator access.

The practical sequencing for most Canadian SMBs: start with a cybersecurity risk assessment to establish your baseline and address Critical and High gaps, add quarterly automated vulnerability scans for ongoing patch visibility, then commission a pen test once core controls are in place. This avoids commissioning a CA$12,000 pen test on an environment so poorly controlled that the tester achieves full access in 90 minutes — a result any CA$2,500 assessment would have predicted.

Why Canadian SMBs cannot defer penetration testing

Four distinct pressures are converging to make penetration testing a near-requirement for Canadian businesses of all sizes in 2026, even those below the traditional enterprise threshold where pen tests were historically common.

Cyber insurance underwriter requirements: The Canadian market — Intact Financial, Aviva Canada, Northbridge, Zurich Canada — has shifted from questionnaire-based underwriting to technical validation since 2021. Several insurers now require evidence of annual penetration testing as a condition for issuing or renewing policies at competitive rates. A business that cannot demonstrate active testing may face excluded attack vectors, higher self-insured retentions, or premium increases of 15–40% versus an equivalent business with testing evidence.

SOC 2 demand from enterprise clients: Canadian SaaS providers, technology companies, and MSPs increasingly face SOC 2 Type II requests from US-based enterprise clients. Auditors mapping to the Common Criteria for logical access consistently expect annual testing evidence or a formally documented compensating control. Missing it creates pipeline friction with enterprise prospects regardless of your actual security posture.

PIPEDA and Quebec Law 25 due diligence: Both require safeguards appropriate to the sensitivity of personal information. The OPC at priv.gc.ca and Quebec's CAI have established through breach investigations that "appropriate safeguards" for organizations handling SINs, financial records, or health information includes active technical control testing. Organizations without recent testing history face harder scrutiny when a breach triggers regulatory inquiry.

Supply-chain and contractual pressure: The Canadian Centre for Cyber Security (CCCS/CSE) guidance at cyber.gc.ca recommends penetration testing as part of a mature security program, referenced in federal procurement language. Private-sector supply chains are following: deferring testing creates eligibility risk with enterprise clients who make vendor security evidence a contract condition.

Test types: black box, grey box, and white box explained

Every penetration test begins with a decision about how much information the tester starts with. This determines both the simulation fidelity and the cost efficiency of the engagement. Each model has legitimate use cases; the right choice depends on what threat scenario you are testing against and how mature your security program is.

Black box testing simulates an external attacker with no prior knowledge of your environment. The tester begins with only your organization name or IP range and must conduct full reconnaissance — identifying systems, discovering the technology stack, enumerating attack surface — before attempting exploitation. Black box most accurately simulates an opportunistic, unknown external attacker. The limitation: testers spend a significant portion of the engagement on reconnaissance that an internal team could shortcut, which makes black box the most expensive approach per unit of vulnerability coverage. For most Canadian SMBs, black box is appropriate for annual external network tests where simulating a real external adversary is the primary goal.

Grey box testing is the most common and cost-effective model for Canadian SMBs. The tester receives limited prior knowledge — typically valid user credentials (representing a compromised employee account, a contractor, or a phishing victim who clicked a link), basic network documentation, and possibly application login access. This eliminates the reconnaissance overhead while still requiring the tester to discover and exploit internal vulnerabilities without privileged access. Grey box most accurately simulates the threat that drives the majority of Canadian SMB breaches: a credential-harvesting phishing attack that compromises one employee account, from which an attacker moves laterally. It delivers more findings per testing day than black box, making it more cost-efficient for organizations with limited budgets.

White box testing provides the tester with complete environment access: network diagrams, system documentation, source code (for web application tests), full administrative credentials, and a map of all systems in scope. The goal is maximum coverage — finding as many exploitable vulnerabilities as possible — rather than simulation of a specific threat scenario. White box is most appropriate for software companies testing a new application before launch, for organizations that have already completed multiple black and grey box tests and want the highest-coverage technical deep dive, and for compliance-driven tests requiring proof that a specific code base has been reviewed at source level.

Red team operations combine physical access, social engineering, network exploitation, and persistence into multi-week adversary simulations — testing detection and response, not just preventive controls. Engagements start at CA$25,000 and are appropriate only for organizations with a mature security operations function. Most Canadian SMBs should begin with a grey box network test.

Scope: network, web application, and social engineering

The three primary penetration test scopes address different attack surfaces. Most Canadian SMBs begin with one or two; a comprehensive test covering all three is typical for organizations with higher risk profiles (SaaS providers, healthcare practices, law firms, financial advisory firms).

External network penetration test: The most common starting point. The tester attacks your internet-facing systems from outside — firewalls, VPN gateways, remote desktop services, email infrastructure, DNS, and cloud assets. Common findings in Canadian SMB external tests include: exposed RDP without MFA or IP whitelisting (a persistent top finding since the COVID remote-work expansion), VPN concentrators running unpatched firmware, and cloud storage (Azure, AWS, GCP) with overly permissive access rules. External tests for a 10–50 user SMB take 3–5 days of active testing.

Internal network penetration test: Simulates an attacker who has already gained initial access — a phishing victim, a compromised contractor, or a threat actor who purchased stolen credentials on a dark web market. The tester is placed on your internal network (physically on-site or via VPN connection) with low-privilege or no credentials and attempts to escalate privileges, move laterally, and access sensitive data or critical systems. Internal tests consistently surface the highest-impact findings in Canadian SMB environments: Active Directory misconfigurations (Kerberoasting, AS-REP roasting, unconstrained delegation), lateral movement via over-provisioned service accounts, clear-text credentials in network shares or management systems, and flat network architecture that allows direct workstation-to-server communication with no micro-segmentation.

Web application penetration test: A manual test of a specific web application — your client portal, SaaS product, internal business application, e-commerce platform, or customer-facing API — against the OWASP Top 10 and beyond. Unlike automated web application scanners, a manual tester validates authentication bypass opportunities, tests for insecure direct object references (IDOR — the ability to access another user's data by manipulating URL parameters), business logic flaws, API authorization failures, and injection vulnerabilities that context-dependent automated scanning misses. Canadian software companies seeking SOC 2 Type II or approaching enterprise prospects typically begin their pen testing program with a web application test on their primary product.

Social engineering / phishing simulation: Tests your employees' ability to recognize and resist phishing, vishing (voice phishing), and physical social engineering attempts. A typical engagement includes a targeted spear-phishing campaign (custom-crafted emails impersonating a vendor, internal sender, or delivery service, with a credential-harvesting landing page or malware payload link), plus optionally a vishing call campaign and a physical access attempt (tailgating into a secured area, connecting a USB device). Social engineering tests are particularly valuable for organizations whose training programs have not been validated in practice. Findings are presented as click rates, credential submission rates, and a narrative of the most successful techniques used — valuable data for targeting your security awareness training investment.

For most Canadian SMBs, start with an external plus internal grey box network test — this covers the two most common attack paths and gives the broadest risk picture per dollar. Add a web application test if you run a customer-facing application, and social engineering if your phishing training has never been validated in practice.

The penetration testing methodology: from kick-off to report

A professional penetration test follows a structured, reproducible methodology. Here is the sequence for a standard grey box external plus internal network engagement:

1. Scoping and rules of engagement (1–2 hours, typically free): The tester confirms the in-scope systems (IP ranges, domain names, specific applications), explicitly excluded systems (production databases that cannot tolerate disruption, third-party systems outside your control), and rules of engagement (hours during which active testing is permitted, who to contact if a critical vulnerability is discovered, what to do if the tester achieves domain administrator access mid-engagement). You receive a written Statement of Work with a fixed price and signed authorization before any testing begins. Never allow testing without a signed authorization document — it is the legal instrument that distinguishes an authorized pen test from a criminal offence under Canada's Criminal Code s.342.1 (unauthorized use of a computer).
2. Passive reconnaissance (1–2 days for external tests): The tester gathers publicly available information about your organization using open-source intelligence (OSINT) techniques — LinkedIn profiles for technology stack clues, Shodan and Censys for exposed services, WHOIS and DNS records for infrastructure mapping, certificate transparency logs for subdomain enumeration, GitHub for leaked credentials or internal documentation, and breach databases for previously exposed employee credentials. Passive reconnaissance is non-intrusive and leaves no footprint on your systems.
3. Active scanning (0.5–1 day): Port scanning, service enumeration, and vulnerability scanning with tools such as Nessus, Burp Suite Pro, and Metasploit Framework. Coordinate with your IT team or MSP to prevent false-positive incident responses from your security monitoring.
4. Exploitation (1–3 days): The tester actively exploits discovered vulnerabilities — going beyond flagging that CVE-5678 exists to proving it is exploitable on your specific system version and configuration. Each attempt is documented with screenshots, command output, and timestamps. The tester records what data was accessible at each stage — not to extract it but to prove what a real attacker could reach.
5. Post-exploitation and lateral movement (1–2 days, internal tests): From initial access — exploited externally or via grey box credentials — the tester escalates privileges, moves laterally, and demonstrates reach to domain controllers, file servers, and accounting systems. This phase frequently reveals that the highest risk in a Canadian SMB environment is not the initial vulnerability but flat network architecture and over-privileged accounts that allow unrestricted movement once any single system is compromised.
6. Report writing (3–5 days): The tester consolidates all findings into a structured report reviewed by a second assessor before delivery. Each finding includes a title, CVSS severity rating, technical description, proof-of-concept evidence, business impact statement, and specific remediation guidance.
7. Debrief and retest offer: A 60–90 minute debrief walks your team through findings and remediation priorities. A credible firm includes a partial retest — typically at no additional charge — to validate that Critical and High findings are genuinely closed within 60–90 days of delivery.

Penetration testing pricing in Canada (2026)

Canadian penetration testing pricing varies substantially by scope, methodology, tester experience, and firm type. The table below covers market rates for professional, evidence-based penetration tests from qualified security firms in Canada. All figures are in Canadian dollars, before HST/GST, and exclude post-test remediation work.

Price drivers in the Canadian market: tester seniority (OSCP/OSCE3-certified senior testers command higher day rates than junior analysts), firm overhead (boutique Canadian security firms are generally cheaper than multinational consultancies for equivalent quality), scope complexity (multi-cloud environments, legacy systems, and custom applications add time), and report quality (a CA$4,000 engagement that produces a 6-page scan export is not equivalent to one that produces a 60-page evidence-based report with a business-impact-mapped remediation roadmap). Always ask to see a redacted sample report before signing a statement of work.

Many managed IT providers in Canada bundle an annual vulnerability assessment into their managed services agreement. Professional penetration testing is typically quoted separately — it requires specialized expertise and a different authorization and liability framework than ongoing managed services. If your MSP claims to include a full penetration test in your monthly agreement at no additional cost, clarify exactly what methodology, scope, and deliverables are included. See our Managed IT Services guide for what a well-structured MSP agreement actually covers.

Penetration test vs vulnerability assessment vs security assessment: full comparison

Penetration test deliverables: what a credible report contains

A professional penetration test report is the primary artifact you will use to drive remediation, satisfy compliance requirements, and demonstrate due diligence to your insurer or enterprise prospects. A report that fails to include specific sections is either incomplete or was generated by automated tooling and relabelled as a pen test. Use this checklist to evaluate what you receive.

• Executive summary (1–2 pages, non-technical): Written for the business owner or board. States the overall risk posture (Critical/High/Medium/Low overall rating), the number of findings at each severity level, the most dangerous attack path demonstrated, and the headline remediation investment required. If your CFO cannot read this section and immediately understand the business exposure, the firm wrote it for the wrong audience.
• Scope and methodology section: Documents exactly what was tested (IP ranges, domain names, application URLs, test type), what was excluded, the methodology (PTES, OWASP Testing Guide, NIST SP 800-115), test window dates, and tools used. SOC 2 auditors and cyber insurance underwriters review this section — it must be complete and specific, not boilerplate.
• Finding-by-finding technical section: Each finding includes a title, CVSS severity score, technical description, affected system and version, numbered exploitation steps, proof-of-concept evidence (terminal output or HTTP captures), a business impact statement, and a specific remediation recommendation — not generic ("update Apache to 2.4.59", not "keep systems patched").
• Attack path narrative: Where multiple findings were chained together, a narrative section tells the story of the full attack sequence — starting point, each pivot, and the access ultimately achieved. This section communicates the compounded risk of individually medium-severity findings in a way a flat finding list never does, and is typically the most effective motivator for remediation investment at the owner level.
• Prioritized remediation roadmap: A table with columns for finding name, severity, affected system, recommended remediation action, estimated effort in days, estimated remediation cost in Canadian dollars, responsible party, and target date. Importable into a project tracker. Critical and High findings should have 30-day target completion dates; Medium findings 60–90 days.
• Retest offer: A credible firm includes a partial retest commitment — typically validation of Critical and High findings within 60–90 days of report delivery at a fixed fee or included in the original scope. Retesting is the only way to confirm that a remediation action actually closed the vulnerability as intended, not just addressed the surface symptom.
• Technical appendix: Raw tool output, full screenshots, all commands run with timestamps, and a vulnerability reference table mapping findings to CVEs, OWASP identifiers, or CWE numbers. Required for cyber insurance claims, regulatory responses, and legal proceedings where the chain of evidence matters.

Compliance drivers: SOC 2, PIPEDA, cyber insurance, and Law 25

What each framework actually requires determines how your test should be scoped and what the report must include.

SOC 2 (AICPA Trust Services Criteria): SOC 2 does not list penetration testing as a named requirement, but the Common Criteria for Logical and Physical Access (CC6.x) require evidence that vulnerabilities are identified and addressed. In practice, SOC 2 Type II auditors expect to see annual pen test results or a documented compensating control. Enterprise clients reviewing your SOC 2 report will look for testing evidence — its absence weakens your report even if no single criterion mandates it by name.

PIPEDA (federal): Principle 7 requires safeguards appropriate to data sensitivity. The OPC at priv.gc.ca interprets this to require technical control testing for organizations handling sensitive personal data. Under the Breach of Security Safeguards Regulations, an organization that suffered a breach and cannot demonstrate regular control testing faces a difficult position in any OPC investigation. A pen test report with remediation evidence is the most credible technical safeguard documentation available.

Quebec Law 25: Fully operative since September 2024, Law 25 requires safeguards proportionate to data sensitivity and a Privacy Impact Assessment for projects involving personal information. The CAI can levy penalties up to CA$10 million or 2% of global turnover. See our Law 25 compliance guide for the full obligation set. Penetration test evidence directly supports both the security safeguard requirement and any CAI inquiry defence.

Cyber insurance underwriting: Canadian insurers increasingly require evidence of active testing at renewal. The controls most commonly asked about — MFA on privileged accounts, EDR on all workstations, tested offline backups, DMARC — overlap directly with pen test finding categories. A signed report from a qualified firm is the evidence insurers accept, and some provide a 5–15% premium discount for clients who produce current (within 12 months) results with remediation evidence.

PCI-DSS 4.0: Requirement 11.4 explicitly mandates annual penetration testing of the cardholder data environment (CDE) covering external and internal networks, application layer, and segmentation controls. If PCI-DSS applies to your environment, confirm your tester's PCI-DSS experience and whether they hold Approved Scanning Vendor (ASV) or Qualified Security Assessor (QSA) credentials.

Case study: 35-person law firm in Toronto

The following composite is anonymized from real Canadian SMB penetration test engagements.

A 35-employee litigation firm with offices in Toronto and Ottawa had completed a cybersecurity risk assessment 14 months prior and addressed its Critical findings (MFA rollout, RDP lockdown, backup validation). The partners elected to commission a grey box external plus internal network penetration test at CA$8,500 to validate whether their remediation program had actually closed the previously identified risks and to satisfy a new cyber insurance renewal requirement from their underwriter.

The tester began with external reconnaissance and identified three internet-facing assets — the firm's email gateway (Microsoft 365 managed), a legacy case management system with a web interface accessible via HTTPS, and a client file-exchange portal. The legacy case management system was running an outdated TLS configuration (TLS 1.0 still permitted alongside TLS 1.2), which was flagged as a Medium finding — insufficient for exploitation alone but noted for remediation.

Internal grey box testing, starting from a standard user account, produced the following findings:

• Critical: A service account named svc_backup_legacy — created during a server migration four years earlier and never decommissioned — held Domain Admin membership. The account had a weak password (eight characters, no complexity) and was not protected by MFA. Kerberoasting the service account using freely available tooling yielded the password hash in 12 minutes on a standard GPU; the tester cracked it offline in approximately 40 minutes. From that account, full domain administrator access was achieved within three hours of beginning internal testing.
• High: The client file-exchange portal, while using valid TLS, was vulnerable to an Insecure Direct Object Reference (IDOR) flaw: by incrementing a numeric client matter ID in the URL, the tester accessed file listings for other clients' matters — including opposing counsel files from active litigation — without authentication. This was a business logic flaw invisible to automated scanning.
• Medium (three findings): SMB signing was not enforced on internal hosts, enabling potential NTLM relay attacks; printer servers were running outdated firmware with a known remote code execution vulnerability; and one laptop used by a partner running macOS had full disk encryption disabled.

The remediation sprint took 18 business days: svc_backup_legacy was disabled within four hours of the debrief; the IDOR flaw was patched within two weeks; SMB signing and printer firmware were addressed within one week; and the macOS laptop was encrypted within 24 hours. Total MSP remediation effort: approximately CA$3,200. The insurance underwriter renewed the policy at a 9% premium reduction upon receiving the test report and remediation evidence — partially offsetting the CA$8,500 engagement cost. For organizations that want testing and remediation under one engagement, IT Cares pairs penetration test findings with hands-on technical remediation across Canada, eliminating the gap between report delivery and vulnerabilities being closed.

Checklist: what to verify before signing a pen test scope of work

Use this checklist before committing to any penetration testing engagement to ensure you are getting what you need.

• Written, signed authorization document before any testing begins (Criminal Code s.342.1 protection)
• Tester credentials confirmed in writing: OSCP (Offensive Security Certified Professional) or equivalent for network tests; OSWE or eWPT for web application tests; GPEN (GIAC Penetration Tester) or CEH as supplementary
• Fixed price in Canadian dollars confirmed in the Statement of Work (not hourly estimates with open-ended scope)
• All in-scope and explicitly out-of-scope systems listed with IP ranges or domain names
• Testing window confirmed (hours, days, date range) and agreed with your IT team or MSP
• Emergency contact protocol documented: what happens if tester discovers active compromise by a third party mid-engagement?
• Data handling agreement: how is captured evidence (screenshots, credentials encountered) stored and destroyed post-engagement?
• Deliverables confirmed: executive summary, finding-by-finding technical section, attack path narrative, remediation roadmap, technical appendix
• Retest provision confirmed: Critical and High findings retested within 60–90 days
• Compliance mapping confirmed if required: SOC 2, PCI-DSS, PIPEDA, Law 25
• Redacted sample report reviewed before engagement signature

What to look for when hiring a Canadian penetration tester

The Canadian cybersecurity consulting market includes certified ethical hackers with deep methodology and a track record, boutique red teams with specialized industry expertise, and generalist IT firms that offer "pen testing" as an add-on service with limited specialized tooling or methodology. The distinction matters enormously for the value of the report you receive. Here is how to evaluate proposals:

Technical certifications: OSCP (Offensive Security Certified Professional) is the hands-on industry baseline for network testing — ask for the tester's certificate number and verify it directly with Offensive Security. OSWE or GWAPT indicate web application expertise. CEH is the most widely advertised credential in Canada but is knowledge-based, not practical — it does not prove exploitation skill the way OSCP does.

Canadian regulatory knowledge: The tester should know PIPEDA's Breach of Security Safeguards Regulations, the Law 25 CAI penalty structure, and how engagement deliverables support compliance documentation. If they cannot explain how a pen test report supports a PIPEDA Principle 7 defence, your report will lack the context needed for regulatory or insurance use.

Industry experience: Law firms, healthcare practices, and technology companies have distinct attack profiles and regulatory overlays. Ask for two or three Canadian client references at comparable size and industry — and call them.

Evidence-based methodology: Ask whether the firm uses manual exploitation or primarily automated tooling. Request a redacted sample report from a prior SMB engagement. A genuine manual pen test report contains screenshots of interactive terminal sessions, HTTP intercepts, and numbered exploitation narratives. A formatted Nessus export with a custom cover page is a vulnerability assessment at pen test pricing.

Five mistakes that undermine a penetration test's value

1. Testing before fixing known critical gaps. A pen test on a network where the security assessment found RDP exposed without MFA, default credentials on network devices, and no patch management will produce a report that confirms those gaps — at ten times the cost of the assessment. Fix Critical and High assessment findings first. Test when you want to validate your remediation, not diagnose your starting point.
2. Scoping too narrowly to reduce cost. Excluding the internal network from a network pen test because "we trust our employees" produces a report that validates only your external posture — and misses the lateral movement risk that is the primary threat in most Canadian SMB breaches. A grey box internal test covering the most common post-compromise attack paths (lateral movement, privilege escalation, domain controller access) is where most businesses get the highest-value findings per dollar. Do not exclude it to save CA$1,500 on the scope.
3. No retest of Critical findings. A pen test report without a confirmed retest is an incomplete engagement. Without retesting, you have no verification that the patch, configuration change, or compensating control you applied actually closed the vulnerability. Some remediation steps close the specific CVE but leave the system vulnerable to a related exploit variant. A retest — typically 4–8 hours for Critical and High findings — provides that confirmation.
4. Filing the report without acting on it. A pen test report filed in a shared drive and never referenced again is worse than no test. It creates a documented record that you knew about specific exploitable vulnerabilities and chose not to remediate them — a damaging exhibit in any OPC investigation, CAI audit, or litigation following a breach. Build the remediation roadmap directly into your quarterly IT review or MSP QBR agenda. Track completion with evidence.
5. Treating annual testing as a checkbox, not a program. Your environment changes: new applications are deployed, staff change, cloud services are added, vendors are onboarded. A pen test reflects your security posture as of the test date. Schedule a repeat engagement annually — or sooner after a significant infrastructure change — and track progress against the prior-year baseline. The second engagement is always faster and cheaper because most prior-year findings are resolved and the tester already understands your environment architecture.

Related guides

Build a complete security program with these TechCare Canada resources:

• Cybersecurity risk assessment for Canadian SMBs — the evidence-based baseline assessment that should precede a pen test
• Small business cybersecurity hub — the full guide to security controls for Canadian SMBs, from MFA to incident response
• Quebec Law 25 & PIPEDA compliance — privacy obligations for Canadian businesses by province and industry
• Backup & disaster recovery — tested offline backup is the primary ransomware recovery control and a pen test finding in most environments that lack it
• Managed IT services Canada — what a quality MSP agreement includes for ongoing security monitoring and patch management between annual tests

Frequently asked questions