Most disappointing penetration tests are lost at the scoping stage, not during the testing. A team buys a test because a customer or a board asked for one, hands the provider a URL, and receives a report that mostly repeats what an automated scanner already reported. The money is spent, a box is ticked, and the difficult questions about the system are no better answered than before.
Scoping is where a test earns its value. It is the conversation that decides what the testers examine, how deeply they look, and whether the findings will help you make a decision. In our advisory work this is often the most useful hour we spend with a client, because a well-scoped test of a small area beats a shallow test of everything.
Start with the decision the test should inform
Before you discuss targets or tools, agree what the test is for. A test before a major launch, a test to satisfy an enterprise customer’s security review, and a test to check one high-risk feature are three different engagements. Each implies a different scope, a different depth, and a different definition of success.
Write the objective down in a sentence. “Give us confidence that a tenant cannot reach another tenant’s data” is a scope. “Test the platform” is not. A clear objective lets the provider propose the right approach, and it gives you a way to judge the report when it arrives.
Define the targets precisely
List exactly what is in scope: which applications, which API base paths, which environments, and which user roles. List what is explicitly out of scope too, such as third-party services you do not own, shared SaaS platforms, and production data you cannot expose. Ambiguity here is where budget leaks, because the testers spend hours confirming boundaries instead of finding problems.
For a typical SaaS product, name the domains, state whether the mobile client and its backend are included, and identify the identity provider. If a system is out of scope because a supplier operates it, say so in writing so nobody assumes it was covered.
Agree the rules of engagement
Rules of engagement protect both sides. Decide the test window, whether testing runs against production or a production-like staging environment, and how everyone will react if a test causes an outage. Agree how sensitive data is handled. Under Malaysia’s Personal Data Protection Act you remain responsible for any personal data a tester encounters, so use synthetic or masked data wherever you can, and cover confidentiality in the contract.
Set named contacts on both sides and an agreed way to pause the test quickly. A test that runs over a weekend with nobody reachable is a test that turns a minor issue into an incident.
Decide how much access the testers get
Pure black-box testing, where the tester starts with nothing, mimics an anonymous outsider but spends much of the budget on discovery that an attacker would happily spend weeks on. For most SMEs a grey-box approach buys far more coverage per ringgit: give the testers accounts, roles, and some documentation, so they can reach the authenticated attack surface where the interesting flaws usually live.
Provide at least two accounts for each role. Much of the value in an application test comes from checking whether one user can read or change another user’s data, and that is impossible to test properly with a single login.
Ask for a methodology, not a tool
A credible provider describes how they test, not just which scanner they run. Recognised methodologies give you a baseline to expect. NIST’s SP 800-115, Technical Guide to Information Security Testing and Assessment, covers the overall assessment approach. The OWASP Web Security Testing Guide (v4.2) sets out web application coverage. The OWASP Application Security Verification Standard (ASVS 5.0) works well as a checklist for what “tested” should mean at your chosen assurance level. The Penetration Testing Execution Standard is a helpful structure for the engagement lifecycle, though it is now dated and best read alongside the living OWASP and NIST references.
For provider quality, CREST accreditation indicates that a firm and its testers meet an independent standard, which is useful when you cannot assess technical skill directly. If you handle cardholder data, PCI DSS requirement 11.4 sets specific expectations: internal and external testing at least every twelve months and after significant change, using a documented methodology.
Plan remediation and retest before you sign
A list of findings is not an outcome. Agree before the work starts that the provider will retest the issues you fix, so you can show a customer or auditor that exploitable problems were closed rather than merely recorded. PCI DSS makes retesting of exploitable findings explicit, and it is sound practice for everyone else.
Decide who on your side will own triage: reading the report, confirming real risk in your context, and assigning fixes to the people who can make them. We have written separately about how to triage a pentest report without getting lost in severity labels, because a strong test with weak follow-through still leaves you exposed.
Scoping is an advisory conversation
The best time to involve someone senior is before the statement of work is signed. A short review of the objective, the targets, and the rules of engagement usually pays for itself, because it stops you buying the wrong test or paying for reassurance you will not actually get.
A test scoped around a real decision, with the right access and an agreed retest, tells you something you did not already know. That is the difference between a report you file and a report you act on.