Conflict of interest in vendor selection, and how to test for it
Every party advising you on a technology purchase has a commercial position. The useful question is not whether a conflict exists, it is whether it is capped, disclosed, and pointing somewhere you can live with. Here is how to test that in about ten minutes.
The four places conflict hides
- The advisor sells what they recommend. Resellers, VARs and most managed service providers earn on the transaction. The shortlist is bounded by what they carry, and what they carry is bounded by their own supplier agreements.
- The advisor is paid by the winner. Provider-paid models remove your invoice but introduce a gradient toward whoever pays most. Whether that gradient matters depends entirely on whether it is capped and whether it varies between the options on your shortlist.
- The evaluation criteria arrive after the vendors. This is the quietest one. If criteria are written or weighted once responses are in, they can be reverse-engineered toward a preferred answer without anybody lying.
- The incumbent wrote the requirement. Common with renewals and extensions. The specification describes the incumbent's product rather than the outcome you need, so the market cannot compete for it.
The ten-minute test
Ask these five questions of anyone advising you, and write the answers down.
A precise answer takes one sentence. Vagueness here is the finding.
The important follow-up is by how much. "It is capped" and "it is identical" are different answers, and many advisors use the first to imply the second.
If yes, that is not disqualifying, but the shortlist should then be treated as a catalogue rather than a market view.
A refusal, or a delay until responses are in, is the clearest single signal in this list.
An advisor who has never been asked this will say so. An advisor who has a register will produce it.
Testing the requirement itself
Before testing the advisor, test the document.
- Does the specification name a product, a vendor, or a proprietary feature? If so, ask what outcome that feature delivers, and specify the outcome instead.
- Can each requirement be verified by someone who was not in the room? "Must integrate with our SIEM" cannot. "Must deliver parsed events to our SIEM via a supported connector without custom code" can.
- Is there a "will not" column? Scope that is explicitly excluded is the cheapest defence against both scope creep and incumbent drift.
What good looks like in the paperwork
Three artefacts, and you should be able to ask for all three.
- A requirements register, dated and signed off, produced before vendors were approached.
- A weighted scorecard showing how each option was assessed against those requirements, with the weightings timestamped before responses arrived.
- A conflict declaration covering the advisor and anyone on the evaluation panel, naming actual commercial relationships rather than asserting there are none.
If a process cannot produce those three, it may still have reached the right answer, but it cannot demonstrate that it did. That distinction matters when the board asks why this vendor.
Applying the test to us
We would fail our own test if we claimed to have no conflict, so here is ours plainly.
CYBORIUM is paid by the provider you select. You pay nothing and receive no invoice from us. For managed services the fee is capped at 20% of revenue. For technology it is a 50/50 split. It is ongoing rather than a one-off payment.
The rate is agreed with each provider individually, so it is not identical across every provider on a shortlist. That is a real incentive gradient and we are not going to pretend otherwise.
What bounds it: the cap is contractual; providers you do not select pay us nothing, so shortlist length earns us nothing; we sell and operate none of what we recommend, so there is no margin anywhere; you contract directly with your chosen provider; and we will tell you the rate applying to any provider we have shortlisted if you ask.
Ask us question 2 above. The answer is that yes, it can vary, here is the cap, and here is the number for the providers in front of you.
Last reviewed: 7 September 2026