How to Run a Penetration Testing Engagement

A penetration testing engagement runs in five stages: scoping, reconnaissance and testing, exploitation and validation, reporting, and retest. For a small-to-mid-size SaaS environment, expect two to four weeks from kickoff to final report, with the hands-on testing itself taking three to ten business days depending on scope.

Why Pentest Timelines Get Underestimated

Most first-time buyers assume a penetration test is a single event, a consultant runs some scans and hands over a PDF a few days later. That model produces automated vulnerability scan reports dressed up as pentests, and auditors and enterprise security reviewers increasingly know the difference. A real engagement, human-led rather than tool-generated, takes longer because a tester has to understand the application logic, chain findings together, and confirm exploitability rather than flag every scanner hit as a critical finding.

Companies in Toronto, Waterloo, and Ottawa preparing for a SOC 2 audit or an enterprise security questionnaire often start the clock too late, assuming a pentest can be squeezed into the final two weeks before a deal closes. Build the timeline backward from your audit date or renewal date, not forward from when you happen to remember it is required.

Step 1: Define Scope and Rules of Engagement

Scoping is where most engagements succeed or fail before testing even starts. A tight scope produces a focused, defensible report. A vague one produces a report nobody trusts.

• Assets in scope: production application, staging environment, API endpoints, mobile apps, internal network segments, or cloud infrastructure (AWS, Azure, GCP configuration review).
• Test type: black-box (no credentials, simulates an external attacker), grey-box (authenticated user access, the most common and realistic choice), or white-box (source code access).
• Rules of engagement: testing windows, denial-of-service exclusions, data handling rules, and an emergency contact if something breaks in production.
• Compliance driver: SOC 2, PIPEDA obligations, Quebec's Law 25, or a specific customer contract clause. The driver shapes what evidence the final report needs to satisfy an auditor.

This is also where a boutique firm earns its keep over a generic vendor. A tester who understands your security program as a whole, not just the box being ticked, will flag scope gaps before they become findings an auditor rejects later.

Step 2: Reconnaissance and Vulnerability Discovery

The tester maps the attack surface: subdomains, exposed services, authentication flows, API surface, and third-party integrations. This phase blends automated tooling with manual review, automated scanners are useful for coverage but generate false positives and miss business logic flaws entirely. A published security researcher brings pattern recognition from real-world vulnerability research that a scanner cannot replicate, the kind of thinking that finds a broken access control path or an authentication bypass a tool would flag as informational, if it flags it at all.

Expect two to four days here for a mid-size web application. This is not idle time, it is the foundation for everything that follows.

Step 3: Exploitation and Manual Validation

This is where a real pentest earns its name. The tester attempts to exploit discovered weaknesses to confirm they are real, chained, and impactful, not theoretical. Common findings at this stage include broken object-level authorization, privilege escalation between customer tenants, injection flaws, misconfigured cloud storage, and weak session management.

Every confirmed finding is documented with reproduction steps, evidence, and a severity rating (typically CVSS-based). Nothing gets included on the strength of a scanner output alone. This distinction matters a great deal when the report needs to hold up to scrutiny from an enterprise customer's security team or an auditor reviewing your compliance evidence package.

Step 4: Reporting and Remediation Guidance

A useful report does two things a raw findings dump does not: it prioritizes by real business risk, and it gives your engineering team enough detail to fix the issue without a follow-up call for every line item.

• Executive summary written for a non-technical stakeholder or board.
• Detailed technical findings with reproduction steps and evidence.
• Risk ratings mapped to business impact, not just CVSS scores in isolation.
• Remediation guidance specific to your stack, not generic best-practice boilerplate.

This report also doubles as compliance evidence. Auditors for SOC 2 want to see a penetration test performed by an independent party with named credentials, not an anonymized vendor report. A report backed by a tester with a public research record, including CVE-2024-45163, a CVSS 9.1 finding that functioned as a kill-switch for the Mirai botnet, carries more weight in a due-diligence review than an unnamed contractor's output.

Step 5: Retest and Closure

Once your team remediates the findings, a retest confirms the fixes hold. This is often skipped by budget-constrained teams and it is a mistake, an auditor or enterprise customer asking for pentest evidence will often ask specifically whether findings were retested and closed, not just reported. Build a retest window of three to five business days into your original timeline rather than treating it as an afterthought.

Realistic Timeline for a Canadian SaaS Company

