For the engagement owner. Comparable pricing starts with comparable assumptions. Tell providers what decision the test supports, what access is available and what evidence the bank will accept.
State the commissioning objective
Write the decision the bank needs to make: release an application, evaluate a defined trust boundary, investigate a known exposure or validate remediation. Identify the service owner and intended audience for the report. Avoid using “full pentest” as a substitute for scope. Providers can interpret that phrase as anything from a narrow unauthenticated scan to a broad assessment with privileged access and business-logic testing.
Separate routine penetration testing from any advanced threat-led exercise. If TLPT is the requirement, use the applicable governance and procurement process. The DORA Article 27 provider requirements guide explains considerations that should not be reduced to a generic supplier questionnaire.
Read diagram text
- Objective
- Decision and accountable service owner
- Coverage
- Systems, roles and operations
- Acceptance
- Evidence, handover and retesting
Describe systems through operations and roles
Provide an inventory of the relevant applications, APIs, identity boundaries, environments and integrations. Add the operations and roles that matter: customer, support, approver, administrator and workload identity where applicable. Explain which accounts and synthetic objects the bank can provide. An endpoint count without this context gives a poor basis for estimating business-logic coverage.
Highlight third-party components, shared environments and permissions that are not yet resolved. Ask bidders to identify how each assumption affects coverage and delivery. Keep sensitive architecture details in the agreed confidential procurement channel rather than a public enquiry form.
Make operational constraints visible
State the approved environments, windows, request limits and prohibited methods. Identify services where even a small side effect requires a separate decision. Describe the stop authority, communications model and incident escalation arrangements. If production testing is proposed, require a risk-based explanation of the evidence needed there and the safeguards that support it.
For API-heavy products, our fintech API scoping guide helps turn a feature inventory into testable actor-object-operation comparisons. Banks can use that approach while applying their own change management and supplier controls.
Read diagram text
- Supplied access
- State test roles and synthetic fixtures
- Operational boundary
- Agree methods, windows and stop rules
- Closure work
- Define the included retest coverage
Specify what a useful finding contains
Ask for the tested starting position, affected boundary, reproducible observation, technical evidence, impact reasoning and limitations. Require a clear distinction between demonstrated actions and plausible but untested consequences. The report should record blocked and excluded coverage as well as findings. Agree how urgent observations will be communicated before the final document is delivered.
Review a sample finding with technical and risk stakeholders. It should be possible to understand what failed, which team can change it and how the bank will verify the result. Visual polish should support that reasoning, not replace it.
Read diagram text
- Starting position
- Unaided, supplied or assisted access
- Observation
- Reproduction and demonstrated impact
- Limitation
- Excluded, blocked and untested paths
Define retesting before comparing prices
Identify the included retest period, scenario boundaries and evidence expected for closure. Agree what happens if remediation changes the architecture, if new routes appear or if the necessary test role becomes unavailable. Clarify whether the provider will validate only named findings or also agreed adjacent cases. This avoids treating a narrowly priced verification exercise as an implied repeat of the whole engagement.
Set an acceptance criterion for the delivery itself: the bank receives usable evidence, a coverage record, a technical handover and an intelligible retest statement. A PDF file arriving on time is only part of that outcome.
Normalise the bids before selection
Create a comparison table covering scope, assumptions, delivery roles, operating safeguards, evidence, exclusions and closure. Ask providers to resolve material ambiguities in writing. A lower price may reflect efficient delivery, but it may also omit roles, integrations or validation work another bid includes. Compare those differences explicitly rather than relying on day rates or findings counts.
Use the bank readiness checklist to prepare the inputs. The final statement of work should be understandable to the service owner, testing team and procurement reviewer without requiring each to invent missing assumptions.
Read diagram text
- Issue a common brief
- Give every bidder equivalent inputs
- Resolve exclusions
- Make material differences explicit
- Agree the final scope
- Record ownership and acceptance criteria
Primary sources
General information, not a compliance opinion. Confirm legal applicability and testing requirements for your entity and jurisdiction.
This guide and the related sector publications linked above are published by Atlant Security. Technical examples are planning examples, not claims about completed client tests.
