A deal blocker is a requirement that must be satisfied before a sales opportunity can move forward. In the SOC 2 context, it means the report is not just desirable, but necessary to unblock a specific customer or contract. That distinction helps teams decide whether compliance investment has immediate business value.
Expanded Definition
In security and compliance sales, a deal blocker is not a general interest item or a nice-to-have assurance signal. It is a prerequisite that a buyer, procurement team, or end customer has made mandatory before the opportunity can advance. For a SOC 2 discussion, that usually means the report is required to clear vendor risk review, not merely to strengthen the pitch.
The term is practical rather than technical. It is used to distinguish commitments that influence revenue timing from broader trust-building work that may help later but will not close the current gap. In that sense, it sits between commercial urgency and security governance: the organisation must prove control maturity enough to satisfy the gate that is blocking progress. The most common misapplication is treating a deal blocker as a vague objection, which occurs when teams assume the issue can be handled after contract signature instead of before procurement approval.
Examples and Use Cases
Implementing a response to a deal blocker rigorously often introduces scheduling and evidence-collection pressure, requiring organisations to weigh speed of sale against the cost of accelerating assurance work.
- A healthcare buyer refuses to begin security review until the vendor can provide a current SOC 2 report, making the report a direct prerequisite for the sales cycle.
- An enterprise procurement team will not issue a master services agreement until the supplier completes a security questionnaire and shares control evidence, including policy and audit artifacts.
- A public-sector customer requires specific compliance proof before allowing technical validation, so the absence of that proof stops the deal even if the product is otherwise suitable.
- A sales team discovers that a prospective customer’s legal and security gate depends on a documented access control program, so the compliance roadmap becomes tied to pipeline movement.
- For teams mapping security maturity to business demand, the NIST Cybersecurity Framework 2.0 can help structure the control narrative that often sits behind such gating requirements.
Why It Matters for Security Teams
Deal blockers matter because they reveal where security evidence has become a revenue dependency, not just a governance objective. When a SOC 2 report, access review, or policy set is required to move a customer forward, delays in security readiness can translate directly into lost pipeline, extended sales cycles, or stalled renewals. That makes the term especially important for teams balancing assurance work against commercial priorities.
For security leaders, the key question is not whether a control is valuable in principle, but whether the market or a specific customer has made it mandatory for transaction progress. Where the requirement touches identity, access governance, or non-human identities, weak controls around credentials, privileged access, or service accounts can also become deal blockers because buyers increasingly ask how systems are protected in practice. Organisations typically encounter the full cost of a deal blocker only after procurement or legal review stops the transaction, at which point the requirement becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-1 | Supply-chain governance frames external assurance needs that often become deal blockers. |
| NIST SP 800-53 Rev 5 | CA-2 | Security assessments and authorizations often supply the proof buyers demand before closing. |
| ISO/IEC 27001:2022 | A.5.31 | Compliance obligations frequently sit behind customer gating requirements for assurance. |
| NIST SP 800-63 | AAL2 | Identity assurance can be a prerequisite when buyers require stronger authentication evidence. |
Use governance controls to identify which customer assurance items must be ready before procurement review.
Related resources from NHI Mgmt Group
- What does the Palo Alto Networks and CyberArk deal mean for NHI governance?
- What breaks when inherited access is not re-certified after a deal closes?
- Who is accountable when inherited compromise is discovered after a deal closes?
- What breaks when identity reviews are only done at a single point in the deal cycle?