For a company based in Vancouver, Calgary, Montreal, or anywhere else in Canada preparing for a SOC 2 Type II audit or a customer security review, a realistic end-to-end timeline looks like this:

• Week 1: scoping call, rules of engagement signed, testing window scheduled.
• Weeks 2 to 3: active testing (three to ten business days depending on scope).
• Week 4: report delivery, findings walkthrough with engineering.
• Weeks 5 to 6: remediation and retest.

Compressed timelines are possible when the driver is a hard deadline, a closing enterprise deal or an audit date that cannot move, but scope needs to shrink to match, not the rigour of the testing itself.

Where a Partner Adds the Most Value

Most Canadian SaaS companies do not need a large testing firm running a templated methodology across every client. They need a tester who understands the specific architecture, asks the right scoping questions up front, and writes a report their auditor and their engineering team can both use without translation. That is the gap a boutique, human-led engagement fills, especially compared to a generic penetration-testing-as-a-service platform that leans heavily on automated scanning with light manual review layered on top.

For engagements that call for offensive-security depth beyond a single tester's bandwidth, or overlapping specialties like cloud configuration review and application testing in the same window, traztech works alongside Lorikeet to bring in the right coverage without adding a layer of account management between you and the people doing the testing.

Get Your Penetration Test on the Right Timeline

If you have an audit date, a renewal, or an enterprise deal on the calendar, the time to scope a penetration test is now, not the week before the evidence is due. TrazTech runs human-led penetration testing for Canadian tech companies from Toronto to Vancouver, built to produce evidence your auditor and your customers will actually accept. Explore our full compliance services or contact us to scope your engagement and get a realistic timeline for your audit date.

What to Have Ready Before the Testing Window Opens

The most common cause of a lost testing day is not a hard technical problem. It is a tester sitting idle on Monday morning because credentials do not work. Have these in place before the window starts, and confirm them the Friday before rather than the morning of.

One account per role, plus a second account in a different tenant. Two accounts at the same privilege level in separate organizations is what makes tenant isolation testing possible. If the tester only gets one account, cross-tenant access findings simply cannot be produced, and those are the findings enterprise reviewers care about most.

Seeded data that looks real. An empty account exercises almost nothing. Populate the test tenants with representative records, file uploads, integrations connected, and at least one invited user who has not accepted.

Allowlisting decisions made deliberately. If your WAF or rate limiter blocks the tester's source addresses, you will get a report describing your WAF. Decide whether you want the test to measure the application or the perimeter, and document the choice in the rules of engagement so the report says which one you tested.

Environment parity confirmed in writing. If testing runs against staging, list every way staging differs from production: authentication provider, feature flags, data volume, third-party integrations stubbed out. Auditors and enterprise reviewers read that list.

Third-party notice where it is genuinely required. Most major cloud providers no longer require advance permission for standard testing of your own resources, but managed SaaS components, payment processors and hosted identity providers frequently do. Check the contracts, not the folklore.

A change freeze, or at least a change log. Deploying twice a day during a test window produces findings the tester cannot reproduce and fixes nobody can attribute.

What Actually Drives the Quote

Penetration testing prices vary by an order of magnitude for reasons that are rarely explained on a proposal. The variables that matter:

Number of distinct roles and permission levels. Testing an application with three roles is not three times the work of testing one, but it is not the same work either. Every authorization boundary is a surface that has to be walked deliberately.

API breadth. A product with forty endpoints and a product with four hundred take very different amounts of time, regardless of how similar the front ends look.

Whether infrastructure is in scope. Cloud configuration review, internal network testing and application testing are separate disciplines with separate time budgets. Bundling them into one number without separate day counts is how scope quietly shrinks.

Retest terms. Some quotes include a retest, some include one within thirty days, some charge for it. This single line can change the real cost by a quarter.

Report depth and attestation. A full technical report plus a shareable attestation letter takes longer to produce than a findings export. If you need something to hand a customer, say so during scoping.

traztech's penetration testing starts from $1,000, and the honest framing is that the floor buys a narrow, well-defined scope rather than everything you own. Scope to the risk that matters, and see how the fixed-scope work is priced before assuming a bigger number is a better test.

Scoping Mistakes That Produce a Useless Report

Excluding authenticated functionality to save money. An unauthenticated external test on a SaaS product tells you almost nothing, because the product is behind a login. This is the single most expensive false economy in the category.

