competing with the bundle the customer already owns

When a buyer says “we already have it in our platform licence”, find out three things before you defend your product: whether the bundled feature is licensed at the tier they need, whether it is deployed and owned by someone, and whether it covers the risk this buyer cares about. If it is deployed and covers that risk, walk away or offer to complement it. If it leaves a gap, sell into the gap, prove it in a test on the buyer’s own criteria and count the full cost of both options honestly. Arguing that the platform is worse rarely works, and it turns the people who chose it into opponents.

the bundle objection is a no-decision with a price of zero

Most of the time “we already have it” is a status quo objection. The buyer is telling you that changing nothing costs nothing, and that someone above them signed the platform agreement for good reasons. The guide on why deals stall in no decision separates two causes: a buyer not convinced that change is worth it, and a buyer who wants to change but is afraid of choosing wrong. The bundle feeds both. It makes doing nothing look free, and it makes buying a second product look like a mistake someone will have to explain.

So treat it the way you would treat any no-decision risk. Find out whether the objection describes the buyer’s real situation or a reflex. A licence that includes a feature is one fact. A feature that is switched on, tuned, watched by a named person and covering the systems that matter is a different and much rarer fact.

There is also a fairness point that affects how you sell. The platform vendor’s product may be the right answer for this buyer. Your job is to help the buyer find out, on their criteria, in a way that their own architect and their CFO will accept. If you cannot do that without running down the incumbent, the deal is probably not yours.

qualify the bundle in the first call

Ask four questions early, ideally before any demo:

1. Which licence tier do you hold, and does the capability you need sit in it? Platform vendors package capability by tier, and the buyer’s administrator often knows the tier while the security lead does not.
2. Is it deployed, on which systems, and since when? Ask for coverage in the buyer’s own numbers: endpoints, servers, accounts, cloud subscriptions.
3. Who owns it? A feature without an owner produces alerts nobody reads. A feature with an owner who built it means a person whose work your product would replace, and that person will sit on the evaluation.
4. What risk were you trying to cover when you started looking? This is the question that decides the deal. The bundle is only a competitor for the risk it actually addresses.

The answers place the deal in one of four positions, each with its own play.

Four positions against a bundled feature

bundled feature deployed and owned →

deployed, leaves a gapSell alongside it, scoped to the gap. Test only the gap.

deployed, covers the riskWalk away or offer a complement. Keep in touch for the next trigger.

not deployed, leaves a gapOpen contest. Compare the full cost of deploying each option.

not deployed, would cover itThe trap: your POC can become the reason they switch the bundle on.

bundle covers the risk this buyer cares about →

The bottom right deserves a warning. When the licence is owned but unused and the feature would cover the need, you are competing with a deployment project. A detailed evaluation from you can show the buyer exactly what to switch on. If the gap is small, say so and save your engineers’ weeks.

find the gap that matters to this buyer

A gap only counts if this buyer cares about it. Feature lists produce long gap tables that nobody on the buying committee reads. Five kinds of gap tend to matter to security buyers:

• Coverage. Systems, platforms or account types the bundled feature does not reach, or reaches only with another licence.
• Depth. A capability that exists in both products but works differently for the use case at hand, such as how far an investigation goes or how fine-grained a control is.
• Operations effort. Hours of skilled work per week to tune, review and maintain each option in this buyer’s team.
• Separation of duties. Whether the people who administer the platform should also control and review the tool that watches them.
• Vendor concentration. How much of the security stack would depend on one supplier’s contract, roadmap and outage.

Read the platform vendor’s own licensing documentation before you claim any coverage gap, and quote it. For example, Microsoft’s documentation, as of November 2026, states that Microsoft 365 E5 and Microsoft 365 E5 Security include Defender for Endpoint Plan 2, and that Defender for Endpoint Plan 1 and Plan 2 do not include server licences, which need another licence such as Defender for Servers. That is a fact about packaging, and it says nothing about quality. It tells you which questions to ask about tiers and servers, and the buyer can check it in a minute.

