Web Application Penetration Testing Checklist for Startups

Why preparation matters

The difference between a good pentest engagement and a great one is usually preparation. A vendor walking into a clear scope, a defined role matrix, and a working test environment finds more issues in the same number of testing days than one walking into "we will figure that out next week". The checklist below is what a startup security or engineering lead can prepare in a few hours that materially improves the outcome.

Step 1. Define what is in scope

Three lists, in writing:

• URLs and hosts in scope. The actual hostnames, including subdomains, that should be tested. Be explicit; "the website" is not specific enough.
• APIs in scope. Endpoints, base URLs, OpenAPI / GraphQL schema if available.
• Exclusions. Anything that is owned by a third party, hosted by another vendor, or out of scope for any reason. Note why.

If you are not sure whether something is in scope, list it as ambiguous and resolve on the scoping call. The cost of resolving ambiguity in writing is small; the cost of a tester spending two days on something that is not actually yours is large.

Step 2. Document the role matrix

For each user role in your application, write down what the role should be able to do. A simple table works:

Role	Read users	Modify users	Read billing	Modify billing	Export data
Owner	Yes	Yes	Yes	Yes	Yes
Admin	Yes	Yes	Yes	No	Yes
Member	Yes	No	No	No	Own data
Viewer	Yes	No	No	No	No

The matrix is rarely fully accurate the first time you write it. That is fine — the gap between what you wrote and what the application actually enforces is usually where the engagement finds the most.

Step 3. Provision the environment

Three options, in order of preference:

• Dedicated staging that mirrors production. Best option. Same code path, same configuration, isolated data. Tester moves freely without operational risk.
• Shared staging. Acceptable if other testing or dogfooding will not be disrupted. Note the multi-tenancy implications for tester observations.
• Production with safe-testing rules. Possible. Requires explicit rules of engagement: throttled rates, no destructive payloads, immediate stop signal, contact path open during the engagement.

Step 4. Provision test accounts

Two accounts per role per tenant, minimum. Why two: one for the tester to act as, one to verify cross-account boundaries. Why "per tenant": you cannot test multi-tenant isolation with one tenant.

For each account, document:

• Credentials (delivered via secure channel — never email)
• Tenant assignment
• Role assignment
• Any one-time setup (MFA enrollment, terms acceptance, profile completion)
• Whether the account is allowed to perform destructive actions in scope

Step 5. Rules of engagement

Six items in writing before testing starts:

• Hosts in scope and explicitly excluded. No ambiguity.
• Test window. Calendar dates and (if needed) hours of day.
• Throttling expectations. Maximum requests per second per host, if any.
• Contacts. Tester lead, your point of contact, plus an escalation contact on both sides.
• Escalation path for critical findings. What happens when something gets found that needs immediate fix.
• Authorization-to-test letter. Signed by an authorized person on your side, dated, scoped. Required for cloud-provider compliance and for legal protection of the tester.

Step 6. Set deliverable expectations

Confirm before kickoff:

• Report format. One document, or executive summary plus full report.
• Audiences. Board, auditors, customers, engineers.
• Compliance mapping. SOC 2, ISO 27001, PCI DSS, HIPAA — which to map findings to.
• Retest scope and timing. A retest of reported findings should be included in scope by default; confirm it.
• Disclosure terms. What can and cannot be shared externally about the engagement and findings.