Penetration Testing Requirements: A Practical Checklist

Penetration testing requirements typically boil down to five things: a clearly scoped engagement, human-led exploitation (not just automated scanning), coverage of the systems your compliance framework or customer contract names, a report mapped to remediation, and evidence that a qualified tester actually did the work. Skip any one of these and the test may satisfy a checkbox but not an auditor, an enterprise security questionnaire, or a real attacker.

Below is a practical checklist you can use to scope a penetration test, whether you're prepping for SOC 2, closing an enterprise deal, or just trying to find out where you're exposed before someone else does.

1. Define What "Passing" Actually Means

Before you scope anything, know who is asking for the test and why. A SOC 2 auditor, a customer's vendor risk team, and your own engineering leadership all want different things out of the same engagement.

• Compliance-driven: SOC 2, ISO 27001, and PCI DSS each expect an annual test, but none of them accept a vulnerability scan dressed up as a pen test.
• Contract-driven: Enterprise customers often specify scope, frequency, and sometimes even the tester's qualifications in the master services agreement.
• Risk-driven: If you're testing because you actually want to know your exposure, scope it around what an attacker would target first, not what's easiest to test.

2. Confirm the Test Is Human-Led, Not Just Scanner Output

This is the single most common gap we see when reviewing pen test reports for clients. A lot of "penetration tests" on the market are an automated vulnerability scan with a template wrapped around it. Automated tools are fine for coverage, but they miss business logic flaws, chained exploits, and authentication bypasses that only show up when a human tries to break the application the way a real attacker would.

Ask any prospective testing firm directly: who is running this test, and what's their track record? traztech's testing is led by Jacob Masse, a published security researcher with five CVEs to his name, including CVE-2024-45163, a CVSS 9.1 finding that functioned as a kill-switch for the Mirai botnet. That's the level of hands-on exploitation experience your report should reflect, whether it's traztech or another firm doing the work.

3. Scope the Right Assets

Scope creep and scope gaps both cause problems. Too narrow and you leave real risk untested; too broad and you burn budget testing things nobody cares about. A defensible scope typically includes:

• External-facing web applications and APIs that handle customer data
• Authentication and authorization flows (this is where most business logic bugs hide)
• Cloud infrastructure configuration (AWS, Azure, GCP) if your product runs there
• Internal network segments, if the framework or customer requires internal testing
• Any newly shipped feature that touches sensitive data since the last test

If you're not sure what's in scope, our security testing services page walks through how we scope engagements around what actually matters to your business, not just what's convenient to test.

4. Set the Right Frequency and Trigger Events

Annual testing is the baseline most frameworks expect, but "annual" isn't the whole answer. You also need testing triggered by events, not just the calendar:

• After a major architecture change or new product launch
• Before a significant enterprise deal closes, if the customer's security team requests evidence
• Following a merger, acquisition, or new cloud environment migration
• After any security incident, even a minor one

Canadian SaaS companies selling into the US market run into this constantly: a prospective customer's procurement team asks for a pen test report dated within the last twelve months, and a stale report kills momentum on the deal.

5. Verify Tester Qualifications and Independence

Most frameworks require the test be performed by a qualified, independent party, meaning not your own engineering team testing its own code. Look for:

• Relevant certifications or, better, a demonstrated public research record (published CVEs, conference talks, disclosed vulnerabilities)
• No conflict of interest with the systems being tested
• A named tester, not an anonymous team, so the auditor or customer can verify credentials if asked

6. Insist on a Report That Maps to Remediation

A pen test report that's just a list of CVSS scores isn't useful to your engineering team. A requirements-grade report should include:

• An executive summary a non-technical stakeholder or board member can read in five minutes
• Detailed findings with reproduction steps, not just a severity label
• Business impact framing for each finding (what happens if this is exploited, not just what the exploit is)
• Concrete remediation guidance, ranked by priority
• A retest or attestation once fixes are in place

7. Make Sure the Test Doubles as Compliance Evidence

If you're pursuing SOC 2 or ISO 27001, your pen test report needs to slot directly into your evidence package, not require translation for the auditor. That means dated reports, clear scope statements, and a remediation trail auditors can trace. This is also where a testing partner who understands the compliance side pays off: our team pairs pen testing with compliance advisory work so the report lands in a format your auditor already expects, rather than something you have to re-explain during the audit.

For engagements that call for specialized red-team depth beyond what an in-house test covers, we bring in our partner Lorikeet, so clients get boutique-firm attention without sacrificing coverage on complex environments.

8. Understand the Canadian Regulatory Backdrop

