Contractual Obligations in Tech Contracts

The most dangerous clauses in vendor contracts aren’t the ones you fight over. They’re the ones you skim past—(em dash mine 😑) the “standard” terms that seem harmless until they explode. Just ask Morgan Stanley. Overlooked contractual gaps turned a vendor’s mishandling of client-data-bearing equipment into hundreds of millions in fines, settlements, and penalties for Morgan Stanley. I have identified some top of mind examples: #1: The Subcontracting Black Hole Most vendor contracts include innocent-looking language like: "Vendor may engage subcontractors as necessary to perform services." The problem: You have zero visibility into who's actually handling your sensitive data or critical operations. What Morgan Stanley missed: Their vendor subcontracted the actual data destruction to an unqualified third party. The fix: • Require prior written approval for all subcontractors • Mandate the same security/compliance standards flow down • Include right to audit subcontractors directly • Cap subcontracting to specific, pre-approved functions #2: The Liability Cap Loophole Standard cap: "Vendor's liability limited to fees paid in preceding 12 months." The hidden trap: This covers the vendor's mistakes but not the regulatory fines, customer lawsuits, and reputational damage you'll face. What to negotiate: • Separate caps for different types of damages • Higher caps for data breaches and regulatory violations • Unlimited liability for gross negligence and willful misconduct • Minimum insurance requirements that match your actual risk exposure #3: The Termination Cost Surprise Innocent clause: "Upon termination, vendor will assist with transition for 30 days." The trap: No mention of data extraction, migration costs, or knowledge transfer requirements. Real example: A SaaS company switching CRM vendors discovered "transition assistance" meant read-only access to export screens. Manual data extraction cost $47K in consulting fees. Protection strategies: • Define data export formats and timelines • Cap termination assistance fees • Require knowledge transfer documentation • Include escrow provisions for critical operational data #4: The Change Order Cash Grab Standard language: "Any modifications require mutual written agreement." The hidden cost: No controls on pricing for change orders or scope creep. Pattern I see: Vendors lowball initial proposals then recover margins through change orders priced at 200-400% markup. The armor: • Cap change order pricing as percentage of original contract value • Require detailed justification for scope changes above set thresholds • Include right to third-party validation for major change orders • Build in quarterly spend reviews with automatic triggers The point is, most "standard" vendor contracts are written to protect vendors, not you. Don't let your "standard" vendor agreement become someone else's cautionary tale. Dig deep. #VendorManagement #ContractReview #RiskManagement

Silent Red Flags in a Contract Not all contract risks are obvious. Some don’t wave big red flags they sit there quietly, sipping coffee, waiting to ruin your day when it’s too late. Here are a few sneaky ones to watch out for: 1. Termination Notice that has a trap ex: “Either party may terminate by giving a 90-day prior written notice by registered post.” This sounds fine until the other party refuses to accept mail, leaving you stuck. Flexibility in notice delivery methods (emails, RPAD, etc.) helps avoid this. 2. Auto-Renewal that feels like some subscription you forgot to cancel ex: A contract that auto-renews unless terminated 60 days before expiry. Missed the deadline? Congratulations, you just bought another term of commitment. Always check renewal terms and negotiate flexibility. 3. ‘Reasonable Efforts’ without a guiding light ex: “The service provider shall take all reasonable steps to ensure 99.5% website up-time.” Reasonable to whom? The client? The universe? Always define obligations with measurable standards. 4. Confidentiality that lasts forever ex: “The receiving party shall never disclose or use the confidential information.” Never is a long time, longer than some companies exist. A well-drafted clause should account for practical realities (disclosures required by law, etc.). 5. One-sided dispute resolution ex: “All disputes shall be resolved by arbitration, and the Party A shall appoint the arbitrator.” Agreeing to this means you’re going to their turf every time. Always ensure jurisdiction and dispute resolution are neutral. 6. Hidden costs in referenced documents ex: The main contract looks great, but a linked “Standard Terms & Conditions” document quietly adds extra fees, penalties, and other nightmares. Always review referenced docs. for no surprises. 7. ‘Best efforts’ vs. ‘Commercially reasonable efforts (CRE)’ ex: “The contractor shall use its best efforts to complete the project on time.” Best efforts could mean working 24/7 with unlimited resources. CRE = practical, business-minded execution. Choose wisely. 8. Non-Compete clauses that overreach ex: “The employee shall not engage in a competing business at any time in the future.” is a legal life sentence. Restrictions ought to be reasonable in scope, and duration. 9. Force Majeure that helps one side ex: “In case of an unforeseeable event, Party A is excused from obligations.” And Party B? Well… good luck. Force majeure should work both ways. 10. Silent Assignment clauses ex: You sign a contract with a trusted vendor, only to realize they’ve assigned their obligations to an unknown entity. Avoid unpleasant surprise, and require written consent before assignment. A little ambiguity is unavoidable. But when vagueness creates risk, or gives one party too much control, that’s when alarms should go off. #ContractReview #InHouseCounsel