Leaving the admin panel out. Internal admin tooling is usually the least reviewed code in the company and holds the most privilege. It belongs in scope more than the marketing site does.

Testing staging that is not production-like. If staging runs a different identity provider or has integrations stubbed, the test covers a system you do not sell.

Scoping by asset list rather than by attack path. A list of domains is not a scope. What an experienced tester wants to know is where the money, the customer data and the trust boundaries are, then they work backward to the assets.

Setting the window over a holiday or a release. Testing during the week your senior engineer is away means findings sit unread for a fortnight and the retest slips past the audit date.

When Something Breaks During Testing

Occasionally a test causes a production problem: a queue backs up, an integration rate-limits, a poorly handled input crashes a service. This is not automatically a failure of the engagement, and how both sides behave in the next hour matters more than the incident itself.

The rules of engagement should name a live contact on both sides with a phone number, not an email address, and define a stop condition. When something goes wrong, the tester stops that activity, contacts your named person immediately, and documents exactly what was sent and when so your team can correlate it against logs. Do not let the incident vanish from the record. A crash caused by malformed input is a finding, and it should appear in the report with the same detail as anything else. Some of the most useful findings in the category surface exactly this way, because availability impact is real impact.

The corollary is that your team should be watching. If a tester can degrade a production service for twenty minutes and nobody in your company notices, you have learned something important about your monitoring that has nothing to do with the vulnerability.

What To Do With a Critical You Cannot Fix In Time

Reports do not always land at a convenient moment. If a critical finding arrives ten days before an audit or a contract signature, the instinct is to hide it. Do the opposite, and do it in this order.

First, contain. A compensating control that removes exploitability, a feature flag disabling the affected path, a WAF rule, an IP restriction on an admin route, buys you time and is legitimate provided it is documented as temporary. Second, record the decision properly: what the finding was, what you did, what the residual risk is, who accepted it, and by what date the real fix ships. Third, tell the auditor or the customer before they find it. An open critical with a dated remediation plan and an owner is a manageable conversation. The same finding discovered by someone else after you stayed quiet is a credibility problem that outlives the vulnerability.

Auditors are generally not surprised that a penetration test found something. They are looking for evidence that findings enter a tracked process with owners and dates rather than dying in an inbox. If your remediation record is a Slack thread, that is the gap to close before the next test, and it is the sort of thing an ongoing vulnerability management arrangement exists to hold.

Reading the Report the Way Your Buyer Will

Enterprise security reviewers open a penetration test report and check a short list, usually in under five minutes. Know what they look for, because it shapes what you should ask your tester to produce.

They check the date and whether it predates your last major release. They check the scope statement to see whether the thing they are buying was actually tested, which catches a surprising number of reports covering a marketing site. They check the methodology and whether it names a recognized standard. They check who performed it, because an independent named party carries weight that an anonymous vendor template does not. And they look for evidence of closure, meaning a retest letter or a remediation summary rather than a list of open highs.

Most companies should not hand the full technical report to customers. Reproduction steps for live vulnerabilities are not something to distribute under a click-through NDA. The normal practice is a summary attestation letter stating scope, dates, methodology, tester identity, severity counts and remediation status, with the full report available under a signed agreement to buyers who insist. If customers are asking you for this regularly, there is more detail in how to answer a customer asking for proof of a penetration test.

When You Should Not Buy a Penetration Test Yet

There are cases where booking a test is the wrong spend, and saying so costs us work we would rather not take.

You have known unfixed issues. If you already know MFA is not enforced on admin accounts, secrets are in the repository, or a service is running an unpatched major version, you do not need someone to charge you to confirm it. Fix the known list first. A test run over a known-bad environment produces a report full of findings you could have written yourself, and it burns the budget that should have funded the retest.

Pre-launch products with no users and no data. Testing an application that will be substantially rewritten before anyone touches it means paying to test code that will not ship. A design and architecture review is the better purchase at that stage.

The requirement is a scan, not a test. Some contracts and some framework criteria are satisfied by regular authenticated vulnerability scanning. Read the actual clause. If it says quarterly scanning, buy quarterly scanning, which costs a fraction of a manual engagement. It is worth checking whether your framework genuinely requires a penetration test before assuming it does.

You have no capacity to remediate. If engineering has no sprint room for the next quarter, the report will sit. A test whose findings go unfixed is worse than no test, because you now have documented knowledge of a vulnerability and no record of acting on it. Book the test when the fixing capacity exists, not when the budget line opens.