Cybersecurity · Testing

Penetration Testing

A penetration test is an attempt to reach something valuable using the paths a real attacker would use. It differs from a vulnerability scan because the tester chains small weaknesses together — a service that should not be published, a password reused by an administrator, a share with looser permissions than anyone realised.

We scope and coordinate testing, then do the part that determines whether it was worth doing: turning the report into remediation and verifying the result.

Before you book a test

Testing rewards preparation

Testing an environment with no multi-factor authentication, unpatched internet-facing systems and shared administrative accounts produces an expensive report telling you what an assessment would have identified in a week. The value of a test is highest once the obvious controls are in place.

We are direct about this. If the basics are missing, we recommend fixing them first and testing afterwards, so the exercise reveals genuine architectural weaknesses rather than housekeeping.

Scope is the other decision. External-only testing answers what an internet-based attacker can reach; internal testing answers what a compromised laptop can do; identity testing answers what a stolen credential achieves in your Microsoft 365 tenant. Each answers a different question, and cost follows scope.

What we do

How we run a testing engagement

  1. 01

    Define the objective

    What we want to learn — whether client data is reachable, whether a compromised device can reach finance systems, whether the perimeter holds — expressed before tooling is chosen.

  2. 02

    Set rules of engagement

    Written scope, timing, excluded systems, escalation contacts and stop conditions, so nothing critical is disrupted and everyone knows the exercise is authorised.

  3. 03

    Coordinate the testing

    We work with qualified testers, provide the environment context they need, and monitor detection during the window — a test is also a live check of whether your monitoring notices.

  4. 04

    Translate the findings

    Each finding is restated as a business risk with an owner and a fix, separating genuine exposure from informational noise.

  5. 05

    Remediate in order

    We schedule and implement the fixes across identity, endpoints, network and application configuration, with change control.

  6. 06

    Retest and document

    Verification that each item is resolved, producing the closing evidence that clients, boards and insurers ask to see.

Common findings

What tests usually surface locally

  • Remote services exposed unnecessarily
  • Administrative accounts without MFA
  • Over-permissive internal file shares
  • Unsegmented networks
  • Outdated appliance firmware
  • Legacy authentication still permitted

Where this fits

Assurance work like this sits alongside the day-to-day controls described on our St. Catharines cybersecurity page.

Questions

Frequently asked questions

How often should we test?
Annually is a common baseline, plus after any significant change — a new office, a cloud migration, a new customer-facing application, or a merger. Continuous vulnerability management fills the gaps between tests.
Could testing break something?
Properly scoped testing is careful with production systems, and fragile equipment such as industrial controllers is excluded or handled in a controlled way. That is exactly what the rules of engagement document.
Do we need a test to satisfy our insurer?
Most insurers ask about controls rather than testing. Larger clients and regulated counterparties are more likely to ask for a test report, and some contracts require one.

Next step

Talk to Griffin IT Group about your St. Catharines IT environment

Tell us how your technology is set up today and what is getting in the way. We will walk through your environment, outline the gaps we see and recommend a practical path forward.