Penetration testing requirements aren't purely a US SOC 2 conversation. Canadian organizations have their own pressures:

• PIPEDA expects reasonable safeguards for personal information, and a documented pen test is standard evidence of due diligence.
• Quebec's Law 25 raises the bar further for any organization handling Quebec residents' data, with security assessment expectations baked into its risk assessment requirements.

We work with tech companies across Toronto, Waterloo, Ottawa, Vancouver, Calgary, and Montreal, and the pattern is consistent: Canadian buyers face US-calibre compliance demands from customers and investors, but the domestic regulatory context (PIPEDA, Law 25) still shapes what "good" looks like at home. A testing partner who understands both worlds saves you from re-scoping the engagement twice.

9. Budget for the Test Realistically

Cost varies widely based on scope, and firms that quote a flat low price for "a pen test" without asking about your architecture are usually scoping an automated scan, not human-led testing. Ask for a scoping call before accepting a quote, and expect pricing to reflect the number of applications, APIs, and environments in play.

Putting the Checklist to Work

Run through these nine points before you sign a statement of work with any testing firm: defined purpose, human-led methodology, correct scope, appropriate frequency, qualified and independent testers, an actionable report, compliance-ready evidence, awareness of Canadian regulatory context, and realistic budgeting. Miss one and you risk a report that looks complete but doesn't hold up under an auditor's or a customer's questions.

If you're scoping a penetration test for SOC 2, an enterprise deal, or just peace of mind, get in touch with traztech and we'll walk through what your specific environment actually needs tested.

10. Get the Statement of Work Right Before You Sign

Most of the disputes we see between companies and testing firms trace back to a statement of work that left something implied. Six clauses are worth reading closely.

Named testers and substitution. If you selected the firm on the strength of a specific researcher, say so in the document. Firms that sell on a senior tester's reputation and staff the work with a junior are common enough to make the clause worth writing down.

Retest terms. State how long the retest window stays open, how many findings it covers, and whether it costs extra. Thirty days is common and often too short, because remediation has to fit a release calendar. Ninety days is more realistic for a team of ten.

Critical finding notification. Define what happens if the tester gains domain admin or reaches customer data on day two. You want notification within hours and a named phone number, not a mention in the report three weeks later.

Evidence handling. The tester will hold screenshots, extracted records, and credentials. Specify how that data is stored, when it is destroyed, and whether any customer data is permitted to leave your environment at all. Your own customers will eventually ask.

Report ownership and redistribution. Confirm you can hand the report, or a summary version, to auditors and customers under NDA. Some firms restrict this by default, which is unhelpful when the whole reason you commissioned the test was to satisfy a buyer.

Third-party authorization. If your product runs on infrastructure you do not own, or integrates with a SaaS platform you do not control, check whose permission is required. Major cloud providers permit customer testing of your own resources under a published policy, but testing a partner's API without their written agreement puts both of you in an awkward place.

11. Decide Between Authenticated and Unauthenticated Testing

An unauthenticated external test tells you what an anonymous attacker on the internet can reach. It is the cheaper option and it is what many low-cost quotes silently assume. It is also the wrong test for most SaaS products, because your real attack surface sits behind the login page.

For an application test, provide credentials for at least two roles at different privilege levels, plus two separate customer accounts if you are multi-tenant. That combination is what lets the tester probe the failures that matter commercially: horizontal access between tenants, vertical escalation from a standard user to an administrator, and object-level authorization on API endpoints where the identifier is guessable. None of those are findable without accounts.

Provisioning those accounts is also the most common cause of a delayed start. Have them ready, with working email addresses the tester controls, before the kickoff call, along with API documentation and a walkthrough of the main workflows. That typically saves a day of reconnaissance you would otherwise pay for.

Decide on defensive controls too. Leaving a web application firewall and aggressive rate limiting fully enabled produces a report that tests your firewall vendor rather than your code. The usual arrangement is to allowlist the tester's source addresses so the application itself gets tested, and then verify separately that the firewall blocks the same attacks from an ordinary address. Both results are useful. Only one of them tells you whether your code is sound.

12. Test Production, or Know Exactly How Staging Differs

Everyone would rather test staging, and staging is frequently a different application. Different configuration, missing integrations, older code, and permissive settings that would never survive production review. A clean staging test that misses a production misconfiguration produces confidence you have not earned.

If you test staging, write down the differences and check them separately: TLS configuration, security headers, cloud permissions, secret management, logging, and any component that exists only in production. If you test production, agree on rate limits, avoid destructive checks, and tell your on-call team the dates so a real incident during the window is not dismissed as the tester.

