You're six months into an enterprise deal. The product demo went well, the security review cleared, and the commercial terms have been agreed on. Then their legal team comes back with two queries that weren't exactly on your radar.
The first: "Can you provide a Software Bill of Materials?"
The second: "What happens to our operations if your company shuts down?"
Neither question has anything to do with features or capabilities. Both can kill the deal.
Most vendors get caught here because they spend the whole sales cycle focused on selling the dream. These questions focus on provable, long-term continuity. If you don't have documented answers ready, the deal could be dead in the water.
Why procurement is asking these two questions now
To understand why these questions have become standard, you need to understand what procurement teams are now liable for.
The EU's Cyber Resilience Act (adopted in 2024 with SBOM documentation requirements phasing in from 2027) makes it a compliance obligation for software sold in the EU to document its components. Your buyer's procurement team can't sign off on software without that documentation. It's not that they're being pedantic. Approving software without it creates a gap in their own compliance posture.
The larger continuity pressure comes from DORA, which became enforceable in January 2025 for EU financial institutions. DORA requires organizations to document continuity plans for every critical software dependency. NIS2, CPS 230 in Australia, and FFIEC guidance in US financial services carry the same requirement. If your buyer can't show regulators a documented recovery strategy for when you fail, they'll fail their compliance audits.
This is also why these enquiries pop up late in the deal. They're not engineering or product concerns. They're dealt with during the final stages when the decision is passed to their compliance and legal teams.
Why SBOM alone isn't enough
Part of what those regulations require is visibility. A software bill of materials is a documented inventory of everything inside your software: every open-source library, every third-party dependency, every version. A buyer's security team asks for one because it allows them to scan for unpatched vulnerabilities in the software's dependencies. Any issues found fall under their own compliance risk.
But while it offers a window into the building blocks of your software, it won't help them recover if you go down. They'd have a detailed list of components and no access to the source code needed to maintain, rebuild, or migrate anything. The best they can do is put contingencies in place, but it's still only reactive risk management.
Why escrow alone isn't enough
Software escrow addresses the continuity requirement by storing your source code, documentation, and deployment materials in a secure vault managed by a neutral third party. An escrow agreement defines the release conditions: vendor insolvency, bankruptcy, discontinued support, and material breach. If one of those conditions is met, the buyer gets the materials and the support to operate independently.
It's by far the stronger recovery tool of the two. A buyer with an escrow agreement in place knows their business won't suffer if yours goes under. But escrow deposits aren't always complete. If they try to rebuild and there's something missing, they won't know what they need without an SBOM to point out the correct components.
That's why, for regulated buyers operating under CRA obligations, visibility is a separate compliance requirement. An escrow deposit without an SBOM gives them continuity without the transparency their auditors need.
How vendors combine SBOM and escrow to win enterprise deals
The regulatory need for a combination of the two is pretty obvious. And having both ready for a procurement meeting will smooth over a buyer's compliance concerns. But a procurement team will only approve what they can verify. Deposits and SBOMs can quickly become outdated as development and software improvements roll out.
Which brings us to the two-pronged solution needed to combine both tools effectively:
- Deposits (including the SBOM) need to be kept current through automatic daily syncs. This ensures the software product will never drift away from the client's ability to rebuild an up-to-date version.
- The state of the deposit needs to be verified. Meaning, a review of whether all components are present, complete, and up to date. This will determine if the software is rebuildable or not.
Codekeeper's 50+ integrations sync with your repositories to pull daily updates, so deposits aren't dependent on manual uploads. Plus, Codekeeper's verification service testing confirms deposits are complete and buildable, then issues a Software Resilience Certificate as documented proof. That certificate closes the gap between "we have escrow" and "our escrow works."
For buyers in regulated industries, the certificate satisfies DORA, NIS2, ISO 27001, SOC 2, and CPS 230 audit requirements. You're handing them the proof they need to keep their auditors happy.
One vendor who made this work
A Boston-based fintech company spent six months watching enterprise deals fall apart at the final stage. Banks, insurers, and large retailers liked the product. What they couldn't get past was the business continuity question. The vendor had already lost around $1.2 million in potential contracts because of it, and their sales cycle had stretched to nine months as risk and compliance teams ran extended assessments with no clear end in sight.
They implemented SaaS Escrow with verified deposits and built the Software Resilience Certificate into their standard sales collateral. Within six months, three enterprise contracts totaling $650,000 closed. Their sales cycle dropped from nine months to five. Their RFP win rate went up 18%. Every quarterly verification passed on the first try.
The VP of Sales claimed the certificate gave the client's CIO something tangible to take back to their compliance team. The procurement hold disappeared.
» Read the full case study and many others like it on our resources page.
So what does it take to set it up?
A major concern most vendors have is wondering how disruptive the whole process will be. It's quicker to set up than most people realize.
The escrow agreement is drafted by Codekeeper's in-house legal team, no external lawyers required, and typically done in one to three days. Source code, documentation, and deployment infrastructure are deposited via integrations with GitHub, GitLab, Azure DevOps, and others. Daily automated syncs keep the deposit current from that point on. Verification testing confirms the deposit is complete and buildable, and a Software Resilience Certificate is issued and renewed with each cycle.
Your SBOM is generated separately using a tool like CycloneDX or SPDX, then deposited into escrow alongside your source code so both sit in the same verified package. Once everything is in place, the ongoing maintenance is close to zero.
Your next enterprise prospect will ask
The procurement requirement behind both questions is getting more entrenched, not less. CRA enforcement is progressing. DORA is in effect. CPS 230 applies from July 2025. The buyers you're selling to are under increasing pressure to document software risk, and the vendors they choose are the ones who make that documentation straightforward to produce.
Getting ahead of the game makes you a more desirable, low-friction option than your competitors.
» If your deals are stalling because you don't have these procurement requirements in place, take a look at Codekeeper's software escrow verification service.
