Penetration testing services that include the retest, not just the report

Trusted by

  • Broadcom
  • SSENSE
  • Mondou
  • Western University
  • Votatec
  • Ren's Pets
  • City of Mississauga
The work

Penetration testing services, three pillars, one operator.

One Canadian team agrees the scope, runs the test, and comes back after you've fixed it. Pen testing and ethical hacking are the same work under two names, and both belong to the engineer who has to explain the finding.

  1. Scope and authorisation

    Written rules of engagement, signed, naming what's in scope, what we won't touch, and which windows we work in.

  2. The test

    Network, web application, external and internal, run against a documented methodology rather than a scanner and a screenshot.

  3. Report and retest

    Findings your engineers can reproduce, then a second pass once the fixes land, so a closed finding is proven closed.

By industry

Does Penetration Testing work the same way in every industry?

No. The Penetration Testing work is the same craft in every sector, but the conditions around it are not. In financial services that means OSFI's technology and cyber risk rules; in government, Protected A, B and C data handling; and in defence and aerospace, controlled goods rules, CMMC and the flow-down from your prime. We keep the service and change the part that bends.

  • Testing at the cadence your regulator and your customers expect.

    OSFI B-13. Technology and cyber risk across three domains: governance, technology operations and resilience, and cyber security. It binds federally regulated institutions, and only those.

    • OSFI B-10
    • OSFI E-23
    • Provincial credit union regimes
    Financial services IT
  • Protected A, B and C data handling decides where the work can run and who can touch it.

    Protected A, B and C. Each level changes where the data can physically live, who can reach it, and what you have to prove about both. Most files turn on Protected B, and most disagreements turn on what counts as reaching it.

    • ITSG-33, and ITSP.10.033
    • CPCSC
    • PIPEDA and the Privacy Act
    Government IT services
  • Controlled goods rules, CMMC and the flow-down from your prime set what a supplier can do.

    ITAR and the Controlled Goods Program. Registration under the Defence Production Act is mandatory before anyone examines, possesses or transfers controlled goods in Canada. Technical data counts, so a drawing sitting on a laptop is in scope.

    • CMMC
    • NIST SP 800-171
    • CPCSC
    Defence and aerospace IT
  • Health information sits under provincial privacy law, and your IT provider is usually the custodian's agent.

    PHIPA. Ontario's health privacy act, with its own definition of a custodian and its own duties for the agents acting on a custodian's behalf. Your IT provider is usually an agent.

    • Provincial equivalents
    • PIPEDA
    • Breach notification
    Healthcare IT
  • Solicitor-client privilege decides how a firm can handle its data.

    Law Society obligations. Confidentiality and competence duties reach the technology you practise with, and the vendors who touch client information. The firm is expected to have assessed the provider, which means the provider should arrive with the answers.

    • Solicitor-client privilege
    • PIPEDA breach notification
    • Quebec Law 25
    Legal IT services
Request a consult

What do you need from Penetration Testing?

Tell us who you are and what you're working on. A senior engineer reads your message before replying, so the first answer is a real read on scope, risk and timing, within an hour, 24/7. Nothing here is a commitment, and we'll tell you plainly if we're not the right fit.

I agree to receive emails from SMEnode.

We use your details to reply to this message. You can unsubscribe from our emails at any time. Privacy

Your request

Service
Penetration Testing

What happens next

  1. A senior engineer replies within an hour, 24/7, never an SDR.
  2. We book a 30-minute call to listen, sketch options, and flag risks.
  3. You get a scoped statement of work within 3 business days.

Call the 24/7 line

+1 514-465-1584
The deep dive

Penetration testing in Canada, made real.

A test you can't reproduce isn't evidence. It's an invoice with severity ratings attached.

What good testing produces, and what your framework asks for.

Good testing produces two things: findings an engineer can reproduce without trusting you, and proof the fix worked. Most of this market delivers the first badly and skips the second entirely. Compliance is usually the trigger for Canadian buyers, so it's worth knowing what your framework asks for. PCI DSS v4.0.1 requires internal and external testing at least every 12 months and after any significant change, a documented methodology, segmentation testing, and remediation retesting under 11.4.4. Service providers test segmentation every six months, not twelve (source: PCI DSS v4.0.1, requirement 11.4).

