Types of Penetration Testing: Web, Network, Cloud, and More

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.

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 five 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.

Pentest, Vulnerability Scan, Red Team, Bug Bounty: Four Different Products

Half the confusion in scoping conversations comes from four distinct things being sold under overlapping names. A vulnerability scan is automated, runs in hours, and tells you which known issues are present against a signature database. A penetration test is time-boxed manual work against a defined target, where a human attempts real exploitation and chains findings together. A red team engagement drops the defined target and tests whether your detection and response functions notice an operator working toward a specific objective, which means it measures your blue team as much as your attack surface. A bug bounty is an ongoing open invitation with variable coverage, useful for breadth, useless for producing a dated report against a fixed scope.

The mismatch that wastes the most money is buying red team work before you have fixed the findings a standard test would have produced. If your patch cadence is unproven and your logging is not centralized, a red team will succeed quickly, and you will pay a premium for a report that tells you what a two thousand dollar scan and a week of manual testing would have told you. Red teaming earns its place once the obvious paths are closed and the question has genuinely moved from what is broken to whether anyone would notice.

Black Box, Grey Box, White Box: The Choice That Changes Your Findings

Access level is the variable most buyers ignore, and it changes results more than the tester's skill does. A black box test starts with no credentials and no documentation, which mimics an anonymous attacker but burns a large share of the engagement on reconnaissance. A grey box test supplies working accounts at each privilege tier plus basic architecture context. A white box test adds source code and infrastructure configuration.

For a SaaS product, grey box is almost always the right buy, and the reason is arithmetic. If a five day test spends two days finding its way into an authenticated area that any paying customer reaches by signing up, you have bought two days of reconnaissance theatre. Give the tester one account per role, including a second tenant so cross-tenant access can be tested properly, and the whole engagement is spent on the logic that actually holds your customers' data apart. The exception is when the specific question is what an unauthenticated attacker on the internet can reach, which is a legitimate external network question rather than an application one.

Rules of Engagement, and the Prerequisites That Delay Tests

The paperwork before a test is short but non-negotiable, and missing pieces are the most common reason a start date slips. You need a written scope listing every in-scope host, domain, and application, with anything explicitly excluded named rather than assumed. You need a testing window, including whether after-hours work is required. You need named technical and business contacts reachable during the test, and an agreed escalation path for a critical finding that cannot wait for the report. You need authorization signed by someone with authority over the systems, which is not the same as the engineer who requested the test.

Two prerequisites catch teams out. The first is cloud provider notification requirements and, more importantly, your own WAF or DDoS protection, which will happily block a tester for an entire engagement while everyone assumes the application is remarkably resilient. Allowlist the tester's source addresses at the edge, or run the test against an origin the tester can reach directly, and record which you did because it changes how the results should be read. The second is credential provisioning. Accounts that require an email domain you control, an admin approval step, or a manual onboarding call routinely arrive on day two of a five day test.

Testing Production or Testing Staging

The honest answer is that production gives real results and staging gives safe ones. Staging environments diverge from production in exactly the places that matter: different IAM roles, sanitized data, a different WAF configuration, feature flags set differently, and third-party integrations pointed at sandboxes. A clean staging report can coexist with a genuinely exploitable production system.

Most teams land on a workable compromise. Read-only and enumeration work runs against production, destructive or noisy work runs against a staging environment that has been deliberately reconciled with production configuration beforehand, and anything that would create customer-visible data runs under agreed test tenants. If you test staging, make the report say so plainly. An auditor or an enterprise security reviewer reading a report that quietly tested a mirror will treat it as weaker evidence, and they are right to.

What a Report Has to Contain to Be Worth Anything

Reports vary enormously in quality, and you can grade one quickly. Every finding should carry reproduction steps precise enough that your own engineer can trigger the issue without asking the tester a question, the evidence that proves it, an explanation of what an attacker gains, and a remediation recommendation specific to your stack rather than a paragraph copied from a standards document. The report should also state what was tested and what was not, which is the section that protects you when a buyer asks whether the API was in scope.

Severity ratings deserve scepticism. A CVSS score is calculated against a generic environment and knows nothing about your data. A medium-rated information disclosure that leaks internal user identifiers may be the most dangerous item in the report if those identifiers are the only thing standing between tenants, and a high-rated issue on an internal admin tool that three people reach through an authenticated VPN may sit for a quarter without harm. Re-rank the findings yourself against your own architecture before you build the remediation plan, and record why you moved anything, because that reasoning is what you will show an auditor who asks about a high finding you did not close in thirty days.

Remediation, Retest, and the Letter Your Buyer Actually Wants

A finding is not closed when a ticket is closed. It is closed when someone re-runs the original reproduction steps and the exploitation fails. Retesting is the step most often dropped for budget reasons, and it is the one that turns a report into evidence. Agree the retest window up front, usually thirty to ninety days after delivery, and confirm what it includes, because retesting fifteen findings in a fresh code branch is not the same effort as confirming three configuration changes.

Understand also what you will hand to customers. Most enterprise buyers do not receive the full report, which contains a working map of how to break your product. What circulates is an attestation letter naming the testing firm, the dates, the scope, the methodology, the count of findings by severity, and a statement of remediation status. Ask for that letter as a deliverable at contract time. Teams that ask afterwards spend a fortnight chasing a firm that has already moved on, usually while a security questionnaire sits open on a deal. Our penetration testing work treats the retest and the attestation letter as part of the engagement rather than as extras.

What Drives the Price

Testing is priced in tester days, so everything that adds days adds cost. Application complexity is the largest factor, measured by distinct user roles, number of authenticated workflows, and how much of the product is bespoke rather than framework default. A single-role CRUD application is a very different job from a multi-tenant platform with an admin console, a partner API, a billing engine, and role inheritance. Host count drives network testing. Cloud accounts, regions, and the number of distinct IAM boundaries drive cloud testing. Retesting, an attestation letter, and remediation support are separate line items in most proposals, and comparing quotes without checking which of the three are included is how buyers conclude that one firm is half the price of another.

Our own testing starts at $1,000 for narrowly scoped work, and the reason a small scope can be priced that way is precisely that scope, not skill, is what the day count follows. Be suspicious of any fixed price quoted before anyone has asked how many user roles your application has.

When You Should Not Buy a Penetration Test

There are three situations where we will tell you to spend the money elsewhere.

The first is when you already know the answer. If you have a vulnerability scanner reporting forty unpatched packages, no multifactor authentication on your cloud console, and secrets committed in a repository, a manual test will find those same things, charge you more, and deliver them in a longer document. Fix the known items, then test to find what you could not have found yourself. Paying a senior tester to rediscover your backlog is an expensive form of procrastination.

The second is when the requirement is satisfied by something cheaper. Some questionnaires ask for evidence of regular vulnerability scanning rather than penetration testing, and some SOC 2 auditors accept authenticated scanning plus a documented remediation process for systems that carry little risk. Read the actual control text or the actual clause before buying. A recurring scan and a tracked remediation cadence is a fraction of the cost and, for that specific requirement, is the correct answer.

The third is when the product is about to change underneath the report. Testing a week before a rewrite of your authentication layer ships means paying for findings against code that will not exist. Time the test to land after the significant release and before the customer deadline, and if those two dates conflict, test the current state and schedule a delta test after the release rather than pretending one test covers both. For teams running this internally for the first time, our guide on how to run a penetration test covers the operational side in more detail, and continuous coverage between annual tests is better handled through an ongoing vulnerability management arrangement than by buying a second full engagement.