21 / 33Penetration Testing

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

Canadian penetration testing services with written scope, reproducible findings, and a retest after you fix.

Talk to an architectSee what's covered
  • CCIE Security-led testing team
  • Testing Canadian estates since 2021
  • Written rules of engagement, always
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. 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. 2

    The test

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

  3. 3

    Report and retest

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

THE PROOF

Built to last. Evidence over promises.

PCI DSS v4.0.1 asks for a retest after remediation, under 11.4.4. Most testing stops at the report.

IN PRODUCTION

Findings Canadian engineers could act on.

The last firm gave us a 90-page PDF with severity ratings and no way to reproduce anything, so our developers argued with it for a month instead of fixing it. SMEnode's report had the exact request that worked, pasted in, for every finding. We closed eleven of thirteen in two sprints and they came back and proved it.

SMEnode · Engineering principle
  • CCIE Data Center
  • CCIE Security
  • CCDE Design
  • Canadian data residency
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.
Zero-Trust vault
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.

  1. Step 01

    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. Step 02

    Test

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

  3. Step 03

    Report with reproduction

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

  4. Step 04

    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

Ready to build a stronger,
smarter network?

Explore our servicesBook a free consultation

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