A team that ignores alerts during a test window is a team that will ignore an attacker who happens to arrive during it. Agree on a rule up front: alerts get triaged normally, and the tester confirms or denies attribution within the hour.

13. Argue About Severity Before the Report Is Final

Severity ratings in pen test reports are a negotiation more often than buyers expect, and the negotiation should happen during the draft review rather than after delivery. CVSS scores describe the technical characteristics of a flaw, not what it costs your business. A medium-rated information disclosure that exposes customer names in an error message may matter more to you than a high-rated issue on an internal tool with three users.

Ask for a draft and hold a findings review call. Testers occasionally misread a control that exists elsewhere in the architecture, and you would rather correct that before an auditor reads it, and findings get contextualised so the final report carries both the technical rating and the business impact.

What you must not do is pressure a firm into removing a valid finding. Auditors and enterprise reviewers read these reports regularly and they notice reports with no findings above low, particularly on a complex product. A firm that agrees to soften findings on request is a firm whose next report will not be believed either.

14. Have a Plan for Findings You Are Not Going to Fix

Every report contains something you will not remediate. The fix requires an architecture change scheduled for next year, or the affected component is being decommissioned, or the cost genuinely exceeds the risk. This is normal and it does not fail an audit. What fails an audit is an open finding with no decision attached to it.

Write a short risk acceptance record for each one: the finding, why it is not being fixed now, what compensating controls reduce the exposure in the meantime, who accepted the risk by name and title, and the date it will be reviewed again. One page. An auditor reading that sees a functioning risk management process. An auditor reading a twelve-month-old open critical with no commentary sees a control failure, and the conversation moves from your pen test to your entire remediation process.

Frameworks care about remediation timeliness as much as remediation itself. Set internal targets by severity, something like critical within seven days, high within thirty, medium within ninety, and then actually track against them, because the tracking record is what gets sampled.

15. Know Why Auditors Reject Pen Test Reports

A report can be technically excellent and still fail as evidence. The rejections we see fall into a short list.

The scope statement does not match the audited system boundary, so the auditor cannot tell whether the production application was tested or only the marketing site. The report is undated, or dated outside the observation period. There is no evidence the tester was independent of the team that built the system. The methodology section is generic enough to be indistinguishable from a scan. Remediation is claimed but never evidenced, with no retest letter. Or the report covers one application while the system description names three.

PCI DSS is stricter than the others and worth calling out separately, because it separates requirements that companies often assume are one purchase. Internal and external penetration testing are distinct. Quarterly external vulnerability scanning by an approved scanning vendor is a separate requirement from penetration testing and does not substitute for it. If you rely on network segmentation to reduce scope, segmentation testing has its own cadence. Read the requirement text against your quote before you sign, because discovering the gap during assessment means paying for a second engagement on a deadline.

What Actually Drives the Price

Testing is sold in days, so everything that adds days adds cost. The number of distinct applications and the number of user roles in each. The size of the API surface, since a hundred documented endpoints take longer than ten. Whether cloud configuration review is included and how many accounts are in play. Whether internal network testing is required, which usually adds logistics for access. Whether the environment is unusual, meaning heavy client-side logic, thick clients, embedded devices, or anything requiring reverse engineering. And whether the report has to be written to land as compliance evidence, which is a real difference in effort rather than a line item.

Our own penetration testing starts from $1,000, and that figure describes a genuinely small scope. A single application with a handful of roles is a different number, and a multi-application platform with internal testing is different again. Any firm that quotes without asking about roles, endpoints, and environments is quoting a scan.

When You Should Not Buy a Penetration Test Yet

There are situations where the honest answer is to spend the money elsewhere first.

If you have never run a vulnerability scan, do that first. Paying a skilled tester to find missing patches and expired certificates is paying premium rates for work a tool does in an hour, and the report will be full of noise that buries the findings you actually needed a human for. Clear the automated layer, then test.

If you already know about serious problems and have not fixed them, fix them first. A test on a system with a known open admin interface produces one obvious finding and a tester who ran out of places to go.

If you have no capacity to remediate, defer. A report you cannot act on for six months is a document that ages into a liability, since a buyer who asks for it will also ask what you did about the findings.

And if nobody is asking, no framework requires it, and you are pre-revenue with three customers, a design review of your authentication and tenant isolation is usually better value than a full test. That is a smaller conversation and a cheaper one. If you are unsure which of these describes you, say so when you get in touch and we will tell you if the answer is to wait, or fold the testing into something ongoing once there is a reason for it.