Flow-down risk has always been a challenge in supply chain contracts. But has become a more urgent issue with AI contracts. The fast pace of change and the lack of contracting leverage make this a tough risk to manage. Flowing down obligations to a vendor requires that we make sure our AI product vendors are complying with the restrictions and obligations we agreed to with our own customers. That means if we agreed to deletion in 30 days, the vendors we use to provide the service to the customer must do so as well. In our dream world, that would happen for all our contractual relationships. But we live in the real world with good-enough contracting and managing impossible risks. So if we can't create a perfect flow-down world, where should we prioritize our efforts? This will always be a "it depends" answer, but here are my four critical areas: 1. Definitions - We have to make sure that the defined terms used in our customer obligations match the obligations made to us by our vendors. Pay attention to the specific definition language, any carve-outs, and what data types are covered. Make sure your vendor contracts are mirroring those. For one-to-one flow downs (meaning the vendor’s scope is limited to one customer), use the exact same language. 2. Data Deletion Requirements - Vendors interpret "delete your data" differently. Does it mean permanent erasure? Within what timeframe? From all systems including backups? Rather than assume they understand, make it verifiable by requiring an affirmative confirmation of deletion within 30 days of written request. 3. Data Usage - Be explicit in your vendor contracts about data usage limitations. Decide if it is worth adding any special or unique customer requirements in your standard vendor contracting documents. It may be easier to remove it from your standard terms when it doesn't apply than to affirmatively insert it each time it does. 4. Security Standards - Make sure that the security frameworks you require in your vendor contracts align with what customers require. When the customer requires an updated or different standard, make sure that is passed down to your vendors too. What others should be added? Which are your top four? #Contracts #AIContracts

Half the internet napped yesterday, and everyone blamed Cloudflare. But the real story is not that a single provider can take huge chunks of the web with it. The real story is how fast you did, or did not, reach for your contracts. Most organizations discovered a quiet gap. Systems went down in minutes. It took hours to answer three basic questions: What did our vendor promise? What happens when they fail? What can we actually do about it? Here are the uncomfortable patterns I see over and over: We negotiate SLAs like our business depends on them, then file them away where no one can find them. We accept service credits as if they meaningfully offset reputational damage and lost sales. We rely on tribal knowledge instead of market data to decide what is acceptable risk. Outages are not just infrastructure failures. They are live fire drills for your legal and commercial readiness. Three practical takeaways if this rattled you. Treat SLAs as an operational tool, not a legal artifact. Your IT, legal, and business teams should all know, in plain language, what “down” triggers and who does what. Look at the actual economics of your remedies. A month of discounted service will not fix a blown launch or missed quarter. If the math does not work, your risk is mispriced. Measure how long it takes to get a clear answer from your contracts during an incident. That response time is as important as your technical RTO. Contract intelligence is about speed to clarity. If this outage felt chaotic, that is not a Cloudflare problem. That is a signal about how you manage vendor risk, contractual trust, and legal debt. Pick one mission-critical vendor and do a no-drama review of your SLA, liability, and incident clauses. Your future self, on the next bad internet day, will thank you. -------- Olga V. Mack Building trust and creating new categories at the intersection of contract intelligence, commerce, and AI. Let’s shape the future together.

DPDP Act Decoded #27: Using Data Processors Lawfully — What a “Valid Contract” Must Cover Many organisations assume DPDP compliance can be handled through a standard vendor DPA. That is not what the law says. The Act permits engagement of a Data Processor, for any activity related to the offering of goods or services to Data Principals, only under a valid contract. But it does not define that phrase or prescribe a clause-level checklist. So the real question is not “What template do we use?” It is: what must the contract enable the Data Fiduciary to do, given its non-delegable obligations? Three things matter in practice. 1. Responsibility does not shift Section 8(1) is explicit. The Data Fiduciary remains responsible for complying with the Act and Rules in respect of processing carried out by it or on its behalf by a Data Processor. A processor agreement is not just a procurement document. It is part of the Data Fiduciary’s compliance architecture. 2. The contract must enable control where the Act requires it Processing under DPDP must rest on a lawful purpose, whether through consent or certain legitimate uses. While the Act does not expressly prescribe “instruction clauses,” the strongest reading is that the contract should bind the processor to purpose-linked processing requirements and enable the Data Fiduciary to exercise control where the Act requires it. This matters because: • if consent is withdrawn, the Data Fiduciary must cause its processors to cease processing • where erasure is required, the Data Fiduciary must cause its Data Processor to erase the personal data made available to it That outcome is only possible if the contract creates enforceable control. 3. Security is now expressly a contractual issue Rule 6(1)(f) makes one point explicit: the contract should contain appropriate provision for taking reasonable security safeguards. Read with Section 8(5), this means security cannot be left as an implied expectation. This is not implied compliance. It is contractual design. In practice, the contract should support access controls, logging and monitoring, breach response support, and retention and erasure workflows. It should also be drafted with Rule 8(3) in view, because the Rules require retention of certain data and logs for at least one year before erasure in specified cases. So what is a “valid contract” under DPDP? The Act does not define it. But the safest reading is this: a processor contract should be structured so that outsourcing does not disable the Data Fiduciary from complying with its own statutory duties. The real takeaway Under DPDP, you can outsource processing. You cannot outsource accountability. Relevant provisions • Section 2(i), 2(k) • Section 4(1), 4(2) • Section 6(4)–6(6) • Section 8(1), 8(2), 8(4), 8(5), 8(6), 8(7) • Rule 6(1), especially clause (f) • Rule 7 • Rule 8(3) #DPDP #DPDPAct #DataProtection #DataPrivacy #PrivacyLaw #IndiaLaw #Compliance #DataGovernance