The Danger of Ambiguous Scoping
In offensive security, time is the ultimate constraint. If you allocate 10 days for a penetration test but provide an ambiguous scope, the engineers will spend the first 3 days just mapping subdomains and figuring out how to bypass your WAF. By the time they reach the core ledger APIs where the real fraud happens, the budget is exhausted.
Proper scoping requires the CTO or VP of Engineering to clearly demarcate the boundaries of the test, provide the necessary access, and establish the Rules of Engagement.
Step 1: Define the technical boundaries
You must create an exhaustive list of the assets to be tested. Do not use wildcards (`*.yourfintech.com`) unless you genuinely want the vendor testing your marketing blog and employee email portal.
- Web Applications: Provide exact URLs (e.g., `https://admin-staging.yourfintech.com`).
- APIs: Provide the base URL and the exact number of dynamic endpoints (e.g., `https://api-staging.yourfintech.com/v2` - 45 endpoints). Provide the Postman Collection or Swagger/OpenAPI documentation.
- Mobile Apps: Specify the platforms (iOS, Android). Provide the `.apk` and `.ipa` files directly, or provide TestFlight/App Distribution links.
- Explicit Exclusions: List exactly what is out of bounds (e.g., "Do not test the Zendesk integration. Do not run automated scanners against the core banking integration API").
Step 2: Choose the Environment (Production vs. Staging)
This is the most common point of friction. Do not test in Production if you can avoid it.
When security engineers test for race conditions or database injection, they generate massive amounts of garbage data. Testing a payment gateway in Production might trigger thousands of real SMS alerts or accidentally execute real ledger transfers.
You must provide a Staging or UAT (User Acceptance Testing) environment. However, this environment must be a 1:1 replica of Production. If your staging environment has the WAF disabled, uses HTTP instead of HTTPS, or runs code that is three months old, the pentest report will be completely invalid for your Production compliance.
Step 3: Provision the User Roles
To test business logic, engineers need to understand what different users are allowed to do. You must provision test accounts for every single role in your system.
For a standard Nigerian agency banking app, you should provide at minimum:
- 2 x Unverified User accounts (Tier 0)
- 2 x Fully Verified User accounts (Tier 3)
- 2 x Sub-Agent accounts
- 2 x Super-Agent accounts
- 1 x Admin Dashboard account
Why two of each? Because the engineers must log in as User A and attempt to access the data of User B (Horizontal Privilege Escalation). Without two accounts per role, this is impossible to test thoroughly.
White-listing the Pentesters
If you are testing behind a Web Application Firewall (WAF) like Cloudflare, you must temporarily whitelist the static IP addresses of the pentesting firm. If you do not, the WAF will block their tools after 5 minutes, and they will spend the rest of the week testing Cloudflare's security rather than your application's security.
Step 4: Define the Rules of Engagement (RoE)
The Rules of Engagement dictate what the engineers are allowed to do once they find a vulnerability.
Exploitation Depth
If the engineers find Remote Code Execution (RCE), should they attempt to pivot into your internal AWS network to see how far they can get, or should they immediately stop and report the initial RCE? Specify this.
Denial of Service (DoS)
Volumetric DDoS attacks are almost always excluded from scope. However, application-layer DoS (e.g., causing the server to crash by uploading a massive XML file) should be discussed. Usually, testers will prove the concept without crashing the server.
Social Engineering
Are the testers allowed to send phishing emails to your developers to steal their GitHub credentials? If this is purely an application pentest, explicitly exclude social engineering and physical premises testing.
Need help defining the scope for your upcoming assessment?
Request a Scoping CallFrequently asked questions
What is a penetration testing scope?
The scope is the strictly defined boundary of what the security engineers are allowed to attack. It includes the specific URLs, IP addresses, APIs, and mobile applications, as well as the rules of engagement (e.g., whether social engineering or DDoS attacks are permitted).
Should we test in Production or Staging?
You should always test in a Staging or UAT environment that perfectly mirrors Production. Testing in Production carries the risk of corrupting live databases, triggering actual financial transfers, or causing denial of service to real customers.
Why does the pentest vendor need different user roles?
To find complex business logic flaws and privilege escalation vulnerabilities (like a standard user viewing an admin's data), the engineers need access to every defined user role in your system. This allows them to map out the authorization matrices fully.
Can we exclude third-party integrations from the scope?
You must exclude the underlying infrastructure of third-party APIs (e.g., you cannot authorize a pentest against Paystack's servers). However, you must include your application's *integration* with that API to ensure you are handling webhook callbacks and authentication securely.
Related reading
Blog: Pentest Pricing in Nigeria · Pentest RFP Template
Guides: Fintech Security Checklist · CBN Compliance
Services: Penetration Testing · Vulnerability Assessment