BYTEASSUREStart a reviewA fixed-price penetration test can be useful for a small application. It becomes misleading when the price is fixed and the scope is not.
The phrase “test our platform” leaves too many unanswered questions. Does the platform include three mobile apps, an administrative console, third-party infrastructure and a production API? How many roles exist? Is source code available? Can the tester create data or trigger emails?
A credible scope removes that ambiguity before payment and before testing.
Name the targets precisely
List the hostnames, application, API paths and environment. State whether the test uses production, staging or a dedicated environment. If production is included, define safe data and operational limits.
Third-party systems should be excluded unless the customer can provide written authorisation from their owner. A payment provider's hosted page can be part of the workflow without becoming a target for active testing.
Describe the roles and accounts
Authorisation testing depends on roles. Provide representative accounts for an ordinary user and any in-scope administrator or organisation owner. For a multi-tenant product, provide at least two test organisations so isolation can be tested safely.
State whether account creation, invitations, passwordless links, password reset and support impersonation are in scope. These flows often matter more than the login form itself.
Write the exclusions in plain language
Typical exclusions include:
- denial-of-service and high-volume stress
- social engineering and phishing
- physical access
- destructive data modification
- unrelated customer or third-party systems
- persistence after the test window
An exclusion protects both parties, but it should not hide an important product risk. If rate limiting is relevant while load testing is excluded, agree on a low-volume method to assess the control.
Agree on timing and contact
Name the testing window, time zone and emergency contact. Define what should happen if the tester finds a vulnerability with immediate customer impact. The answer may be “stop, preserve evidence and call this person.”
Production monitoring teams should know the authorised source and window so they can distinguish the test from unrelated activity without disabling useful alerts.
Define the evidence and severity method
Each confirmed finding should include the affected target, prerequisites, reproducible steps, safe evidence, impact and remediation. Severity should reflect exploitability and business consequence rather than scanner labels alone.
The report should also state limitations: unavailable roles, unstable environments, excluded systems and areas that could not be tested. That makes the result easier to interpret later.
Be precise about the retest
“One retest” should say what is included. A sensible fixed-price retest verifies agreed fixes for the confirmed findings from the original report. It is not a second full assessment of a redesigned product or newly added functionality.
Set a reasonable window for the retest and explain how unresolved findings will be recorded.
Confirm authority before activity
The customer should confirm ownership or provide written authorisation for every active target. The rules of engagement should identify the organisation, tester, dates and scope.
This is more than paperwork. It is the boundary that turns potentially harmful activity into controlled security work.
A good scope makes a modest penetration test more valuable because the evidence answers a defined question. It also makes clear when the application has outgrown a £999 engagement and needs a separately planned assessment.