The main types of penetration testing are web application, network (internal and external), cloud, API, mobile, and social engineering, and the right one depends on what you're trying to protect and who's asking for proof. A SOC 2 auditor wants different evidence than a bank running vendor risk on your app, so picking the wrong test wastes budget and still leaves the actual gap unfound.
Most Canadian tech companies run into this the first time a customer or auditor asks for "a pentest" without specifying which kind. Below is a breakdown of each type, when you actually need it, and how it fits into a broader security testing program.
Web Application Penetration Testing
Web app testing targets the software your customers log into: the SaaS platform, the customer portal, the admin dashboard. A tester works through authentication, session handling, business logic, and input validation looking for issues like broken access control, injection flaws, and privilege escalation between customer accounts (tenant isolation).
You need this when:
- Your product is the thing customers are trusting with their data
- You're pursuing SOC 2 and the app is in scope
- You just shipped a major feature touching authentication, billing, or permissions
This is the test most B2B SaaS companies in Toronto, Waterloo, and Ottawa ask for first, because it's the surface a prospect's security team will poke at during due diligence.
Network Penetration Testing: Internal vs External
Network testing splits into two distinct engagements that get confused constantly.
External Network Testing
This simulates an attacker on the open internet probing your perimeter: exposed ports, outdated services, misconfigured firewalls, VPN gateways. It answers "what can someone see and hit from outside our network."
Internal Network Testing
This assumes a foothold already exists, a compromised laptop, a malicious contractor, a phished employee, and asks how far that attacker could move. It tests segmentation, Active Directory hardening, lateral movement paths, and privilege escalation inside the network. Companies with office infrastructure in Montreal or Calgary that still run on-prem servers alongside cloud workloads need this even if their product is entirely SaaS, because the internal network is often the softer target.
Cloud Penetration Testing (AWS, Azure, GCP)
Cloud testing looks nothing like traditional network testing because there's no perimeter to scan in the classic sense. Instead it examines IAM policies and role permissions, storage bucket configurations, misconfigured security groups, secrets management, and container or Kubernetes hardening. A huge share of real-world breaches trace back to a misconfigured S3 bucket or an over-permissioned IAM role, not a zero-day.
If your entire stack runs on AWS or Azure, and it does for most Vancouver and Waterloo startups we talk to, this is arguably higher-value than a traditional network test, since it's testing where your actual infrastructure lives.
API Penetration Testing
Modern products are built on APIs, and API testing has become its own discipline separate from web app testing. It focuses on broken object-level authorization (can user A pull user B's records by changing an ID), rate limiting, authentication token handling, and excessive data exposure in responses. If your product exposes a public or partner-facing API, or your mobile app talks to a backend API, this needs its own scoped test rather than being lumped into a web app engagement.
Mobile Application Penetration Testing
Mobile testing (iOS and Android) covers insecure local data storage, weak certificate pinning, reverse engineering risk, and how the app handles the API calls underneath it. It's often skipped because teams assume the backend API test covers it, but mobile-specific issues, like sensitive data cached on the device, live entirely on the client and won't show up in a server-side test.
Social Engineering and Phishing Simulations
Technical controls don't matter much if an employee hands over credentials to a convincing phishing email. Social engineering engagements test human response through simulated phishing campaigns, pretexting calls, or physical access attempts. For companies handling sensitive financial or health data, this is often the fastest way to find the actual weak point, since attackers know it's easier to trick a person than break an encryption scheme.
How Compliance Frameworks Drive Which Test You Need
SOC 2, ISO 27001, and Quebec's Law 25 don't all ask for the same test. SOC 2 auditors generally want annual penetration testing covering the systems in scope for the trust services criteria, which usually means web app plus supporting infrastructure. PIPEDA and Law 25 obligations lean more on demonstrating reasonable safeguards, which can mean a broader mix depending on what personal data you hold and where. Under the CPCSC and similar Canadian procurement frameworks, the required scope is often spelled out explicitly, so it's worth checking the framework document before scoping the engagement rather than after.
This is where a lot of companies overspend or underspend: buying a generic "pentest" package that doesn't map to what the auditor or the contract actually requires. Scoping conversations should start with the compliance driver, not the vendor's default package.
Why Human-Led Testing Still Matters
Automated scanners find known CVEs and misconfigurations. They don't find broken business logic, chained vulnerabilities, or the kind of tenant-isolation bug that only shows up when a human tester thinks like an attacker rather than a checklist. traztech's testing is led by Jacob Masse, a published security researcher with six CVEs, including CVE-2024-45163, a CVSS 9.1 finding that functioned as a kill-switch for a Mirai botnet variant. That's the standard applied to client engagements: manual exploitation, not just a scan report with a logo swapped in.
For engagements that call for it, traztech partners with Lorikeet to bring in additional specialized capacity without losing continuity on the client side.
Turning a Pentest Into Compliance Evidence
A pentest report shouldn't just sit in a folder. Auditors and enterprise procurement teams want to see scope, methodology, findings with severity ratings, and evidence of remediation, formatted in a way that maps cleanly to whatever framework you're pursuing. A test built with that end use in mind saves you from re-running work later when the audit clock is ticking. This is part of why pentesting and compliance readiness work go together rather than being separate line items.
Choosing the Right Test for Where You Are
A pre-seed startup with no customer data yet probably doesn't need a full suite. A Series B SaaS company selling into US enterprise and mid-Series A companies going up-market almost always need web app plus cloud at minimum, with network and API added as the product and infrastructure grow. The honest answer to "which pentest do I need" is usually: start with what your next big deal or your auditor is actually asking for, then build out from there.
If you're not sure which type applies to your stack, compliance timeline, or upcoming audit, get in touch with traztech and we'll scope it based on what you actually need to prove, not a generic package.