Cybersecurity services: delivery deadline negotiation
Use this delivery deadline negotiation exercise to agree a feasible schedule using actual dependencies and acceptance steps. You are discussing a scoped security assessment and remediation workshop with an IT manager preparing a supplier review. The point of the practice is to make a useful decision together, including recognising when the offer is not a fit.
Agree milestones, required client inputs and a procedure for handling delays.
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 delivery deadline negotiation
A useful question for this stage: “If an input arrives late, which part of the schedule should change?” Ask it when the conversation creates a reason for it, rather than reciting every question in order.
- Work backwards from the required outcome. Identify approvals and inputs. Offer a phased delivery if it is genuinely feasible.
- 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.
- Agree milestones, required client inputs and a procedure for handling delays.
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 agree a feasible schedule using actual dependencies and acceptance steps. The buyer should answer consistently with the brief and ask for evidence when a claim is vague.
- Add this challenge: The buyer wants the full scope sooner but cannot accelerate approvals. Explain the trade-off between scope and timing.
- 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 | Accepting a date without checking access, approvals or delivery capacity. |
|---|---|
| A stronger direction | We can assess that date once the inputs and approval windows are confirmed. Here is the dependency that currently controls it. |
| 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. |
An example conversation
What makes that date important, and which deliverable is needed by then?
Our 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.
Which systems are in scope, and which business process depends on each one?
Can you guarantee we will not be breached?
No assessment can remove every risk. We can agree what we will examine, the evidence we will deliver and how remediation will be checked.
If an input arrives late, which part of the schedule should change?
Your working sheet.
Make the exercise your own. Notes are saved in this browser when storage is available. Download a copy to keep; avoid 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: If an input arrives late, which part of the schedule should change? 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
This is a reflection checklist, not an automated assessment.
Questions
Who is this cybersecurity services exercise for?+
Can I use the example as a script?+
How should I assess the result?+
Fictional training scenario. The dialogue illustrates response choices; it is not a customer testimonial or a record of a real sale.
Explore more sales resourcesTake the conversation further.
Read a practical guide to structuring your sales practice, or explore the current London sales masterclass.
Plan your sales practiceExplore Jordan Belfort in London