Offering a penetration test: define scope and deliverables before quoting

A prospect wants a penetration test and asks you for a quote. For your IT security business, this creates a concrete service decision: which application will be examined, under which agreed conditions, and what decision should the customer be able to make afterwards? A well described testing project connects the intended outcome with a clear scope. The customer can compare proposals on their substance, while your technical team gains a sound planning basis.

This article is for providers who actually perform or professionally take responsibility for such projects. It covers proposal boundaries, rather than testing procedures. The continuing example is entirely fictional: a software company wants its customer portal examined before a substantial extension. It identifies a web application, several user roles and an external hosting partner. Your proposal needs to explain the resulting assignment and what must be clarified before a possible start.

Describe the decision following the test

First ask how the company intends to use the results. In the example, the product owner wants to decide which identified issues should be addressed before the planned extension. This differs from an assignment limited to checking one existing finding. The intended decision gives your proposal a clear purpose and helps identify the right recipients for the results.

Record that purpose in a short paragraph. Explain what basis your team can provide. A report with understandable findings and a results meeting could serve this purpose if you offer those services. It does not approve the security of the company’s entire IT environment. Instead, the customer gains clearly bounded information for its own next decision.

Define the application under examination

“Our portal” is understandable in an initial conversation. A proposal needs a more precise description. Ask the customer to identify the application and its owner. Clarify together whether the public portal, an administration area and a connected interface belong to the same assignment. Both parties need the same understanding of the area examined and of any unresolved boundaries.

In the fictional case, another partner operates the billing interface. Your team therefore records it separately as requiring clarification. A technical connection does not by itself establish an agreed testing assignment for that service. Your proposal can distinguish a confirmed core scope from an extension requiring further coordination. The customer can then deliberately choose the project boundaries.

Connect user roles with business activities

The number of accounts does not explain which different activities need examination. Ask instead about the intended roles and their business tasks. The example has a customer area and internal processing. As the provider, you want to understand which workflows the customer wants included. The professional selection and precise depth of testing then belong in qualified project planning.

For the proposal, describe roles and relevant workflows in plain sentences. Keep real account names and confidential customer data out of the sales document. Abstract labels initially suffice. If dedicated test accounts or further information are needed later, your technical team agrees their provision through the designated project process. Sales does not need to collect credentials.

Make information and assumptions visible

The customer may have an application description that does not yet cover the intended extension. Ask about the date and scope of available documentation. Record which information your proposal assumes and which questions remain open. This helps the customer respond and your team assess whether preparation matches the proposed investigation.

In the example, the existing overview describes today’s application. A new role will only appear with the extension. You can therefore present two decisions: examine the current version, or clarify matters further before also including the planned new area. Your technical team assesses suitability against the actual project. The proposal makes the dependency understandable without treating an unknown development state as ready for testing.

Plan for written authorization and participants

The penetration testing guide published by Germany’s BSI identifies a written assignment and defined target, period and depth as organizational foundations. For sales, this creates a practical task: identify who represents the commissioning organization and which other operators or partners are involved. Actual authorization and required coordination must be established for the individual project; a sales conversation does not replace that assessment.

The hosting partner in the fictional case needs separate coordination. Identify an owner for it and the outstanding clarification. Keep confirmed agreements distinguishable from pending responses. The customer can then understand why its desired start still depends on a specific contribution. Your team also knows which prerequisites must actually be confirmed before delivery begins.

Connect project timing and business operations

A calendar week describes only part of the collaboration. Ask which business activities the customer wants taken into account and when responsible people are available. In the example, monthly billing falls within the initially requested period. The product owner and operations staff can agree a more suitable window. Your proposal planning gains a practical business context.

Also establish an agreed communication route during the project. Who is available on the customer’s side, who communicates for your team, and how will unexpected effects or a request to pause be handled? Detailed arrangements belong in technical preparation. The proposal should make this collaboration visible as a task and reflect the service you actually offer.

Match deliverables to their recipients

The product owner needs an understandable basis for planning. Developers need sufficiently concrete information to interpret and address identified issues. Ask about both audiences. Your proposal can separately name a management summary, a technical presentation of findings and a results discussion, where these form part of your service. The customer sees how the report can be used internally.

Describe the agreed handling of the report as well. It may contain sensitive information about the examined application. Recipients, delivery and subsequent handling should therefore be agreed for the project. During the proposal stage, you can name responsible people and arrangements still to be confirmed. Detailed findings are neither needed nor available at this point.

Explain findings and limitations together

A useful result description names the area examined, its version and the conditions actually agreed. This helps the customer understand the report’s significance later. An interface that was not examined remains explicitly outside the findings. The BSI guide discusses the time and scope limitations of such tests. Your commitment should respect these boundaries while showing the concrete value of the agreed project.

For the example, the report supports prioritization for the described customer portal under documented testing conditions. It does not promise to find every vulnerability or prevent future incidents. If the application changes afterwards, the significance of that change requires separate assessment. This is a professional follow-up question, not an outcome automatically included in the original assignment.

Clarify how findings and subsequent work will be handled

Ask who will receive results internally and organize further work. In the example, the product owner coordinates planning with development. Your proposal may include a discussion of the agreed results. Subsequent implementation or further testing receives its own scope if the customer needs it and you offer it. The initial service remains understandable in its own right.

For a requested retest, ask precisely which finding and which changed version should be examined later. Repeating an entire project differs from an agreed targeted retest. You can explain the option without pricing an unknown follow-up scope. The customer gains a clear decision point for the next phase.

Discuss the proposal through its actual scope

Walk through the fictional project with the customer in a consistent order: purpose, application, roles, partners, supplied information, timing and deliverables. Have outstanding points confirmed by the person who can actually answer them. If another provider also includes the administration area, comparing prices becomes useful once the differing scopes have been clarified.

Explain effort through the agreed work. Preparation, professional examination and reporting serve different purposes. Use your actual calculation rather than a generic flat rate borrowed from another example. If the customer changes the scope, show which service item is affected. Even after an adjustment, the customer can understand what result its purchase will provide.

Bring one outstanding question to a decision

Finally, the proposal needs a concrete next step. In the example, the hosting partner’s response on the intended examination area is still missing. Record who will obtain it and what decision can follow. A focused follow-up can address exactly that point. The customer need not repeat its entire situation or choose among several unclear next steps.

You can apply this approach to other application projects within your real offering. The essential link remains a business question, a clearly described examination target and a useful result. It makes professional competence visible during sales while preparing collaboration everyone understands. Qualified specialists remain responsible for technical delivery and project-specific safety arrangements.

Handle an additional request clearly

During the proposal discussion, the customer also expresses interest in its internal administration tool. First ask whether this belongs to the same application or is a separately operated system. Then identify the extra description and participation your specialists need to assess it. The customer can decide whether to clarify the extension now or proceed with the already described core assignment. This remains an understandable choice even without a reliable effort estimate for the additional tool.

Record the decision with the proposal version. A later reader should recognize which request became part of the scope and which was merely discussed. Product owners, purchasing and your project team retain the same basis. New information changes the relevant part of the agreement rather than silently expanding the entire project commitment.

New business enquiries for your IT security services

webRichtung supplies IT security enquiries with the stated concern, system environment, current stage, business location and contact in Germany. You clarify a specific penetration test scope personally afterwards; reports, system inventories and credentials are not collected through the enquiry. Register your business on the IT security leads page. In webRichtung Customer, you see the current price before placing a binding order.

Sources

BSI: Guide to performing penetration tests, November 2016, sections 1.4.2, 2.3 and 4.1.3. Read on 18 October 2026; organizational context, not current technical testing instructions or legal advice.