what the bundle includes

from the vendor's own licensing pages

• The capabilities in the tier the buyer holds
• The systems that tier covers
• What needs a higher tier or a separate licence

what this buyer needs

from discovery, in their words

• The risk that started the project
• The systems and accounts where that risk sits
• Who will run it, and with how many hours
• Who must be kept separate from whom

concentration risk, stated accurately

Concentration risk is a legitimate topic, and it is easy to overstate. For financial entities, DORA (Regulation (EU) 2022/2554) has applied directly since 17 January 2025. Its Article 29 asks them, when they assess a contract for ICT services that support critical or important functions, to take into account whether the provider is not easily substitutable and whether they would hold multiple arrangements with the same or closely connected providers. It also tells them to weigh the benefits and costs of alternatives, such as using different providers.

NIS2 (Directive (EU) 2022/2555) works through national law. Article 21(2)(d), as transposed into national law, requires essential and important entities to address supply chain security, and Article 21(3) asks them to take into account each direct supplier’s vulnerabilities and the quality of its products and practices.

Neither text says a customer must avoid buying several products from one vendor, and both put the assessment with the customer. Use them to prompt a question the risk team may already be asking: how substitutable would this capability be if it stayed inside one supplier’s agreement? Then let the customer answer. This is general information as of November 2026, not legal advice.

test the gap on the buyer’s own criteria

If the deal sits in one of the two gap positions, propose a test scoped to the gap. Write the success criteria with the buyer, in their language, before anything is installed, and include the bundled feature in the test where the buyer can run it. A side-by-side test the buyer designed is more persuasive than any comparison you publish, and it protects you from the charge that you picked the ground.

The guide on running a security POC that ends in a decision covers the entry gate, signed criteria and the readout. Two points apply with extra force here. First, invite the platform owner to help design the test, because that person will judge the result anyway. Second, keep the scope to the gap. A broad test turns into a feature war on the platform’s home ground.

Before the test, a short demo that opens on the buyer’s problem shows the gap faster than a tour of your console. Show the systems or the use case the bundle does not reach, in their terms, and stop there.

count the full cost of the free option

The bundled feature has a licence line of zero, or close to it. The full cost is wider, and so is yours. A business case that counts both sides in the same categories is the one finance will believe. The guide on a security business case the CFO reads to the end covers how to build one with the buyer and haircut your own numbers.

cost line	the bundled option	your product
licences	any tier upgrade or extra licence the needed capability requires	your subscription
deployment	engineer days to switch on, configure and extend coverage	engineer days to deploy and integrate
operations	weekly hours to tune and review, at the buyer’s rates	weekly hours to tune and review
remaining gaps	what stays uncovered, and how the buyer handles it today	what your product does not cover
exit	effort to replace it later	effort to replace it later

Fill every cell with the buyer’s numbers, and ask their platform owner to check the left column. If the honest total favours the bundle, tell the buyer. You lose this deal and keep the account’s trust for the next one.

when to walk away, and when to sit next to the bundle

Walk away when the bundled feature is deployed, owned and covers the risk this buyer cares about. Walk away too when the buyer cannot name a gap after two conversations, or when the platform owner will not take part in any evaluation. A deal that no one will test is a deal no one will sign. If you are unsure which kind of stall you are in, the no-decision deal check helps you sort it.

Position as a complement when the gap is real but narrow. Scope your offer to the systems, use cases or separation the bundle does not provide, show that your product works next to the platform, and price the first step so it is easy to approve. Complements are easier to buy because nobody has to admit the platform decision was wrong.

the next “we already have it”

Answer with a question instead of a comparison: “Which risk did you want to cover when you started looking, and does what you have reach it today?” If the answer is yes, thank them and leave on good terms. If the answer is “not quite”, you have the start of a test the buyer will own.