Two proposals may both say “web application penetration test”, while one covers only public pages and the other includes login, user roles and APIs. Compare assets, processes and the risks you need to understand before comparing report length or scanning tools.
This guide concerns purchasing an authorized assessment and evaluating its output, rather than performing an attack. Identify a technical decision-maker, business representative and proposed testing company, then review written scope before activity begins. Owning a website does not automatically include every connected system in authorization or price.
Start with a business decision requiring evidence
In a fictional supplier portal, the owner is concerned about one user reaching another entity's documents and about approval permissions. The objective is not a label saying “secure”, but findings about these processes and the boundaries of what was not tested. A server-only assessment may leave the business question unanswered.
Describe sensitive processes in business terms: supplier registration, document review, request approval and staff permissions. Ask how the tester will cover agreed roles and boundaries without directing testing against unauthorized entities or accounts.
A brief for comparable proposals
The fictional supplier-portal brief could include the following. Replace them with your actual system details through an appropriate channel:
- Objective: Decisions to inform and concerns arising from application use.
- Included assets: A defined list of applications, domains, APIs and exclusions.
- Environment and version: Production or testing, known differences and identification of the assessed release.
- Roles and inputs: Test-account types, documentation and data your organization provides.
- Authorization and limits: The approving authority and permissions required for third-party services.
- Coordination: Available window, contact person and stopping/escalation conditions for unexpected effects.
- Delivery: Report, debrief and evidence protection and transfer arrangements.
- Follow-up: Remediation ownership and retest boundaries, period and output.
Ask each company to answer the same brief and identify assumptions. If a key role's account is unavailable, its effect on coverage should be visible. Do not accept a “complete” label hiding an essential untested area.
Discuss method and effort beyond tool names
Is the proposal automated assessment, testing with manual examination of functions and business logic, or a defined combination? Who performs it, what relevant experience do they bring and how much effort is allocated? Ask for the output of each activity rather than treating a tool or framework name as sufficient evidence of quality.
NCSC discusses scope, skills, communication and follow-up as important to obtaining value from testing. A reference such as OWASP can help discuss coverage, but does not establish that every item was applied or confer regulatory accreditation. If your organization requires a particular credential, verify its issuer, scope and validity independently.
Environment and authorization affect the conclusion
A test environment may reduce operational impact but differ from production in settings, integrations or permissions. Record differences affecting conclusions and whether additional authorized work is needed. Testing an old release should not be presented as a complete assessment of a newer one.
Agree a contact who can make decisions during testing and a process for critical findings or unexpected disruption. A connected service outside scope should not be added informally. Review the scope change, permission and effort before inclusion, or clearly record the exclusion and limitations.
A useful report serves management and remediation teams
Request a sample report with customer information removed to understand the provider's approach. Management needs business implications and assessment limits. Technical staff need information to understand, verify and address findings within authorized access. Page count or finding count is not an objective that defines report value.
OWASP's reporting guidance recommends scope, limitations, findings and remediation advice, with protection for sensitive information. For procurement, ask how severity levels are defined, what evidence is provided, how confirmed findings differ from items needing verification and how the report reaches authorized recipients securely.
Remediation and retesting are separate commitments
Who changes the application? It may be the current development company, or the proposal may include separate assistance. Distinguish assessment from implementation and establish whether retesting is included and which findings or versions it covers. Buying a report does not automatically purchase every fix.
For the supplier portal, track each finding's owner, decision, fixed version and retest outcome. If only part is addressed, the record should show that. Completing an assessment does not establish the absence of other risks or permanent security.
For broader controls, see the cybersecurity checklist. When discussing application security testing services, provide the brief, authorization boundaries and required output. Compare proposals against one question: what will we know afterward, and who will act on it?
Sources and limits
Opened on 3 November 2026: NCSC's penetration testing guide, published in 2017 and reviewed in 2022, and OWASP WSTG 4.2 reporting guidance. Procurement and reporting principles are used without applying British accreditation requirements to Egypt or Gulf markets. The example is fictional, and this article establishes no accreditation for Nextwave or another provider. The text was prepared with AI assistance and review of its content and sources.
