So you got an investor’s attention. You made it to the due diligence stage of a request for proposals. You’re excited, and who wouldn’t be? You’re about to make some money, and, just maybe, make your dreams come true.
Meanwhile, your organization’s cyber, data, and AI practices are red flags flying, just waiting to break up your deal. Read on to learn how technical practices become dealbreakers, and discover what you can do to stop it.
Dealbreaker No. 1: You Aren’t Compliant
In most cases, cybersecurity, data privacy, and AI compliance standards are set by where the user is located, not where you are.
If your services are available to users (sometimes called “data subjects”) across different states or even countries, cybersecurity and data privacy compliance aren’t as simple as following the laws where you’re based. Investors and businesses spot failure to comply (or failure to even consider how to comply) with all applicable laws and see inexperience, unprofessionalism, and unnecessary risk.
A company headquartered in Louisiana can find itself answering to the GDPR because it offered services to someone in Dublin. Local businesses can be fined under another state’s privacy statute because the business crossed a consumer threshold it never tracked. AI governance is following the same pattern, with obligations that attach to where a system's outputs land rather than where the model or tool was built. None of this is a secret. Instead, it's the first thing sophisticated counsel checks.
When diligence surfaces a compliance gap, it rarely ends the conversation outright. Instead it can reprice the deal, undercutting your ability to reach your dream outcome. When you fail to comply, expect potential investors and partners to demand specific indemnities, an escrow holdback against regulatory exposure, closing conditions requiring remediation you'll fund yourself, and a representation-and-warranty insurer that excludes the very risk you failed to address.
The deal may survive. Your valuation may not.
Don’t want to break up? Plan for multijurisdictional compliance early, and build flexibility to conform with local requirements into your contracts.
Map your users, not your offices. Pull the data you already have, like billing addresses, IP geolocation, shipping destinations, and signup fields, and determine which jurisdictions your user base actually reaches. Most companies discover that they are subject to more and different legal requirements than they expected.
Then, update your terms of service. Make sure they are sufficiently detailed to apply in and handle requests related to applicable data privacy laws, contain correct contact information, and adequately disclose relevant data handling practices.
When you’re ready to close the deal, build jurisdictional flexibility into your contracts. Vendor agreements, data processing addenda, and customer terms drafted for a single regime become expensive to renegotiate once you've scaled. Contracts that anticipate additional jurisdictions cost far less to amend than contracts that assumed you'd never need to.
Dealbreaker No. 2: You Don’t Practice Real Consent
Consent is time, use, and purpose-specific. Purpose creep creates risk.
How you use data creates real risk for your investors and clients, even if users always click accept. Failure to obtain consent for how you use data, or failing to plan for what to do if that purpose changes, creates liability for you and your clients. If you didn’t get consent for the actual use, you may not have gotten consent.
Trouble arising because the value of data often comes from a use nobody contemplated when it was collected. You gathered email addresses to fulfill orders; three years later, someone wants to train a model on the purchase histories attached to them. If your notices never disclosed that purpose, the collection was lawful and the new use is likely not. Now, the asset a buyer thought they were acquiring is one they may be barred from using the way they want to. Moreover, if you’re already engaging in use beyond what you have real consent for, potential investors and clients go from seeing real potential for growth to real potential for regulator issues and consumer lawsuits.
Compounding the problem, consent obtained under one theory rarely converts cleanly to another. A bundled "I agree" at signup does not carry forward into a materially different processing activity, and retroactive consent is usually impractical at scale. Diligence increasingly asks not just whether you have consent, but whether you can show what each user was told and when. If the answer is a single archived terms page and a shrug, a buyer or investor may now be valuing a dataset they cannot lawfully deploy as they wish, and a client may now be assessing whether you are a vendor asset or a vendor risk.
Don’t want to break up? Create a wraparound, purpose-specific consent plan, make opt outs easy, and document consent in your data provenance.
Inventory what you told people, not just what you collected. Most companies can produce a data map; far fewer can produce the terms of service or privacy notice that was live when a given record came in. Reconstruct which consent language applied during which period, and identify the cohorts where the disclosed purpose no longer matches current use.
Treat consent as a field in your data, not a checkbox at the door. Record the purpose, the version of the applicable agreement presented, and the timestamp alongside the record itself. This is what makes provenance questions answerable at diligence, and what lets you segregate the data you can deploy from the data you can't instead of discounting the whole set.
Build a purpose-change procedure before you need one. Decide in advance who reviews a proposed new use, what triggers fresh consent versus a notice update, and what happens to records that can't be brought into scope. A company that can show how it evaluates purpose creep is in a materially different position than one explaining why it never had to.
Dealbreaker No. 3: You Aren’t Accountable for Your AI Use
You built efficiencies into your workstreams, creating, deploying, and integrating the right AI tools at the right moments for maximum productivity. When an AI tool causes a problem though, you assume that accountability rests with the tool and not the team. Opacity within your AI-integrated processes means that no one knows why a problem happened, and opacity within your team’s structure means that no one is to blame.
A client or investor hears this differently than you do. To them, an organization that cannot explain why its system produced a given output is an organization that cannot commit to it not happening again. Moreover, an organization like that cannot warrant in any meaningful way that the same problem hasn't already happened somewhere they haven't looked.
Vendor terms rarely rescue deals here. Most AI providers disclaim liability for outputs and place responsibility for use squarely on the customer, leaving you responsible for the AI tools you chose to deploy. Nor does opacity function as a defense. Regulators and plaintiffs alike treat "the model decided" as an admission rather than an excuse, and where a decision affects credit, employment, housing, or health, the absence of a human who owns the outcome is often itself the violation. Diligence will ask who signs off, on what basis, and where that's written down. "It's automated" is not an answer to any of those questions.
Don’t want to break up? Take AI Governance seriously.
Name an owner for every deployed system. Not a committee, not a department, but a person, identified in writing, who is accountable for what that system does and who has authority to pause it. If you cannot name that person for a tool already in production, you have found your first governance gap.
Log the decisions, not just the outputs. Record what the system was asked, what it returned, what a human did with the answer, and who that human was. The question at diligence is rarely "does your AI work." Instead, the question is "show me how this particular result came to be." That question is unanswerable unless you create accountability processes.
Inventory what you've already deployed. Most organizations underestimate this, because tools arrive through individual subscriptions, features switched on inside software you already licensed, and vendors who added AI to a product you bought for other reasons. You cannot govern what you don’t know. A buyer, investor, or client who discovers a system you didn't disclose will reasonably assume there are others.
Dealbreaker No. 4: You’re Un or Under-Insured for Cyber Risk
You’re halfway through closing the deal and, mid-redlines, you see it. A blank schedule, just waiting for you to fill in your cyber insurance. You don’t have a policy, or worse, you do, but you don’t know what it covers, what it excludes, whether the limits mean anything against the risk your data actually carries, or whether the ransomware and regulatory-defense provisions the buyer assumed were there were quietly conditioned on controls you never implemented. You’re unaware if the breach response panel is reliable, or maybe, you don’t even know what a breach response panel is.
Cyber policies increasingly tie coverage to specific security practices like multi-factor authentication, backup regimes, and patching discipline. An application answered optimistically two renewals ago can convert a policy you're paying for into a policy that won't respond. Meanwhile the other party’s takeaway is simple. Un or underinsurance signals that nobody priced the risk, which suggests nobody measured it, which raises the question of what else went unmeasured. A blank schedule is an unpriced liability that has to land on someone before signing. The party who noticed it first is not volunteering.
Don’t want to break up? Know your policy, how to keep it responsive, and what vendors might be guiding your breach response.
Read the application, not just the policy. The answers you gave at underwriting are representations, and coverage can turn on whether they were accurate and remain accurate. Pull the last submission, walk it against what you actually do today, and correct anything that has drifted, well before a claim makes the drift someone else's discovery.
Reconcile your limits against your actual exposure. Limits chosen when you had a fraction of your current user base, or before you began processing sensitive categories of data, are limits chosen for a company that no longer exists. Revisit them when your data footprint changes, not when your renewal date arrives.
Find out who is on your breach response panel, and whether you'd want them. Most cyber policies designate approved forensic vendors, breach counsel, and notification providers, and using someone outside the panel can mean paying for it yourself. Learn who yours are before an incident, and if the panel doesn't include breach counsel, remediation vendors, or threat actor negotiators you'd actually want on the call at 2 a.m., raise it at renewal while you still have leverage.
Dealbreaker No. 5: You Don’t Know How to Respond During a Privacy Incident or Data Breach
Picture the worst day of your business’s existence. You walk in, boot up the laptop, and instead of seeing your background and login screen, you see a ransom note. All computers are shut down, all operations are impossible, and no one knows who to call, who to tell, or what to do. Increasingly, due diligence asks about exactly the scenario.
Effective incident response depends on everyone knowing who to call and how to communicate. Employees who don’t know the difference between an incident and a confirmed breach, which creates legal responsibilities and starts the clock on response obligations, create liability in even the smallest cyber incidents. Managers who send out well-meaning client communications can trigger deadline timers, forcing information sharing before a complete investigation.
Notification deadlines usually run from discovery of a data breach as defined by law, not from the moment you see something wrong or when you feel ready to address it. Different notification deadlines run concurrently across every regime that touches your data. That means a single event can trigger overlapping obligations to notify various state attorneys general, sector regulators, foreign supervisory authorities, and your own contractual counterparties, each on its own timeline and each expecting a different level of detail. None of that pauses while you locate the plan, argue about whether this counts, or wait for a forensic answer that may take weeks.
Due diligence is testing whether the response is rehearsed. A plan that exists as a PDF nobody has opened performs identically to no plan at all, and diligence has gotten good at telling the difference. Smart clients and investors ask when you last ran a tabletop, who has authority to declare an incident at 2 a.m., whether counsel is engaged early enough to structure the investigation properly, and what happened the last time something went wrong. The company that answers those questions crisply is describing an operational capability. The company that produces a document is describing a liability with a cover page.
Don’t want to break up? Prepare to respond with a trained, informed, and communications-ready team.
Run a tabletop with the people who would actually be in the room during an incident. The people with authority to shut down operations, notify an insurer, contract partner, or regulator, or to make a ransom payment have to sit through the exercise for it to matter. Do it annually at minimum, and write down what broke. Gaps in tabletops are fixable. Gaps in breach response are often fineable.
Define who declares an incident, and make sure that person is reachable at 2 a.m. Most response failures aren't technical; they're a delay of six or eight hours while people decide whether this is real and who should be told. Name a primary and a backup, give them explicit authority to escalate without waiting for consensus, make sure they know how to contact insurance and get response started, and make sure everyone below them knows how to reach them.
Decide in advance who speaks, and give everyone else a script for saying nothing yet. A well-meant client email can start a clock or lock you into a position before the facts are in. Route all external communication to clients, press, and staff through a single named owner, and make sure counsel reviews anything that goes out regarding the incident.
Don't Want to Break Up? Get Ready Before They Ask.
Every dealbreaker in this article shares a trait: it’s a lot cheaper to fix before diligence than during it. Compliance gaps, undocumented consent, ungoverned AI, a policy nobody has read, or a plan nobody has practiced aren’t hard problems to solve when you have time. All of them are expensive, or a reason to walk away, when your dream investor or client finds them first.
Victoria J. Cvitanovic helps organizations get cybersecurity, data privacy, and AI governance in order before the money is on the table. A Certified Information Privacy Professional and Certified AI Governance Professional through the IAPP, Victoria serves as Data Privacy Officer for Rudick Law Group and as fractional Data Privacy Officer for clients across technology, healthcare, wellness, and emerging markets. Her practice covers the full arc this article describes: multijurisdictional compliance planning, consent and data provenance, AI governance programs, SOC 2, HITRUST, and ISO 27001 audit preparation, vendor and customer contracts built to scale across regimes, and incident response readiness. As a former prosecutor and litigator, she also knows how these questions look from the other side of a dispute, and she’ll use that knowledge to help you navigate them.
Whether you're preparing to raise, competing for enterprise clients who will diligence you hard, or simply trying to find out what's in your own house before someone else does, the work goes better with a head start.
vcvitanovic@rudicklawgroup.com | (212) 369-4200 | Schedule a Consultation
.webp)
