Penetration test scope template and quote comparison

Scope for Northwind Cloud Inc

Derived from: Product: Northwind (Web SaaS) · Hosting: AWS and Vercel · Data types: PII · Source control and CI/CD: GitHub, GitHub Actions · Team size and work model: 11-50 people, remote · Vendors: Supabase, Stripe, Datadog, Slack

Your policies require an independent penetration test at least annually and after major architectural changes (P11 section 4.1; P20 section 4.13; P10 section 4.12).

Scope the application, its API, the internet-facing hosts and the cloud configuration, and add the optional items if the quotes leave room.

In scope

• Web application: Northwind

  The intake describes Northwind as a web SaaS product. Customers will ask about the application first.

  • Every feature available to signed-in users, tested at each role: [Fill in: roles, e.g. owner, admin, member, read-only]
  • Sign-up, sign-in, session handling, password reset and any single sign-on offered to customers
  • Tenant isolation: a user of one customer account must not reach another customer's data
  • File upload and download, exports, integrations and webhooks: [Fill in: which ones exist]
  • Screens and exports that show personal data
  • Target: [Fill in: production URL]
  • Target: [Fill in: staging URL, if testing there]

• API used by Northwind

  The web application calls a backend API. Testing only through the browser can miss endpoints the interface never uses.

  • Every endpoint in [Fill in: OpenAPI file or Postman collection], with the number of endpoints: [Fill in: count]
  • Authentication with API keys or tokens, token expiry and revocation
  • Object-level and function-level authorization: one account must not read or change another account's objects
  • Input handling, rate limiting and error messages that reveal internals
  • Target: [Fill in: API base URL]

• Internet-facing infrastructure

  Every host and service Northwind Cloud Inc exposes to the internet, including ones nobody remembers creating.

  • Open ports and exposed services, including administrative interfaces
  • TLS configuration and security headers
  • DNS records, subdomains and forgotten hosts
  • Target: [Fill in: domains and hostnames]
  • Target: [Fill in: public IP addresses or ranges]

• Cloud configuration review: AWS and Vercel

  Northwind runs on AWS and Vercel. Misconfigured access and public storage are found by reading the configuration with read-only access, not by attacking from outside.

  • AWS: IAM users, roles and policies, S3 bucket policies, security groups, public endpoints, logging and encryption settings
  • Vercel: team members and roles, project environment variables, deployment protection for preview deployments, domains
  • Done with a read-only role created for the test and removed when it ends
  • Target: [Fill in: AWS account IDs in scope]
  • Target: [Fill in: Vercel team and project names in scope]

• Source control and CI/CD configuration: GitHub, GitHub ActionsOptional

  A stolen developer account in GitHub can change what ships to production. A configuration review checks how far it would get. Optional for a first test; add it if the budget allows.

  • Organization settings, member roles and outside collaborators
  • Branch protection and required reviews on the production branch
  • Secrets and deployment credentials in GitHub Actions
  • Third-party apps and tokens with access to the code
  • Target: [Fill in: GitHub organization and repositories in scope]

Out of scope

Testing approach

• Unauthenticated testing. What an outsider with no account can reach: the sign-in and sign-up pages, public endpoints and internet-facing hosts.
• Authenticated testing. Testing with the accounts provided at each role, including attempts to reach data of another tenant or a higher role.
• Gray-box approach. The tester receives documentation, test accounts and an architecture overview, so time goes into finding issues rather than mapping the system.
• Manual testing first. Automated scanners support the work; they do not replace manual testing of authorization and business logic.
• API testing. Every documented endpoint, including endpoints the user interface does not call.
• Cloud configuration review. Read-only review of the hosting accounts against the provider's security guidance.

Suggested: OWASP ASVS Level 2, the level OWASP describes for applications that handle sensitive data. The intake lists personal data.

• OWASP Top 10: every category covered for the web application and API
• OWASP Web Security Testing Guide as the test procedure
• OWASP API Security Top 10 for the API
• CVSS base scores on every finding, so ratings can be mapped to the policy's severity levels

Rules of engagement

Deliverables to require

• Customer-shareable letter. A one or two page letter on the tester's letterhead that Northwind Cloud Inc can send to customers: Northwind Cloud Inc's name, the test dates, a summary of the scope and method, and the number of findings by severity, with no exploit details. An updated letter after the retest shows which findings were fixed.
• Full technical report. Each finding with a title, the affected asset, a CVSS base score and severity, steps to reproduce, evidence and specific remediation guidance, plus the scope actually tested and anything that could not be tested.
• Retest included. A retest of every Critical and High finding, included in the price, available for at least [Fill in: days] after the report so it covers the 30-day High deadline, with a retest letter.
• Findings in a spreadsheet. The findings as CSV or XLSX, so they can be entered in the vulnerability register without retyping.
• Readout meeting. A call to walk through the findings with Engineering before the final report.

Remediation deadlines from the sample policy

