Create a handover record with ownership, acceptance criteria and a first action.
The situation
In this fictional brief, the team has a long list of findings with no agreed business priority. The buyer wants an owned remediation plan linked to specific systems and risks. Your offer is a scoped security assessment and remediation workshop, but you must first establish whether its scope addresses the actual need.
A relevant delivery constraint is that testing needs written scope, permission and an agreed change window. Treat that as a fact in the exercise; do not remove it to make the sale easier.
| Your counterpart | an IT manager preparing a supplier review |
|---|---|
| Offer under discussion | a scoped security assessment and remediation workshop |
| Evidence available | a redacted example of evidence, severity rationale and remediation verification |
| Terms to clarify | Document permitted testing, data handling, exclusions and reporting recipients. |
How to approach sales-to-delivery handover
A useful question for this stage: “Which assumption would cause the biggest problem if it turned out to be wrong?” Ask it when the conversation creates a reason for it, rather than reciting every question in order.
- Review the goal, scope, promises, dependencies and open issues. Ask the client and delivery owner to correct the summary.
- Ground the discussion in the buyer’s work. Ask: “Which systems are in scope, and which business process depends on each one?” Listen for a concrete example before making a claim.
- Use evidence relevant to the decision: a redacted example of evidence, severity rationale and remediation verification. Explain what it demonstrates and what remains unverified.
- Create a handover record with ownership, acceptance criteria and a first action.
Example exchange
An illustrative exchange. Real conversations will take a different path.
SellerBefore we begin, let us check that the delivery team and client have the same understanding of the agreement.
BuyerOur concern is that the team has a long list of findings with no agreed business priority. Also, testing needs written scope, permission and an agreed change window.
SellerWhich systems are in scope, and which business process depends on each one?
BuyerCan you guarantee we will not be breached?
SellerNo assessment can remove every risk. We can agree what we will examine, the evidence we will deliver and how remediation will be checked.
SellerWhich assumption would cause the biggest problem if it turned out to be wrong?
An industry-specific concern
Buyer: “Can you guarantee we will not be breached?”
Possible response: “No assessment can remove every risk. We can agree what we will examine, the evidence we will deliver and how remediation will be checked.”
Why this response helps: it acknowledges the concern, brings the discussion back to a verifiable requirement and leaves room for a different decision. Adapt the wording to what the buyer actually said.
Run the practice
- Prepare for two minutes. One person takes the seller role and one plays an IT manager preparing a supplier review. Read the offer and constraint separately from your preferred answer.
- Have a five-minute conversation focused on transfer the buyer’s goals, agreed scope and unresolved questions to the delivery team. The buyer should answer consistently with the brief and ask for evidence when a claim is vague.
- Add this challenge: The client remembers an informal promise that is absent from the signed scope. Investigate it rather than dismissing or silently accepting it.
- Pause for feedback. Quote one useful question and one missed opportunity. Repeat the difficult exchange using a different response.
- Finish by writing the actual agreement. A sensible option, when it fits, is to assess one explicitly authorised system and review the reporting format. A clear decision to pause is also a useful outcome.
What to avoid
| Common mistake | Passing the proposal over without the context behind the buying decision. |
|---|---|
| A stronger direction | Here is the problem the client described, the evidence we agreed to review and the items we have not promised. |
| Scope and claim boundary | Never offer testing without authorisation or promise complete protection. |
| What to measure in real work | the number of agreed priority findings with owners and verification dates. Establish a baseline and definition before interpreting a change. |
Your working sheet
Write your own version below. Notes are saved on this browser when local storage is available. Use Download to keep a separate copy; avoid adding confidential information on a shared device.
Example: the team has a long list of findings with no agreed business priority; testing needs written scope, permission and an agreed change window.
Example: Which assumption would cause the biggest problem if it turned out to be wrong? Industry question: Which systems are in scope, and which business process depends on each one?
Example: a redacted example of evidence, severity rationale and remediation verification. Never offer testing without authorisation or promise complete protection.
Example: Propose a clear next step, such as: assess one explicitly authorised system and review the reporting format. Confirm the owner and date.
Review your work
Tick only what you can support with your answer or practice. This is a reflection checklist, not an automated assessment.
Questions about this resource
Who is this cybersecurity services exercise for?
Founders, salespeople and account managers preparing for a conversation about a scoped security assessment and remediation workshop. Adapt the brief to your real offer and authority before using it at work.
Can I use the example as a script?
Use the questions as prompts. Listen and respond to the buyer’s actual meaning. The target is to transfer the buyer’s goals, agreed scope and unresolved questions to the delivery team, not to deliver a memorised speech.
How should I assess the result?
Create a handover record with ownership, acceptance criteria and a first action. Use the three review questions below. The checklist is for reflection; it is not a validated prediction of sales performance.
Fictional training scenario. The dialogue illustrates response choices; it is not a customer testimonial or a record of a real sale. About these resources.