Negotiation, Objection Handling & Closing Questions

Direct answer

Say something calm, specific and short, then offer evidence and a next step. You are not trying to prove that you are compliant in 60 seconds; you are showing you take it seriously, know how the answer is structured, and will give them something they can verify. This is the spoken script, under a minute (about 120 words):

"Fair question, and one we hear first from security teams, so let me give you the short version. Your data is encrypted in transit and at rest, access is limited by role and logged, and we are audited by an independent firm each year. The specifics depend on what data you plan to put in and where it has to live, which I would like to understand. Straight after this call I will send you our security pack: the audit report, an architecture diagram showing where data is stored, and our encryption summary. Would it help to set up a short call between your team and ours? In the meantime, which regulations apply to your data?"

Why each line is there

• Plain words, no acronym wall. A chief information security officer (CISO, the executive responsible for an organisation's security) hears vague claims all day. Short and concrete reads as competent.
• Three controls, named in a single sentence. Encryption, access control and independent audit are what they will ask next, and each one maps to a document in the security pack below.
• A question back. Their answer tells you which framework or region matters and moves it from a pitch to a conversation.
• A promised artifact with a time. It converts the exchange into a next step.

What I offer straight afterwards

Security pack within one business day. Items 1 to 3 are the core of a first CISO call and go out every time; items 4 to 6 follow on request or once the CISO's requirements are known.

1. The independent audit report, such as a SOC 2 Type II report (an auditor's assessment of security controls over a period) or an ISO 27001 certificate (proof that an accredited body audited our information security management system against that international standard), where we hold them, under non-disclosure agreement.
2. A data-flow diagram showing where data is stored and who can touch it.
3. An encryption and key management summary (how data is encrypted and who controls the keys).
4. The standard data processing agreement (DPA, the contract governing personal data handling).
5. A completed standard questionnaire, such as the Cloud Security Alliance's CAIQ (Consensus Assessments Initiative Questionnaire, a widely used list of cloud security questions), if available.
6. An offer of a call between their security team and ours.
   Only claim what the documents truly say.

Variant: a longer call

If I have 15 to 20 minutes, I cover three areas in turn:

1. Residency (data residency, meaning the country or region where data physically sits): where data is stored and processed, whether region choice is available, and what leaves the region (support access, backups, telemetry).
2. Encryption: in transit and at rest, who holds the keys, and whether customer-managed keys (encryption keys the customer controls, so we cannot read the data without them) are an option.
3. Audit support: which reports exist, how often they are refreshed, whether the customer can run their own audit or penetration test (a controlled, authorised attempt to break into the system to find weaknesses).
   Then the concrete steps to validate: they share their requirements; we map them to our controls in a one-page table; their security team reviews the evidence; a follow-up call closes gaps.

Variant: EU data-residency CISO

Immediate response (about 30 seconds): "For EU data we can keep storage and processing in an EU region. What I need to confirm with you is which of your data would be involved and whether support or backups could involve other regions. I will send you the region architecture and our data-processing terms today." Follow-up plan: send the regional data-flow diagram; send the DPA and the list of sub-processors (third parties that handle data on our behalf); book a call with our security and legal leads on any transfer mechanism, such as standard contractual clauses (pre-approved contract terms that make a transfer of personal data out of the EU lawful), if any data would leave the region; agree a validation step, such as a proof of concept in the EU region with synthetic data.

Measurable proof to have ready

Quote facts the CISO can verify: audit report period and scope, the number of controls tested, the recovery time objective (how quickly the service is restored after a failure) and recovery point objective (how much data loss is tolerated), and uptime history. Illustrative only: do not use numbers you cannot attach evidence to.

Pitfalls

• Never say "we are fully compliant with everything." Compliance is always scoped to a framework and a service.
• Do not guess an answer you do not know. "I will confirm with our security lead and send it in writing today" is a strong sentence.
• Do not drown a first call in detail. Offer depth afterwards.

Direct answer

Do not make the customer choose between "solve every concern first" and "ignore them". Separate the concerns by whether they block the first phase, then agree a phased commitment: a first phase scoped to deliver real value without depending on the unresolved items, with each open concern written into a register that has an owner, a test that would close it, a date and a go or no-go gate (a checkpoint where both sides decide whether to start the next phase) before the phase that depends on it. The customer commits to start; the concerns remain visible and binding.

Structure of the path

1. Write the concern register. One line per concern, in the customer's words, with an owner on each side, severity, the evidence that would close it, and a due date.
2. Classify each concern as: (a) blocks phase 1, (b) blocks a later phase only, or (c) a preference or watch item. Only (a) must be closed before work starts.
3. Scope phase 1 to value that needs none of the (b) and (c) items. Keep it short enough that the customer sees results (for example, 8 to 12 weeks).
4. Schedule risk first. Put the experiment that answers each concern into the early weeks (a time-boxed technical spike: a short experiment, usually one to two weeks, that proves or disproves one risky assumption), so unknowns resolve before the money is committed to the dependent work.
5. Put gates in the paper. The statement of work (SOW, the document that defines scope, deliverables and acceptance) lists phase 2 as conditional on the concerns closing, with the closure test written down. Add an agreed exit if a gate fails (for example, the customer can stop after phase 1 and pay only for what was delivered). Sample wording: "Phase 2 begins only if the load test in Schedule B meets its stated criteria by week 6. If it does not, either party may end the engagement after phase 1, and the customer pays only for phase 1 deliverables accepted."
6. Run governance. A weekly 30-minute review of the register with both sides, and a sponsor-level readout at each gate: a short briefing for the sponsor, the executive who owns the project and its budget. Governance here means the regular meetings and rules that keep both sides accountable.

Worked example (illustrative)

A customer wants to sign for a 6-month deployment of a data platform. Four concerns are open.

Of the four concerns, two (1 and 3) block phase 1, one blocks phase 2 and one blocks phase 3. So the contract starts with a phase 1 that begins only when items 1 and 3 close in the first two weeks (a gate), delivers a first usable dashboard in 10 weeks, and has gates for phase 2 (item 2) and phase 3 (item 4).

What you say: "I hear that you want to start, and I want the first value in your hands in ten weeks. I do not want to ask you to trust me on the four open points. So let us write them down with who closes each, how we will know, and when. Two of them have to close in the first two weeks before we build, and the others become gates in the contract."

Trade-offs and pitfalls

• Hiding concerns to close the deal returns later as a failed project and a lost reference.
• Too many gates make the contract fragile and the customer reluctant. Keep gates to concerns that truly decide whether the next phase makes sense.
• Vague closure criteria ("when the customer is comfortable") are never met. Write a test.
• Phase 1 with no standalone value is a deposit on a promise. Check it can be used by itself.
• Owner without authority: a concern owned by someone with no power to close it will not close.
• What would change the plan: if one open concern is truly fatal (for example, a legal prohibition), do not start. Say so plainly and keep the relationship warm.

Direct answer

I do not argue with "next quarter" and I do not drop it either. I accept it warmly, find out what is behind it, and leave with one small dated next step that costs the buyer little. The goal is that the deal keeps a pulse during the gap, so next quarter is a continuation and not a restart.

Role-play

Buyer: "That was great. Let us revisit this next quarter."

Me: "Glad it was useful, and that is completely workable. So I plan well, can I ask what makes next quarter the right time? Is it budget timing, another project ahead of this, or something you want to see first?"

Buyer: "Budget resets in January, and we are in the middle of a platform migration."

Me: "That makes sense. Two questions so I do not call you at the wrong moment. When do you expect the migration to finish? And will this need approval when the budget resets, or is it already in the plan?"

Buyer: "Migration ends in December. We would need to put it in the plan in the first weeks of January."

Me: "Then the useful moment may be before that. If I send you a one-page summary of what we covered, with the numbers you mentioned, would it help you put it in the plan? And could we pencil in 20 minutes in early December to check where the migration stands?"

Buyer: "Sure, that would help."

Me: "Great. I will send the summary by Friday. If anything changes sooner, you know where to find me."

Why this works

• Accept first. Pushback right away signals pressure; acceptance buys the right to ask questions.
• Ask what is behind the timing. "Next quarter" can be genuine (budget cycle, a project ahead of us) or a polite no. The reason tells you which.
• Make the next step small and dated. A one-page summary and a 20-minute check-in. The buyer can say yes without having to decide the deal.
• Give them something useful. A summary they can put into their own planning document keeps us in their process.

What I listen for next

• A specific reason with a date (real) versus vague answers (likely a polite no).
• Willingness to name who must approve and when.
• Whether they accept the dated next step. If they decline even a 20-minute call, I lower the opportunity's priority and keep a light touch.

Closing without pushing

I do not ask "can we do it now?" more than once, and I do not offer a discount to pull the date forward unless there is a business reason to. Leaving well: thank them, restate the agreed step, and send a short written recap the same day so the plan is on record and the AE (account executive, who owns the commercial relationship) can see it too.

Trade-offs

Letting go gently risks losing momentum; pushing risks losing the relationship. If the opportunity has a real cost of delay for the buyer (for example, a compliance date or a seasonal peak), I would raise it once, factually: "You mentioned the audit in March. If that is the target, the work would need to start by the start of February." If there is no such cost, I do not manufacture urgency.

Direct answer

I would not pick a side. I would get both people to state what they are protecting (the CTO: access to the legacy data; procurement: low vendor overhead, predictable cost and risk), then put three options in front of the group scored against those goals, recommend one, and ask who decides and by when. My recommendation would normally be: SaaS purchase plus a vendor-supported lightweight gateway running inside the customer's network (it reads from the legacy system locally and sends only the needed data out to our cloud over one outbound connection, so nothing has to be opened up inbound), rather than a custom connector built for one customer.

Terms: SaaS is software hosted and operated by the vendor; procurement is the customer team that negotiates and manages purchases; on-premises means software that runs on the customer's own servers in their own buildings; a legacy system is an older system the company still depends on; a protocol is the agreed format two systems use to exchange data; a statement of work (SOW) is a contract document that defines a specific piece of paid work, its scope and its price; a gateway is a small piece of software that sits between two systems and translates and forwards messages between them.

Step 1: separate positions from interests

Words in the review: "Before we compare options, let me check I have both goals right. [CTO], you need the legacy systems reachable, and you do not want your engineers maintaining a fragile bridge. [Procurement lead], you want one vendor relationship, a predictable bill and no custom code to own. Is that fair?" Often the two positions are not opposed: the CTO wants the outcome (data access), not necessarily the custom build, and procurement wants less overhead, not literally zero on-premises components.

Step 2: three options, one page

Arithmetic: option A is 120 (build) + 72 (three years at 24) = 192; option B is 45. These figures are invented to show the structure; real inputs come from engineering estimates and the price list.

Step 3: recommend and test the key unknown

I recommend B, and say what would flip it: if the CTO's legacy system speaks a protocol the standard gateway does not support, A or a partner-built adapter becomes the realistic choice. So the first action is a one-hour technical check with the CTO's architect to list the legacy systems and protocols. Result decides between B and A, not opinion.

Step 4: get to a decision

• Name the decision owner (often the CTO for technical fit, with procurement approving commercial terms) and a date.
• Offer a short written summary after the meeting with the options, the check, and the decision date.
• Offer a limited-scope proof of the gateway against the one most important legacy system.
• If a custom connector remains the choice, I take it internally for product and legal approval and price it as a separate statement of work, rather than promising it in the meeting.

Pitfalls

• Siding with the technical person in the room and surprising procurement later.
• Promising a custom build with no engineering sign-off.
• Presenting every option as equally good; a recommendation with a clear flip condition is more useful.

Direct answer

I would say plainly that we do not hold that certification, in the first sentence, and then move to what the buyer actually needs: proof that the underlying controls exist. A control is a specific safeguard, for example requiring a second factor to log in or logging every administrator action. I offer the evidence we do have, a mapping of our controls to the certification's requirements (described as a mapping, not as compliance), an independent test report if we hold one, and a route to let their security team verify. I only state a timeline for obtaining the certification if the security team confirms it.

Words I would use

"We do not currently hold [certification]. What I can show you is how our controls line up with what it requires, plus an independent report on our security. If your policy strictly requires the certificate itself, I would rather tell you now than waste your time. If what you need is evidence the controls exist, let us get your security team the right material this week."

Step by step

1. Find out why they ask. Is the certificate a hard policy gate, a contract term, or a proxy for "do you run a mature security programme"? That decides the path.
2. State the gap exactly. Certifications differ: an ISO 27001 certificate is issued by an accredited certification body after an audit; a SOC 2 is an attestation report (a written opinion from an independent auditor) from that auditor, and a Type I report covers the design of controls at a point in time while a Type II covers whether they operated over a period. Say precisely what we have and do not have, and do not call a self-assessment an audit.
3. Offer substitutes that are true. Any report we do hold, a penetration test summary from a third party (an authorised attempt by outside specialists to break in, with a findings report), our answers to a standard security questionnaire (a long list of security questions buyers send to vendors), a control-mapping table, and a call with our security lead.
4. Make a status statement only if confirmed. "Our audit window is in progress and the auditor's expected report date is X" is allowed only when the security team and the auditor timeline support it. Otherwise: "I do not have a confirmed date; I will ask and reply by Friday."
5. Contract options. If the buyer wants comfort, legal and security may offer a commitment to obtain the certification by a date they can truly meet, or customer audit rights (the contractual right for the customer to check our security themselves). I do not create that commitment myself.
6. Keep the deal moving. Parallel steps: security review starts now with the substitute evidence; commercial and technical work continue; a decision date is set for the security reviewer.

Worked example (illustrative)

A buyer asks for ISO 27001. We hold a SOC 2 Type II report but not ISO 27001. I say so first, then send the SOC 2 report under non-disclosure (a signed agreement not to share it further), a control mapping showing which of our controls correspond to the requested standard's areas (labelled "our mapping, not an assessment by the certification body"), and an offer of a 45-minute session with our security lead. An excerpt of the mapping, with invented rows:

The last row shows the honesty the buyer is checking for: a gap is listed as a gap. The buyer's security team decides whether that meets policy. If not, we agree whether to pause or proceed with a contract commitment.

What to avoid saying

• "We are essentially certified", "we meet the same standard" or "equivalent": these overstate and can become a misrepresentation (a false statement that the buyer relied on, giving them legal grounds against us) in a contract.
• A date that has not been confirmed.
• Hiding the gap until the buyer's reviewer discovers it.

Trade-offs

Honesty may lose a deal with a hard policy gate; that is a better outcome than a deal that collapses at audit or creates legal exposure. What would change my approach: if the certification is a legal requirement for the buyer's sector, I flag the deal as blocked early and tell the account team.