To scope a pentest, identify each distinct target (web app, API, mobile app, cloud environment) as a separate scope, define what is off limits, and choose grey-box testing for the best cost to coverage ratio. Most SaaS startups should start with one scope covering their main web application or API.
Your first pentest engagement starts with a question that sounds simple: “What do you want us to test?”
If you answer wrong, you either pay for coverage you don’t need or miss the systems where your real risk lives. Scoping is the most important decision in a pentest engagement. Get it right, and the tester spends every hour on the systems that matter. Get it wrong, and you get a report full of findings on things nobody attacks while your actual attack surface goes untested.
Here is how to scope your first pentest without wasting time or money.
What “Scope” Actually Means
In penetration testing, scope defines three things:
1. The target: What systems, applications, or infrastructure will be tested. Each distinct target is typically counted as one “scope.” A web application is one scope. An API is one scope. A mobile app is one scope. A cloud environment (AWS, GCP, Azure) is one scope. If you are not certain what is actually exposed to the internet, a free external attack surface scan lists your live subdomains and services so you scope from a real inventory instead of memory.
2. The boundaries: What is explicitly off-limits. Production databases with real customer data? Third-party integrations you don’t own? Payment processors? These are usually excluded from testing to avoid disruption.
3. The rules of engagement: Testing hours, communication protocols, escalation contacts, and whether the engagement is black-box, grey-box, or white-box.
Your pentest firm should document all of this in a formal scope agreement before any testing begins. If they start testing without a signed scope document, that’s a red flag.
Types of Scope
Each scope type targets a different part of your technology stack. Understanding what each covers helps you prioritize.
| Scope Type | What Gets Tested | Typical Timeline | Best For |
|---|---|---|---|
| Web Application | Authentication, authorization, session management, input validation, business logic, OWASP Top 10 | 5 business days (single app) | SaaS products, customer portals, admin panels |
| API | REST/GraphQL endpoints, authentication, authorization between endpoints, rate limiting, data exposure, OWASP API Security Top 10 | 5 business days | API-first products, mobile backends, integrations |
| Mobile Application | Local storage, certificate pinning, reverse engineering, runtime manipulation, backend API calls | 7-10 days (per platform) | Consumer apps, B2B apps with sensitive data |
| Cloud Security | IAM policies, storage permissions, network segmentation, logging, infrastructure-as-code review | 7-10 days | AWS/GCP/Azure hosted products |
| Network / Infrastructure | External perimeter, internal network segmentation, firewall rules, exposed services | 5-7 days | Companies with on-premise or hybrid infrastructure |
Important: Each row in this table is a separate scope. If you need a web application pentest and an API pentest, that is two scopes, not one.
Common Scoping Mistakes Startups Make
Mistake 1: Testing everything at once
You have a web app, a mobile app, three APIs, and a cloud environment. Your instinct is to test all of it in one engagement. The problem: a tester splitting time across five targets goes shallow on all of them instead of deep on the ones that matter.
Better approach: Start with the system that handles the most sensitive data or faces the most external exposure. For most SaaS startups, this is the web application or the primary API.
Mistake 2: Forgetting the API
Your web app has a React frontend that talks to a backend API. You scope the pentest for “the web application.” The tester tests the frontend. But the API has its own authentication, its own authorization logic, and its own set of endpoints that the frontend doesn’t even use (internal admin endpoints, webhook receivers, batch processing endpoints).
If the API isn’t explicitly in scope, those endpoints go untested. And API endpoints are where most serious vulnerabilities live: BOLA, broken authentication, excessive data exposure.
Better approach: Ask your pentest firm whether the API and web app are one scope or two. If the API has its own authentication and can be tested independently, it’s a separate scope.
Mistake 3: Scoping too narrow to save money
You scope the pentest for just the login page and the payment flow because those feel like the highest-risk areas. The tester finds a few issues there. Meanwhile, the user profile endpoint has an IDOR that exposes every customer’s personal data, but it wasn’t in scope.
Better approach: Scope the entire application, not individual features. The tester should be able to follow attack chains across the full application, the same way a real attacker would. Restricting scope to specific pages defeats the purpose.
Mistake 4: Scoping too broad without budget to match
You include your web app, API, mobile app, cloud infrastructure, and internal network in one engagement for ₹75,000. The tester has 5 business days to cover everything. They spend one day on each target and miss the business logic flaws that take 3 to 4 days of focused testing to find.
Better approach: Match scope to budget. A single-scope engagement with 5 business days of focused testing finds more real vulnerabilities than a five-scope engagement with one day each.
Mistake 5: Not including staging/test credentials
You want a black-box test because “that’s how real attackers work.” True. But a real attacker has months. Your pentester has 5 business days. If the tester spends two of those days figuring out how to create an account and work through basic workflows, that’s two days not spent on finding authorization bypasses and business logic flaws.
Better approach: Provide test credentials for each user role (regular user, admin, read-only, etc.) and basic API documentation. This is grey-box testing, and it’s the most cost-effective approach for SaaS startups.
How to Decide What to Test First
If budget forces you to choose one scope for your first pentest, use this decision framework:
Test the web application first if:
- It’s your primary product and handles customer data
- Enterprise buyers or auditors are asking for a pentest report
- You haven’t had any security testing done before
Test the API first if:
- Your product is API-first (mobile app frontend, third-party integrations)
- Your API is publicly documented or accessible without authentication
- You have different authentication mechanisms for the API vs the web app
Test the cloud environment first if:
- You recently migrated to AWS/GCP/Azure and haven’t reviewed IAM policies
- You’ve had incidents related to storage exposure or misconfigured services
- Your infrastructure team is small and hasn’t had external review
Test mobile first if:
- Your app handles sensitive data locally (financial data, health records, authentication tokens)
- Your app is consumer-facing with a large install base
- You’re in a regulated industry (fintech, healthtech) where mobile security is audited
For most SaaS startups doing their first pentest, the answer is the web application. If you have a separate API (most modern SaaS products do), consider the Growth plan at ₹1,79,999 which covers two scopes with 10 business days of testing.
Grey-Box vs Black-Box vs White-Box
These terms describe how much information the tester starts with. The choice affects what the tester can find and how efficiently they find it.
| Approach | What the Tester Gets | Pros | Cons | Best For |
|---|---|---|---|---|
| Black-box | Nothing. No credentials, no documentation, no source code. | Simulates external attacker perspective | Tester wastes time on reconnaissance that could be spent on deeper testing | External perimeter testing, network pentests |
| Grey-box | User credentials for each role, API documentation, application architecture overview | Maximizes time spent on real vulnerability discovery | Requires some preparation from your team | Web app and API pentests (most common) |
| White-box | Everything: source code, architecture diagrams, database schemas, deployment configs | Deepest coverage, finds issues in code that may not be exploitable yet | Most expensive, requires more tester time | High-security applications, pre-release audits |
Our recommendation for startups: Grey-box. Provide the tester with test accounts for each user role and your API documentation. This lets them skip the setup phase and spend 100% of testing time on finding real vulnerabilities in your application logic.
Questions Your Pentest Firm Should Ask During Scoping
A good pentest firm asks detailed scoping questions before quoting. If a firm quotes you without asking these questions, they’re guessing at scope, and the engagement will either be too shallow or too expensive.
About your application:
- What does the application do? What industry are you in?
- How many user roles exist (admin, regular user, read-only, API consumer)?
- How does authentication work (username/password, SSO, OAuth, API keys)?
- Is the frontend a single-page app that talks to a backend API?
- Are there separate environments (staging, production)? Which should we test?
About integrations:
- Do you integrate with third-party services (payment processors, identity providers, cloud storage)?
- Which integrations are in scope and which are off-limits?
- Are there webhook endpoints or background processing jobs?
About infrastructure:
- Where is the application hosted (AWS, GCP, Azure, on-premise)?
- Is the cloud environment in scope or just the application layer?
- Are there any IP restrictions or WAF rules we should know about?
About compliance:
- Are you pursuing SOC 2 or ISO 27001? (This affects report format and compliance mapping.)
- Does your auditor have specific requirements for the pentest report?
- Do you need the report formatted for a specific audience (investor, customer, regulator)?
About logistics:
- What is the preferred testing window?
- Who is the escalation contact if we find a critical issue during testing?
- Do you need a retest after remediation?
Putting It Together: A Scoping Example
Here’s a typical scoping conversation for a Series A SaaS startup:
The product: A B2B SaaS platform with a React frontend, a REST API backend, and an admin dashboard. Hosted on AWS. 50 enterprise customers. Pursuing SOC 2 Type 1.
The decision: The web application and API share the same backend but have different authentication (session-based for the web app, API keys for the API). The admin dashboard is a separate React app with its own routes.
The scope: Two scopes. Scope 1: the customer-facing web application and its API (same backend, tested together). Scope 2: the admin dashboard and admin API endpoints. This maps to the Growth plan: 2 scopes, 10 business days, ₹1,79,999, with SOC 2 + ISO 27001 audit prep evidence included.
Grey-box setup: The startup provides test accounts for three roles (regular user, team admin, super admin), API documentation via Swagger, and access to a staging environment.
Boundaries: Third-party integrations (Stripe, Auth0) are out of scope. AWS infrastructure review is saved for a separate cloud pentest engagement next quarter.
Next Steps
If you’re planning your first pentest, here’s the path:
- List your targets. Web app, API, mobile app, cloud, network. Each is a potential scope.
- Prioritize by risk. Which system handles the most sensitive data or has the most external exposure?
- Choose one or two scopes. Match to budget. Deep testing on fewer scopes beats shallow testing on many.
- Prepare grey-box materials. Test credentials for each role, API documentation, architecture overview.
- Talk to your pentest firm. If they don’t ask the questions listed above, find a firm that does.
For a single-scope engagement, our Startup plan covers one target with 5 business days of testing at ₹74,999, including a full manual retest within one month of the v1.0 report. For two scopes, the Growth plan at ₹1,79,999 adds a second scope, 10 business days of testing, and SOC 2 + ISO 27001 audit prep evidence.
Not sure what scope you need? Book a free 30-min discovery call with the founders. We will assess your current posture and help you decide where a pentest delivers the most value.
For more on the testing process itself, read Penetration Testing 101 or see the difference between API pentests and web app pentests.
See our service pages for scope-specific details: web application pentest, API pentest, cloud pentest, Android application pentest, iOS application pentest, and internal network pentest for the network and infrastructure scope.
Want to see what you actually receive? Our sample penetration test report is published in full, no email gate: finding format, severity ratings, reproduction steps, and the retest that closes each finding as remediated.