Scope is where engagements go wrong, in both directions.

Too narrow and you buy a test of the one system you already trusted. Too broad and the days get spread so thin nothing gets tested properly. We write scope with you before quoting, name what we won't touch, and get it signed. That document is also your legal cover: testing systems without written authorisation is a criminal matter in Canada, not a technicality, and a reputable tester will insist on the paperwork before you do.

The report, and the retest the industry quietly bills for.

The other failure is the report. Severity scores without reproduction steps produce a month of argument between your developers and a PDF, which is how real findings die. Every finding we file carries the request, payload, or path that worked, so your team reproduces it in minutes and disputes nothing. Then we come back. The retest is what turns a finding into a fixed system, and charging separately for it is the industry's quiet habit.

Want a Senior IT Consultant's Read on Your Setup?

Tell us what you run today and what keeps breaking. A senior SMEnode engineer replies within an hour with a first read on scope, risk and timing. No sales handoff.

Request a consult
The method

How a network penetration test and web application pentest run.

Four steps, and step 01 is longer than clients expect. Scoping properly takes a conversation about what you're actually worried about, what's in production, what's behind which control, and which systems would hurt if we broke them. Skip that and you get a test of whatever was easiest to reach. We also agree the escalation path before starting, because occasionally a Canadian estate turns out to be compromised already, and nobody wants to be deciding who to call at that point.

Engagement phases

Phases 01 to 04

  1. Scope and authorise

    What's in, what's out, which windows, which contacts. Written rules of engagement, signed by someone in your Canadian entity who can sign them.

  2. Test

    External perimeter, internal network, web applications, against a documented methodology rather than a scanner and a screenshot.

  3. Report with reproduction

    Every finding carries the exact request or path that worked, ranked by what an attacker gains, not by raw score.

  4. Retest

    Once your fixes land, we test the same findings again and say plainly which are closed. That's what your auditor wants to see.

Questions

Penetration testing services questions, answered straight.

Answers first, including when a test is the wrong purchase. An architect takes the call, not a salesperson.

Days times rate, and the honest variable is scope. A focused external test of a small perimeter is a handful of days. An internal network test across multiple sites, plus two web applications with authenticated roles, is a different number entirely. Anyone quoting before scoping is guessing or selling you a scan. Ask what's excluded, whether the retest is included, and how many days are actually testing rather than reporting.

Yes, with written authorisation, and criminal without it. That's the whole reason the rules of engagement document exists. It names the systems, the windows, the techniques we'll use, and who signed. If you don't own the infrastructure, your cloud or hosting provider's terms may also apply. Any tester who doesn't ask for signed authorisation before starting is a liability, and you should treat that as disqualifying.

A scan lists what might be wrong. A test proves what is. Scanners are automated, run often, and produce long lists with false positives. A test is a person chaining findings together to reach something that matters, which is what an attacker does and what a scanner can't. You want both, at different frequencies, and you shouldn't pay testing rates for scanning work.

An executive summary, the findings ranked by what an attacker gains, and for each one the exact request, payload, or path that worked. Plus what we tried that failed, which tells you where your controls held. Remediation guidance is specific to your stack, not a link to a generic advisory. You get the retest results as a separate short document your auditor can file alongside it.

PCI DSS v4.0.1 asks for internal and external testing at least every 12 months and after any significant change, with segmentation testing every six months for service providers (PCI DSS v4.0.1, requirement 11.4). Outside PCI, annual plus after any material change is the pattern we recommend, with scanning between tests filling the gap.

When you already know the answer, because if nobody has patched in a year a test will just document that expensively. When you can't fix what we find, since findings nobody actions are a liability once they're written down. And when a scan would do, which is most of the time between annual tests. We'd rather scope you smaller and be right than sell days you don't need.

Let's connect

A senior SMEnode engineer replies within an hour, 24/7.