Security and the business are deadlocked on a project. Who decides, and how?

Put both sides on the same page: one list of what the first version does, the risks and the controls each needs, with the reason for each. Most deadlocks ease when the first version is narrowed to what the blocking side can accept and the business still values. Then name who decides what's left, and set a date.

Draft for Tamir's review. Not published.

Tamir Khason · Updated · Decision guides

Write both positions against one list

A deadlock usually hides an unstated requirement on each side. Ask the business for the smallest first version that still has value, in one page. Ask security, risk or compliance for the specific controls that version needs, each with its source.

Score both proposals on the same list of user tasks and abuse cases. Rate each security finding by what an attacker could actually do with it. Some findings are style and some expose customer data.

Look for the option between cut and keep

Often both sides are right about their part. A device vendor's remote access can be approved per session, recorded, time-limited and isolated, instead of cut or kept as it is. A driver app can deliver the data the authority requires without the individual scoring drivers object to.

When a vendor says its approach was approved elsewhere, ask what that approval covered and under which rules. Then have the vendor map its design to your written requirements, step by step. When several parties dispute a process, trace real cases to see where each one stopped and who could act next.

Depending on your seat

If you're the CEO, avoid overruling one side and owning the consequences alone. Make the first version narrow enough for both to sign, put both names on the page, and set a date. Put the vendor's monthly cost of waiting in front of both sides.

If you run IT and two departments reject each other's design, frame it as a comparison against the same risks and tasks. If the deadlock is with another organization over who pays, shrink the scope to the exchanges that save both sides the most. Then let each side own its own endpoint.

What to check before you decide

  • Ask the business for the smallest first version that still has value, in one page.
  • Ask the blocking side for the specific controls that version needs, with the source for each.
  • Score both proposals on one table of user tasks, risks and abuse cases.
  • Rate each finding by what it would expose, and require fixes before launch for those touching customer data.
  • Check what the vendor's approvals elsewhere actually covered, and what it can show working today.
  • Name one owner for the customer outcome and a decision maker for cases where the parties still disagree.
  • Set a date for the first version with both sides' names on the page, and record the residual risk.

Questions people ask

AI project stuck between business and risk for months, how do I get a decision without overruling either side?

Make both sides write the same page: what the system will do in its first version, which decisions it makes alone, and which controls apply to each. Most deadlocks dissolve when the first version is narrowed to what risk can accept and business still values. It depends on whether the AI decides or advises in the first version and on what your regulator expects for automated customer interactions.

Security wants to cut a device vendor's remote access and clinical engineering says equipment depends on it, how do I decide?

Both are right about their part, so the answer is controlled access rather than cut or keep: vendor sessions approved by the hospital, recorded, time-limited, through an isolated path. Device vendors agree to this when asked properly. It depends on which devices need remote maintenance and on what the vendor's contract requires.

Digital onboarding stuck on identity verification requirements, vendor says approved elsewhere, how do we move?

Approvals elsewhere prove the flow can be approved. They don't prove it meets your regulator's reading or your own risk appetite. Get compliance to write the specific requirements the flow must meet and have the vendor show, step by step, how it meets each. Launch for a lower-risk customer segment first if the full flow needs more. It depends on your regulator's identity requirements and on which customer segments you serve.

Driver app rollout stalled over tracking objections and the authority needs the data, how do I get out of this?

Separate what the authority actually requires, usually vehicle and service data, from what the vendor's app adds, often individual scoring; the first is usually negotiable with drivers when the second is dropped or limited. Then agree rules on what is collected, who sees it and what it is used for. It depends on the authority's exact data requirements and on your labor agreements.

Who should decide when ticket refunds are stuck between several suppliers?

Assign ownership for the customer outcome and separate the underlying disputed steps. The remedy depends on evidence of each handoff and the responsibilities already agreed, with contractual disputes reviewed appropriately.

Patient app project stalled because security and product can't agree on identity and consent, how do I break the deadlock?

The deadlock usually hides an unstated requirement from each side, so write both proposals against the same list of risks and user tasks. Test each on the three most common member tasks and the two worst abuse cases. It depends on what your privacy rules require for proof of identity and on which member groups the app must serve.

Security review found issues in our partner API platform before launch and the vendor says it's industry practice, launch or delay?

Rate each finding by what an attacker could do with it through a partner, because some findings are style and some are a data breach. Fix or mitigate the ones that expose customer data, and launch with the rest tracked and time-boxed. It depends on which findings touch authentication, authorisation and data exposure.

Hospital and health fund data exchange stalled over who pays for interfaces, how do we move it?

Shrink the scope to the one or two exchanges that save both sides the most, and write a simple agreement on who builds, who hosts and who maintains each side. Standard interfaces reduce the argument because each side owns its own endpoint. It depends on which exchanges matter clinically and on whether a national or sector exchange service exists that both can use.

How I can help with this decision

Ask or talk (Free)
I give my view on how to narrow the first version so both sides can sign, and which control or privacy question usually settles it.
Review (Pay if it was worth it)
I write an independent assessment of the scope, the controls, the findings and the requirements each side relies on. I recommend a first version both sides can accept, and the conditions for it.
Retain (When it makes sense)
I stay available through the first version to review control evidence, remaining findings and the next scope decision.