“Findings are remediated within timelines measured from detection: Critical within 7 days, High within 30 days, Medium within 90 days, and Low within 180 days or at the next scheduled maintenance, whichever is sooner. Where no fix exists for a Critical finding in an internet-facing system, a mitigating control such as a firewall rule, feature disablement or configuration change is applied within 72 hours.” (P11 section 4.3)

Questions to ask each firm

1. Method: Which standards and test procedure will you follow for each asset in scope, and how much of the work is manual?
2. Method: How do you test authorization and tenant isolation in a multi-tenant SaaS application?
3. Method: What will you need from us before testing starts (accounts, documentation, allowlisting), and by when?
4. People: Who will do the testing? Please name the testers, their certifications and relevant experience, and say whether they are employees or subcontractors.
5. People: Are your testers background-checked, and will they sign our confidentiality terms?
6. Independence: Do you sell any other product or service to us, such as remediation work or a compliance platform? How do you keep the test independent of it?
7. Deliverables: Can you share a redacted sample report and a sample customer letter?
8. Deliverables: Does the letter state the scope, dates and findings by severity, and can we share it with customers under NDA or without one?
9. Deliverables: How do you rate severity? Do you give a CVSS base score for every finding?
10. Retest: Is a retest of Critical and High findings included? How many retests, within what window, and do you issue an updated letter afterward?
11. Logistics: How many tester-days does your quote assume, when is your earliest start, and how many days after testing ends is the report delivered?
12. Logistics: How will you tell us about a Critical finding during the test, and how fast?
13. Data: Where will our findings and evidence be stored, who can see them, and when will you delete them?
14. Commercial: Is the price fixed for the scope described? What would cost extra?
15. Commercial: What professional liability and cyber insurance do you carry?
16. References: Can you give references from companies of similar size that you tested in the last year?

How to compare the quotes

What the sample policies require

• An annual independent test (P11 section 4.1)“... an annual independent penetration test ...”
• Annually and after major architectural changes (P20 section 4.13)“The external attack surface of Northwind is scanned for open ports, exposed services and known vulnerabilities at least monthly, and an independent penetration test of production is performed at least annually and after major architectural changes.”
• The product is tested and Critical and High findings retested (P10 section 4.12)“Northwind receives an independent penetration test at least annually and after major architectural changes; findings are remediated under the Vulnerability and Patch Management Policy and Critical and High findings are retested before closure.”
• How the test is run (P11 section 5.6)“Penetration test. The Security Owner engages an independent tester annually, scopes Northwind (Web SaaS) and its infrastructure, agrees the rules of engagement in 4.13, provides accounts and documentation, enters findings into the register, tracks remediation and obtains a retest letter for Critical and High findings; the report and letter are retained as audit evidence.”
• Written approval and rules of engagement (P11 section 4.13)“Penetration tests, audit tests and other technical assessments of live systems are scoped and approved in writing by the Security Owner and the Engineering lead before they start, and scheduled away from peak usage and release windows. They use a non-production environment or read-only access wherever that meets the objective, both sides name contacts who can halt the test and roll back any change, and test accounts and data are removed when testing ends.”
• No testing without written authorization (P02 section 4.9)“The following are prohibited: bypassing or testing security controls without written authorization from the Security Owner ...”
• How findings are rated (P11 section 4.2)“Findings are rated Critical, High, Medium or Low starting from the CVSS base score (9.0 and above Critical, 7.0 to 8.9 High, 4.0 to 6.9 Medium, below 4.0 Low) and adjusted for Northwind Cloud Inc's context: internet exposure, reachability in Northwind, active exploitation and data sensitivity. Any vulnerability in the CISA Known Exploited Vulnerabilities catalog present in an internet-facing system is Critical. The Security Owner may adjust a rating with recorded justification.”
• Remediation deadlines (P11 section 4.3)“Findings are remediated within timelines measured from detection: Critical within 7 days, High within 30 days, Medium within 90 days, and Low within 180 days or at the next scheduled maintenance, whichever is sooner. Where no fix exists for a Critical finding in an internet-facing system, a mitigating control such as a firewall rule, feature disablement or configuration change is applied within 72 hours.”
• Penetration test findings (P11 section 4.12)“Penetration test findings enter the register at the tester's severity, adjusted under 4.2 where warranted, are remediated within the 4.3 timelines, and Critical and High findings are retested by the tester before closure.”
• One register for every finding (P11 section 4.5)“All findings from every source are tracked in a single vulnerability register with asset, severity, source, owner, detection date, due date, status and closure evidence.”
• Findings that miss their deadline (P11 section 4.6)“Where a finding cannot be remediated on time, the owner submits an exception with the reason, compensating controls and planned remediation date. The Security Owner approves exceptions for Medium and Low findings; Critical and High exceptions also require Executive Management approval. Exceptions last no more than 90 days and are re-reviewed before renewal.”
• Findings feed the risk register (P17 section 4.12)“Findings from internal reviews, external audits, penetration tests and post-incident reviews are entered in the register or linked to an existing risk within ten business days, so one prioritized action list exists.”
• Customer data outside production (P09 section 4.11)“Production customer data is not copied to lower environments except in anonymized or masked form approved by the Security Owner.”