The scope of a penetration test determines everything: what gets tested, how long the engagement takes, what it costs, and whether the results are meaningful. A poorly scoped pentest wastes money by testing the wrong things or missing critical areas. A well-scoped pentest delivers maximum security value for every dollar spent.
This guide walks you through the scoping process step by step, covering what information your provider needs, how to define boundaries, and common scoping mistakes that lead to ineffective assessments.
What your pentest provider needs to know
Before a provider can give you an accurate scope and quote, they need to understand your application. Here is the information you should prepare for the scoping conversation.
Application overview
- Application URLs. The production or staging URLs where the application is accessible.
- Technology stack. Frontend framework, backend language, database, hosting environment.
- Application size. Approximate number of pages, features, or functional areas.
- User roles. Every distinct permission level in the application (admin, manager, user, viewer, etc.).
- Authentication methods. Password, SSO, MFA, API keys, OAuth, magic links.
API details
- API type. REST, GraphQL, SOAP, WebSocket.
- Endpoint count. Approximate number of API endpoints.
- Documentation. Whether OpenAPI/Swagger specs or Postman collections are available.
- Public vs internal. Whether the API is consumed only by your frontend or also by third parties.
Business context
- Data sensitivity. What types of data the application processes (PII, financial, health, etc.).
- Compliance requirements. Which frameworks the pentest needs to satisfy (SOC 2, PCI DSS, etc.).
- Previous testing. Whether you have been pentested before and what was found.
- Specific concerns. Any areas you are particularly worried about or want extra focus on.
Defining what is in scope
The scope should cover everything that matters for your security posture. For most web applications, that means the following areas.
All user-facing functionality. Every feature that any user role can access, from the login page to the deepest admin function. Excluding features from scope means excluding them from security coverage.
The complete API surface. Not just the endpoints the frontend calls, but all endpoints that exist in production. This includes legacy endpoints, admin APIs, and undocumented functionality.
Authentication and authorization. The full authentication lifecycle (registration, login, password reset, session management, logout) and the authorization model (every endpoint tested against every role).
Third-party integrations. Webhook endpoints, OAuth flows, payment processing, file import/export, and any other integration points where external data enters your application.
Scoping rule of thumb: If it is accessible from the internet and it handles your data or your customers' data, it should be in scope. The goal is to test your application the way an attacker would target it, and attackers do not respect scope exclusions.
Common scoping mistakes
- Excluding the API. Testing only the frontend of an API-driven application means missing the vast majority of the attack surface. The API is the application.
- Testing only one user role. If you provide only admin credentials, the tester cannot verify that lower-privilege users are properly restricted. Provide accounts for every role.
- Scope too narrow to satisfy compliance. If your pentest needs to satisfy SOC 2 or PCI DSS, the scope must cover the systems relevant to those frameworks. Discuss compliance requirements upfront.
- Excluding staging environment differences. If your staging environment is significantly different from production, findings may not be applicable. Test against an environment that mirrors production as closely as possible.
- Forgetting about mobile API endpoints. If you have a mobile app that talks to the same backend, those API endpoints should be in scope even if they are not used by the web frontend.
How scope affects cost and timeline
Pentest pricing is driven by effort, and effort is driven by scope. A tighter scope means less testing time and lower cost, but also less coverage. The goal is to find the scope that covers your critical risk areas without paying for testing you do not need.
For most SaaS companies, the sweet spot is a comprehensive assessment of the core application and API that covers all user roles and critical business logic. This typically results in an engagement of 7 to 15 testing days at a cost of $7,500 to $20,000.
If budget is a constraint, work with your provider to prioritize. Focus on authentication, authorization, and the features that handle the most sensitive data. A focused assessment of your highest-risk areas is more valuable than a shallow assessment of everything.
How Lorikeet Security handles scoping
At Lorikeet Security, scoping is a collaborative process. We schedule a 30-minute call where we walk through your application together, understand your architecture, discuss your compliance requirements, and identify your highest-risk areas. Based on that conversation, we provide a detailed scope document that specifies exactly what will be tested, how long it will take, and what it will cost.
There are no surprises. The scope document becomes part of the engagement agreement, and any changes are discussed and agreed upon before testing begins. Our web application pentests start at $7,500, with pricing that scales predictably based on application complexity.
Need Help Scoping Your Pentest?
Schedule a free 30-minute scoping call. We will review your application, recommend the right scope, and provide a detailed quote within 24 hours.
