Security assurance
Penetration Testing for Oakville Organisations
A penetration test answers one question that no scan or review can: given what exists today, can an attacker actually get in, and how far can they go once they do?
At a glance
- Performed only under written authorisation
- Defined scope, exclusions and testing windows
- Evidence-based findings with reproduction steps
- Remediation guidance and retesting included
Authorisation comes before anything else
No testing begins without signed written authorisation from someone with authority to grant it. That document names the systems in scope, the systems explicitly excluded, the testing window, the techniques permitted, the emergency contacts on both sides, and the conditions under which testing stops immediately.
Where systems are hosted by a third party — a cloud provider, a SaaS vendor, a data centre — their own authorisation requirements must be satisfied before those assets can be included. Testing infrastructure you do not own or have permission to test is unlawful, and we will not proceed on a verbal assurance.
- Written authorisation from an authorised signatory
- Explicit in-scope and out-of-scope asset lists
- Agreed testing windows and blackout periods
- Third-party hosting authorisation where required
- Named emergency contacts and a stop-testing trigger
Rules of engagement
Rules of engagement set the boundaries of realistic testing. They cover whether social engineering is included, whether denial-of-service techniques are permitted (usually not), how discovered credentials may be used, what happens if evidence of a pre-existing compromise is found, and how sensitive data encountered during testing is handled and destroyed.
They also define the testing perspective: unauthenticated external testing, authenticated testing from a standard user account, or an assumed-breach scenario starting from a compromised workstation. Each answers a different question, and the most valuable is often authenticated testing — because that is the position most real attackers reach quickly.
- External, internal, authenticated or assumed-breach perspective
- Data handling and secure destruction requirements
- Escalation procedure if a live compromise is discovered
- Restrictions on disruptive techniques
What testing typically covers
External testing examines the internet-facing surface: published services, remote access, VPN and firewall interfaces, web applications, mail security configuration and exposed administrative interfaces. Internal testing examines what an attacker with a foothold can reach — segmentation, credential exposure, privilege escalation paths and lateral movement toward high-value systems.
Cloud and identity testing has become the most consequential area for organisations that have moved most workloads to Microsoft 365 or Azure. Conditional access gaps, over-permissioned applications, consent grants and token handling are examined because that is where realistic attack paths now run.
- External network and service testing
- Web application testing against common vulnerability classes
- Internal network, segmentation and lateral movement
- Microsoft 365, Entra ID and cloud identity paths
- Wireless network testing where in scope
- Optional phishing and social engineering by agreement
Findings, remediation and retesting
Each finding includes evidence, reproduction steps, an assessment of realistic impact in your environment, and specific remediation guidance. Severity accounts for exploitability and what the finding actually reaches — a critical-rated vulnerability on an isolated system with no sensitive data is not the first thing to fix.
We debrief the report with both technical staff and leadership, because the two audiences need different framings of the same result. After remediation, in-scope findings are retested to confirm closure, and that retest result is documented — which is what clients and insurers usually want to see.
Testing is a point-in-time exercise. It reflects the environment as configured during the testing window and does not certify future security. Annual or post-major-change testing is the practical cadence for most organisations.
- Evidence and reproduction steps for every finding
- Impact rated against your actual environment
- Technical debrief plus executive summary
- Retesting of remediated findings, documented
Keep exploring
Related Oakville services
Most engagements combine several of these. Follow the thread that matches the problem you are trying to solve.
Questions
Frequently asked questions
- Will testing disrupt our systems?
- Testing is conducted to minimise operational impact, disruptive techniques are excluded by default, and windows are scheduled around your business. Some risk of unexpected behaviour always exists when systems are probed, which is exactly why emergency contacts and a stop-testing trigger are agreed in advance.
- How is this different from a vulnerability scan?
- A scan identifies known weaknesses and reports them, often with false positives and without context. A penetration test validates whether those weaknesses can be exploited, chains them together the way an attacker would, and establishes what could realistically be reached. Scanning is a useful ongoing hygiene activity; testing is a periodic assurance activity.
- Should we fix known issues before testing?
- Generally yes. Paying skilled testers to rediscover an unpatched firewall you already know about is poor value. Remediate the obvious first, then test to find what you did not know.
- Who sees the report?
- You do. Reports are sensitive documents — they describe how to attack your organisation — and are delivered securely with agreed retention and destruction terms. We do not publish client names, findings or case studies.
Scope a penetration test properly
We will help you decide what should be tested, from which perspective, and whether a test is the right next step at all.