The Security Exhibit Your Startup Signed Last Quarter

If your startup closed its first big enterprise deal last quarter, the odds are good that somewhere behind the order form and the master services agreement (MSA) sat a document called something like Exhibit C, Information Security Requirements. It arrived after the price was settled. Counsel read it for anything strange, your account executive asked whether it would hold up the signature, somebody said it looked standard, and most of it was. It got less attention than the discount, and from now on it’s the part of the contract your customer will read most carefully.

Three things that may be sitting in yours are worth ten minutes this week.

First, if it promises to sanitize storage media in accordance with the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-88 Revision 1, it cites a document NIST withdrew on September 26, 2025, the day Revision 2 replaced it (NIST, SP 800-88 Rev. 1).

Second, if your customer writes its paper the way Oracle does, you agreed to report “without undue delay and no later than 24 hours any suspected or actual security incident involving Oracle confidential information” (Oracle Supplier Information and Physical Security Standards, June 2026). Suspected, not confirmed. The clock starts on a hunch.

Third, some clauses may be there to find out whether you read them at all. In 2014 someone who writes security contracts on the buying side described, on Hacker News, the addendum he attaches to data processing and security agreements: deliberately long, mostly routine, and containing “a handful of clauses I’ve put in that absolutely no company could reasonably agree to.” Vendors who sign without challenging them get grilled on everything they do. In a thread about Van Halen’s famous tour rider, he called them his “Brown M&M Clauses” (herghost on Hacker News, May 2014).

Each of those is good news if you find it now. The exhibit is the most specific document a big customer will ever hand you: its security team’s worry list, from multi-factor authentication (MFA) to whether its data may train your artificial intelligence (AI) features, with the customer’s regulator behind most of the clauses. Read it the way a good salesperson reads a buyer’s org chart, and it tells you what the people inside need from you to keep saying yes.

My brother Jon and I run YSecurity, and we sit on both sides of this paper. We help startups answer exhibits like these, and we sign them ourselves: every YSecurity engagement runs under a master services agreement with a security addendum. Jon and I also built Cyberbase.ai, a product for exactly this kind of paperwork, so weigh what I say about it later with that in mind. This piece is a companion to the founder webinar Jon and I hosted on October 6 about when to hire security, when to rent it, and how that timing shows up in your deals (event page).

The exhibit is also the written form of something big customers ask for out loud. On episode 104 of our podcast, Jon asked Yash Kosaraju, the Chief Information Security Officer (CISO) of a16z, which sales signals tell a startup it’s time for security leadership. Yash started with the customer.

“Some of the bigger clients would definitely ask for one, either a call with your security leader or a dedicated point of contact that they can reach out to for emergencies”

Yash Kosaraju, CISO of a16z, on episode 104

A dedicated point of contact for emergencies is the 24-hour clause in conversational form. The exhibit is where the customer writes down who that person is, how fast they answer and what they owe when something breaks.

That’s why I think of the exhibit as the part of the deal that keeps talking after the signature. What follows covers where its clauses come from, how to check each one against what your team does, and the evidence that gets a big-company reviewer to yes, starting with a System and Organization Controls 2 (SOC 2) report. Each section stands on its own; take the one you need.

The part of the deal that keeps talking after the signature

Big companies give this document a lot of names: Information Security Requirements, Security Addendum, Supplier Security Standards, Data Protection Schedule. Bank of America’s 2010 general services agreement with Cardlytics, filed with the Securities and Exchange Commission (SEC), calls it Schedule D, Information Security (Bank of America and Cardlytics, 2010). AT&T’s is the Supplier Information Security Requirements (Amdocs and AT&T, filed 2024), and Illinois calls its version a Cloud Hosting Appendix. Many deals add a data processing agreement (DPA) for personal data on top. The names vary and the mechanism doesn’t: the exhibit is incorporated into the master agreement, so every “shall” in it binds you the way the payment terms do.

Some exhibits aren’t even in the packet. The general services agreement Verizon signed with a chip supplier in 2019, filed with the SEC in 2024, requires the supplier to comply with “Verizon’s information security requirements available at” a web address, redacted in the filing, “as the same may be updated from time to time” (Verizon and GCT Semiconductor, filed 2024). You sign a link, and you agree in advance to whatever the page says next year.

Big buyers write these clauses because their regulators won’t let them hand the risk to you. In an industry letter on October 21, 2025, the New York Department of Financial Services (NYDFS) put it in one sentence: “Covered Entities may not delegate responsibility for compliance with the Cybersecurity Regulation to an affiliate or a TPSP.” A TPSP is a third-party service provider, which in this story is you. The letter’s list of contract provisions reads like the table of contents of the exhibit you signed: multi-factor authentication, encryption in transit and at rest, “immediate or timely notice” of a cybersecurity event, where data is stored, subcontractors, deletion at the end of the relationship, and “Whether the Covered Entity’s data may be used to train AI models or be otherwise disclosed to additional parties” (NYDFS, October 2025).

The federal bank regulators’ June 2023 guidance on third-party relationships has a contract checklist with a right to audit, insurance, and a provision that “specifies when and how the third party will disclose, in a timely manner, information security breaches or unauthorized intrusions” (Interagency Guidance on Third-Party Relationships, June 2023; Federal Reserve copy of the guidance).

They keep testing the exhibit after signature because they’ve learned that the questionnaire at the start misses things. In a 2019 Gartner survey of more than 250 legal and compliance leaders, 83 percent had identified third-party risks after due diligence and before recertification, and 92 percent said those material risks could not have been identified through due diligence at all. Gartner’s Chris Audet: “The only way to surface those risks was through actual engagement with the third party and through ongoing risk identification over the course of the third-party relationship” (Gartner, August 2019).

So the exhibit keeps talking. Oracle reserves the right to send you a security questionnaire “on an annual basis” (Oracle, June 2026). Illinois wants a current SOC 2 report “both at time of award and annually thereafter” (Illinois Cloud Hosting Appendix V.26.1). Microsoft’s suppliers confirm compliance “annually using an online service administered by Microsoft” (Microsoft Supplier Data Protection Requirements v12). The incident clause wakes up the first time something breaks, the audit clause whenever the customer invokes it, and the whole exhibit again at renewal, when the reassessment is graded against what you signed.

On the buyer’s side, the exhibit has a whole department behind it. At a Fortune 500 company, procurement runs the process, third-party risk tiers the vendors and schedules reassessments, legal owns the template, and the CISO’s organization writes the controls and reads the answers. The NYDFS letter tells regulated companies to “classify TPSPs based on the latter’s risk profile” and to “conduct periodic assessments” afterward. An engineer who runs cloud infrastructure at a large company described his side of that machine on Hacker News this spring.

"I have to get compliance involved. Finance involved. If there's a procurement team I have to get them involved. Probably there's a security questionnaire that my bigcorp's security team uses."

SOLAR_FIELDS, commenting on Hacker News, April 2026

On the startup side, the same document usually meets a chief executive officer (CEO), an account executive and outside counsel on the last night of the quarter. Counsel reads it as a contract, the account executive as a speed bump, and the CEO signs because the deal is real. A compliance software company described what tends to happen next: “Legal files the document as per their standard procedure, and your Security team, who is actually responsible for these clauses, doesn’t see it” (Sprinto, May 2026). At a 20-person company there may be no security team to see it.

That asymmetry is the opportunity. Your customer has people whose job is to remember what you promised. You can have the same memory with one owner and a spreadsheet, and the rest of this post is about building it.

Inside the dream customer’s playbook

Many big companies publish their supplier security terms, so you can often read your dream customer’s exhibit before it arrives. Each one tells you what a specific security team worries about.

Oracle. Oracle’s standard, June 2026 version, has one of the strictest notice clauses in our stack: 24 hours for “suspected or actual” incidents involving its confidential information. It wants decommissioned media sanitized “as prescribed in a recognized standard (e.g., NIST SP 800-88),” with certificates of destruction available on request, and it forbids using its confidential information “to train, fine tune, or evaluate artificial intelligence” without a separate written agreement. Then comes the surprise: “Multifactor authentication may be used in Supplier’s discretion depending on services” (Oracle, June 2026).

Microsoft. Microsoft’s Supplier Security and Privacy Assurance (SSPA) program runs on its Supplier Data Protection Requirements, in version 12 since March 2026. Rather than an hour count, suppliers notify “per contractual requirements, as described by applicable privacy law, or without undue delay, whichever is sooner” (Microsoft Supplier Data Protection Requirements v12). The program guide requires suppliers of software as a service (SaaS) to hold a valid certification to the International Organization for Standardization’s security management standard (ISO 27001), or another certification that covers the service, and states the stakes in one line: “New in-scope purchase orders cannot be processed until the SSPA Status turns to Green (compliant)” (Microsoft SSPA Program Guide v12). Requirement 46 is the one I keep rereading: suppliers must verify, “via voice and visual appearance,” that the person they interviewed, hired and placed with Microsoft is the same person. I read it as a direct answer to fake remote-worker schemes.

JPMorgan Chase. Its Minimum Control Requirements keep the hard numbers in the master agreement. Suppliers notify “in compliance with the contract or applicable local regulations,” and the requirements “do not limit the scope of an audit by JPMC.” The MFA list is precise: privileged sessions, external connections to the supplier’s network, applications reachable from the internet and the administration of application access (JPMorgan Chase Minimum Control Requirements, 2025).

Citi. Citi’s Requirements for Suppliers, version 9, revised September 2026, is the most detailed document we read. Suppliers notify Citi “promptly”; the document prefers the newest Transport Layer Security (TLS), with “TLS v1.3 is preferred”; it bans self-signed and wildcard certificates; it gives “180 calendar days for High-Risk issues, 240 calendar days for Medium-Risk issues” found in its assessments; it requires seven years of employment history for supplier personnel; and it bans Citi business on unapproved messaging apps (Citi Requirements for Suppliers, September 2026).

American Express. Its Data Security Operating Policy, April 2026 version, wants notice “immediately and in no case later than seventy-two (72) hours after discovery of a Data Incident,” and a Payment Card Industry (PCI) forensic investigator within five days for incidents involving 10,000 or more card numbers. Then: “The unedited forensic investigation report must be provided to American Express within ten (10) business days of its completion” (American Express Data Security Operating Policy, April 2026). Unedited is the word to notice.

Blue Cross Blue Shield of Michigan. The health insurer asks for AI disclosure in one sentence, “Supplier shall notify Buyer of any use of AI related to the Services,” and it can ask a supplier to begin a SOC 2 Type II examination within 30 days of a written request (Blue Cross Blue Shield of Michigan, February 2026).

The public sector publishes the most. Illinois wants notice “within 24 hours of first becoming aware of any actual or reasonably suspected information breach,” sanitization under “the most current revision of NIST Special Publication 800-88,” a SOC 2 Type 2 report every year, which it strongly prefers, a software bill of materials (SBOM), and no training on state data “regardless of whether the data is anonymized or aggregated” (Illinois Cloud Hosting Appendix V.26.1). California gives contractors no more than 48 hours after “discovery or reasonable belief” (California Department of General Services, Exhibit E, January 2026). The University of California allows 72 hours from “the initial suspicion of a Security Incident and/or Breach” and wants High and Critical vulnerabilities remediated within 20 business days (University of California Appendix, Data Security).

Corning, Snowflake, Cooley and Amazon. Corning wants notice within 24 hours of discovery of anything that “actually or potentially jeopardizes” its systems or the supplier’s own (Corning supplier cybersecurity requirements). Snowflake sits on both sides of the table. As a vendor it promises customers notice without undue delay and, “where feasible,” within 72 hours (Snowflake Security Addendum, January 2026); as a buyer it asks its own vendors for notice “within forty-eight (48) hours after becoming aware” (Snowflake Vendor Data Protection Addendum, March 2025). The distance between those is the negotiation range, published by one company. Cooley, the law firm, asks its vendors for notice “no later than 24 hours upon becoming aware of a data breach,” with a trigger that reaches anyone the vendor has “reason to believe” has “breached or attempted to breach its security measures” (Cooley Vendor Security Requirements). And Amazon asks developers who reach its seller data through its application programming interface (API) for notice within 24 hours of detecting an incident (Amazon seller data security guidance, September 2026).

If your target customer doesn’t publish its terms, try the SEC, where public companies file their material contracts, security exhibits included. When our research team ran the phrase “Supplier Information Security Requirements” through the full-text search of the SEC’s Electronic Data Gathering, Analysis, and Retrieval system (EDGAR), it returned 59 hits, almost all filed by AT&T’s vendors (SEC EDGAR full-text search). The numbers are often redacted. In the AT&T requirements Amdocs filed in 2024, the testing clause reads “Penetration testing at least [***]” (Amdocs and AT&T, filed 2024), a good hint that those numbers are negotiated deal by deal. Most consumer brands keep their supplier exhibits behind procurement portals; we found no public ones for Google, Apple, Salesforce, Walmart, Target, Nike, Disney or most of the big banks.

Side by side, the market is easy to read. Most of these documents pair an urgency word (“without undue delay,” “promptly,” “immediately”) with a ceiling of 24, 48 or 72 hours. The banks, Microsoft and Meta keep the number elsewhere; Meta asks developers for notice “as soon as practicable but no later than required under applicable laws and regulations” (Meta Platform Terms, February 2026).

Clause one: NIST SP 800-88 for a company that owns no disks

Start with the clause most likely to cite a document that no longer exists.

NIST published SP 800-88 Revision 1, Guidelines for Media Sanitization, in December 2014, and for a decade it was the default answer when a customer asked how its data would be destroyed. On September 26, 2025, NIST published Revision 2 and withdrew Revision 1 the same day, about two months after the draft appeared (NIST, Rev. 1; NIST, Rev. 2; NIST, Rev. 2 draft). If the exhibit you signed says “Rev. 1,” it cites a withdrawn publication. If it names no revision, expect your customer to read it as the current one.

Revision 2 changes what the standard is for. NIST’s summary of the changes says the “Focus is shifted to establishing an agency or enterprise media sanitization program,” with technique descriptions “replaced with recommendations to comply with the latest relevant standards” (NIST, Rev. 2 draft). The standard it points to for purge techniques is IEEE 2883, from the Institute of Electrical and Electronics Engineers (IEEE), which you have to buy to read (IEEE 2883-2022). The three methods carried over: clear protects against “simple, non-invasive data recovery techniques,” purge makes recovery “infeasible using state-of-the-art laboratory techniques” while leaving the media reusable, and destroy leaves it unusable (NIST SP 800-88 Rev. 2).

Then, in July 2026, NIST published a frequently asked questions (FAQ) document that answers the cloud question head-on. Using Revision 2’s term for information storage media (ISM), question 13 asks how purging is accomplished “if an organization does not own physical ISM (e.g., cloud storage).” The answer: “In these logical storage scenarios, Cryptographic Erase (CE) is often the only viable purge method. Organizations must review their cloud service agreements to ensure that keys are securely managed and that zeroization can be traceably validated.” Question 6 retires the multi-pass habit in one line: “No. Revision 2 clarifies that multi-pass overwriting is unnecessary” (NIST, SP 800-88 Rev. 2 FAQ, July 2026).

For a company whose every byte lives in someone else’s data center, that’s very good news: the method you can actually perform, destroying keys, is the one NIST expects in the cloud. Revision 2 even lists what a certificate of sanitization should record, with a sample form in Appendix C, down to the serial number, the tool version and the verifier’s signature (NIST SP 800-88 Rev. 2).

Your cloud provider handles the disks. Amazon Web Services (AWS) says that at the end of a storage device’s life it “decommissions media using techniques detailed in NIST 800-88” (AWS, Data Center Controls), and Microsoft says its datacenters use “the NIST SP-800-88 clear guidelines” and its purge guidelines (Microsoft Service Assurance). Google’s data deletion page, last updated in May 2024, still cites “NIST SP 800-88 Revision 1” and an old Department of Defense (DoD) manual known for multi-pass overwriting, DoD 5220.22-M, and commits to delete customer data “within a maximum period of about six months (180 days)” (Google Cloud, Data deletion). The physical work is being done; the page hasn’t caught up with the revision. For evidence, hand your customer the provider’s audit reports; AWS publishes its SOC 2 report twice a year (AWS SOC FAQ).

Your part is smaller, and all of it is doable. Apple’s deployment guide says erasing a device “obliterates all the keys in effaceable storage and renders all user data cryptographically inaccessible,” and mobile device management (MDM) can send that erase to Macs with Apple silicon or the T2 security chip (Apple Platform Deployment). That matches NIST’s description of cryptographic erase, which is “based on the sanitization of keys used to encrypt data.” Log the serial number, the date, the method and who verified it, and every retired laptop has its certificate.

Then keys. If a customer’s data sits under its own key, deleting that key is your purge. AWS Key Management Service (KMS) makes you schedule deletion with a waiting period of 7 to 30 days, 30 by default, and records “an entry in your AWS CloudTrail log when you schedule deletion of the KMS key and when the KMS key is actually deleted” (AWS KMS). Google Cloud’s key service defaults to 30 days before a key version is destroyed (Google Cloud KMS). Those log entries are the “traceably validated” evidence NIST’s FAQ asks for.

The trap is everything that isn’t a key. Amazon CloudWatch stores log data “indefinitely” by default, until you set a retention period (Amazon CloudWatch Logs), Amazon Relational Database Service (RDS) keeps automated backups for up to 35 days (Amazon RDS), and Google allows itself about 180 days. If your exhibit promises to delete all copies within 30 days, those numbers decide whether that’s true. The first two are settings you can change this afternoon; the third is a number to write into the exhibit.

Hacker News has its own folklore about certificates of destruction. One commenter bought an old server on eBay that still held a well-known company’s customer data, reported it, and got a call back from one of the company’s executives.

"he said he was holding a certificate of destruction for that server's hard drives and would be taking some action against the contractor that had been hired to destroy them."

_wldu, commenting on Hacker News, December 2019, in a thread with more than 60 points

Another, replying to a point about the right to erasure under the European Union’s General Data Protection Regulation (GDPR), put the customer’s view in two sentences.

"Unfortunately no right to audit. So deletion is a pinky promise."

wokkel, commenting on Hacker News, September 2026

A third, from the financial industry, explained that regulators and auditors want a certified vendor, a custody trail and a certificate, then added a caveat.

"And it doesn't mean their destruction is any better either, just that the associated red tape is."

hnbear, commenting on Hacker News, May 2023

The best-documented case of a destruction promise and reality parting ways is Apple’s. In a lawsuit first reported at the end of September 2020, Apple alleged that GEEP Canada, a recycler it hired in 2014, resold about 100,000 of the iPhones, iPads and Apple Watches Apple sent it for recycling from 2015 to 2017, and said it found out by auditing GEEP’s warehouse. Apple sought C$31 million, about US$23 million, and GEEP blamed three “rogue” employees (TechSpot, October 2020; iPhone in Canada, October 2020, after The Logic; Hacker News). Those are the lawsuit’s allegations. By Apple’s account, what caught it was the customer’s right to look.

The contract fix is one sentence. Instead of “in accordance with NIST SP 800-88 Rev. 1,” propose: “consistent with NIST SP 800-88 (current revision), including cryptographic erase for cloud storage, relying on our cloud providers’ attestations for physical media.” It names the current revision, says what you’ll actually do, and tells the customer where the physical evidence lives.

Clause two: the 24-hour clock, and who started it

This is the clause founders ask us about most, usually by asking whether 24 hours is normal. It’s common, and it comes from somewhere specific: your customer’s own clock, set by its regulator. When the incident happens at a vendor, the vendor’s notice is often what starts that clock. Here is the chain, from the top.

• An EU bank under the Digital Operational Resilience Act (DORA), which has applied since January 17, 2025, must file an initial report on a major incident within four hours of classifying it as major, and no later than 24 hours after becoming aware of it (Delegated Regulation (EU) 2025/301; DORA, Article 64).
• A US bank must notify its regulator within 36 hours of determining that a notification incident occurred, and its service providers must notify it “as soon as possible” when an incident has materially disrupted or degraded covered services, or is reasonably likely to, “for four or more hours” (Code of Federal Regulations (CFR), 12 CFR part 53).
• A New York bank or insurer has 72 hours after “determining that a cybersecurity incident has occurred at the covered entity, its affiliates, or a third-party service provider,” and 24 hours to report an extortion payment (New York cybersecurity regulation, section 500.17).
• The SEC’s amended Regulation S-P requires the financial firms it covers to make sure their service providers notify them “as soon as possible, but no later than 72 hours after becoming aware” of a breach of a customer information system, with compliance dates in December 2025 for larger firms and June 2026 for smaller ones (17 CFR 248.30; SEC, May 2024).
• A public company files a Form 8-K four business days after it “determines that a cybersecurity incident is material” (SEC, July 2023).
• Under GDPR your customer, as controller, has 72 hours where feasible to notify its regulator, while you, as processor, owe notice “without undue delay after becoming aware of a personal data breach” and no hour count at all (GDPR, Article 33).
• In the EU, the Network and Information Security Directive (NIS2) asks for an early warning “within 24 hours of becoming aware of the significant incident” (NIS2, Article 23). Since September 11, 2026, the Cyber Resilience Act has given makers of products with digital elements a 24-hour early warning on actively exploited vulnerabilities; it’s written for products, so check whether it reaches your business (Cyber Resilience Act, Article 14; Article 71).
• A business associate under the Health Insurance Portability and Accountability Act (HIPAA) has up to 60 calendar days after discovering a breach, and the Department of Health and Human Services’ sample agreement invites “a stricter timeframe for the business associate to report a potential breach to the covered entity” (45 CFR 164.410; Health and Human Services sample provisions). Providence, for one, wants vendors to “immediately report incidents impacting, or potentially impacting, Providence” (Providence).
• California and New York already require a business that holds personal information it doesn’t own to notify the owner, “immediately following discovery” in California’s words and “immediately” in New York’s (California Civil Code 1798.82; New York General Business Law 899-aa).
• Further out: India’s Computer Emergency Response Team (CERT-In) wants reports “within 6 hours of noticing such incidents” (CERT-In, April 2022); Australia gives critical infrastructure operators 12 hours for incidents with a significant impact (Cyber and Infrastructure Security Centre); defense contractors under the Defense Federal Acquisition Regulation Supplement (DFARS) must “rapidly report,” meaning within 72 hours of discovery, and preserve images of affected systems for at least 90 days (DFARS 252.204-7012); and a Department of Labor (DOL) contract clause wants any “suspected or confirmed breach” reported within one hour of discovery (DOL clause 2952.224-70).

Each layer asks the one below it for a little less, and that’s where your 24 hours comes from.

Founder after discovering the enterprise agreement requires SOC 2 compliance, a 12-hour breach notice, unlimited indemnity, customer audit rights, and service credits for downtime caused by the customer.

Ryan Walker (@rwalk_xyz) · May 21, 2026

The hours get the attention, but the word that starts the clock matters more. In the statutes and regulator rules we read, a vendor’s clock starts at awareness, discovery, determination or reasonable belief. “Suspected” shows up in the contracts written on top of them: Oracle’s “suspected or actual,” Illinois’ “actual or reasonably suspected,” the University of California’s “initial suspicion,” Corning’s “actually or potentially,” the DOL clause’s “suspected or confirmed.” Cooley’s reaches anyone who “attempted to breach” your security, which, read literally, covers every blocked login your firewall saw last night.

The customer’s side of this argument is a good one, and Okta shows why. On January 20, 2022, its security team got an alert about a Sitel employee’s account; Sitel was a support subprocessor. Okta received Sitel’s complete investigation report on March 22, about two months later and about nine hours after screenshots of the intrusion appeared online. Its chief security officer, David Bradbury, wrote: “I am greatly disappointed by the long period of time that transpired between our notification to Sitel and the issuance of the complete investigation report” (Okta, March 2022). Okta later ended the relationship (Okta, April 2022).

The market drafts land in between. The Common Paper standard DPA, drafted by a committee of more than 40 attorneys from vendors, procurement teams and law firms, says “without undue delay when feasible, but no later than 72 hours after becoming aware of the Security Incident” (Common Paper DPA; Common Paper on GitHub). The Bonterms standard sets 48 hours and then deals with the noise: “Security Incidents do not include unsuccessful attempts or activities that do not compromise the security of Customer Personal Data, including unsuccessful login attempts, pings, port scans, denial of service attacks or other network attacks on firewalls or networked systems” (Bonterms DPA v2.0). And Nada Alnajafi, a senior corporate counsel at Franklin Templeton who founded Contract Nerds, writing from the customer’s side: “Forty-eight to seventy-two hours is the current market standard for initial notification” (Contract Nerds, March 2026).

Whatever number you sign, here’s what keeping it takes. Detection that notices something at two in the morning. An on-call rotation whose phone isn’t a founder’s personal cell. A named security contact, which is Yash’s “dedicated point of contact” in contract form. A notice template that can go out with partial facts, which GDPR allows: information may be “provided in phases without undue further delay.” Counsel and a forensics firm you can reach on a weekend. And vendors of your own who tell you in time; the AWS and Google Cloud data processing addendums promise notice “without undue delay” and name no hours (AWS DPA; Google Cloud DPA). If detection and the night shift are the hard parts, they’re the core of what our 24/7 monitoring and response service runs for startups.

Clause three: the right to audit, from a 6 a.m. visit to a SOC 2 report

The audit clause is where the buyer’s worst case meets your best evidence. The heaviest version lets the customer turn up unannounced, at 6 a.m. if it likes; the lightest asks for a report you already have.

Part of the audit right is law. GDPR Article 28 requires a processor to make available “all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller” (GDPR, Article 28). If you process EU personal data for a customer, you’ve agreed to audits by statute. The negotiable part is how, and the EU’s own model clauses for processors help: “In deciding on a review or an audit, the controller may take into account relevant certifications held by the processor” (Commission Implementing Decision (EU) 2021/915).

For an EU bank’s providers of critical services, DORA requires “unrestricted rights of access, inspection and audit by the financial entity, or an appointed third party, and by the competent authority,” along with “the right to agree on alternative assurance levels if other clients’ rights are affected” (DORA, Article 30). Pooled audits, in which a group of banks audits one provider together, are one way the market makes that workable; AWS described completing one with European financial institutions in 2025 (AWS Security Blog, July 2025). US bank regulators suggest that contracts name the audit reports a bank will receive, “for example, SOC reports, Payment Card Industry (PCI) compliance reports, or other financial and operational reviews,” while reserving the bank’s own right to audit (Federal Reserve copy of the guidance).

Real contracts sit on every rung in between. At the top is the buyer from the introduction. Asked on Hacker News for an example of a Brown M&M Clause, he gave this one.

"for example, the right to audit their premises at our convenience and their expense without giving notice."

herghost, commenting on Hacker News, May 2014, in a thread with more than 240 points

The “without notice” part, he explained, would let him disrupt a vendor’s business at his leisure, since an audit uses the vendor’s people too. Most real clauses sit lower. MD Anderson asks suppliers to accommodate “a customer’s site visit for a security audit within 24 hours notice” (MD Anderson Rider 118). Meta audits developers “no more than once a calendar year unless there is a Necessary Condition,” with “at least 10 business days’ written notice (email will suffice)” (Meta Platform Terms, February 2026). Bank of America’s 2010 contract with Cardlytics allowed audits “During regular business hours but no more frequently than once a year,” at the bank’s “sole expense,” on a date within ten business days of its notice, and if an audit found the supplier “not in substantial compliance,” up to “two (2) additional such audits in that year” at the supplier’s expense (Bank of America and Cardlytics, 2010). Illinois strongly prefers a SOC 2 Type 2 report every year, and the University of California may have a qualified third party audit you “annually or as a result of a Breach” (University of California Appendix, Data Security). At the bottom, the Common Paper DPA has the customer exercise its audit rights “by instructing Provider to comply with the reporting and due diligence requirements below,” with requests that “must be in writing and made to the Provider Security Contact and may only be made once a year” (Common Paper DPA).

The biggest vendors put themselves near the bottom of the ladder by default. AWS’s data processing addendum has customers exercise their audit rights “by instructing AWS to carry out the audit described in Section 10,” meaning its own third-party audits and certifications (AWS DPA). Google Cloud lets customers audit “by reviewing the Security Documentation,” allows on-site audits only where privacy law requires them, and may charge a fee for those (Google Cloud DPA). The infrastructure under your product almost certainly works this way, so asking for the same terms on top of it is reasonable.

Founders have been meeting this clause for a long time. In 2007, one asked on Hacker News what selling to corporate clients involves, and got this answer.

"Some big companies request a right to audit in order to do business with you (which means they have the right to come over to your business and check things out whenever they want). Be prepared to deal with all this mess."

cstejerean, commenting on Hacker News, October 2007

The market version is now well established. Bonterms limits audits to the customer’s expense, an independent third party, business hours and a frequency of “no more than once annually (unless required under Data Protection Laws or in connection with a Security Incident),” and treats the audit rights the law grants as satisfied by its audit reports together with that limited customer audit (Bonterms DPA v2.0). Alnajafi’s read from the customer’s side: “Most vendors will resist full on-site audits but will accept annual SOC 2 obligations and security questionnaire responses” (Contract Nerds, March 2026). Offer that before anyone asks. A startup that leads with its SOC 2 report, a bridge letter and a penetration test summary has already answered the question the audit clause exists to ask.

Expect some buyers to push the other way. Samir Pawaskar, a security leader who advises boards and regulators, wrote in June that the right to audit “has quietly become the right to receive a curated PDF,” and that buyers have collectively decided that’s good enough (Samir Pawaskar on LinkedIn, June 2026). He thinks it isn’t. A report earns its place in lieu of an audit when it’s current and specific enough to answer the questions an auditor would have asked, so offer the bridge letter and the penetration test summary with it. Templates for both, and for the rest of the packet buyers ask for after a report lands, are in The Week After Your SOC 2 Report Lands.

There is a clause in almost every vendor contract that nobody ever uses.
The right to audit.
It is in there. Your legal team fought for it. It says you may inspect the vendor, review their controls, verify what they claim. And in most organizations, it sits untouched for the entire life of the relationship.
I understand why. Exercising it feels confrontational. It takes time nobody has. And the vendor has been fine so far, so why go looking.
But here is what that clause actually is. It is leverage you already paid for.
…

Glover M. · Cybersecurity & Third-Party Risk · September 22, 2026

Load the post from LinkedIn

The quieter promises: MFA, AI training, messaging apps, insurance

The headline clauses get the redlines. The rest of the exhibit is a list of quieter promises, each easy to sign and each a specific thing your team either does or doesn’t do.

Multi-factor authentication. Most of the bank and enterprise exhibits ask for it, and the good ones say where, like JPMorgan Chase’s list above. Signing “MFA on all access” honestly means single sign-on (SSO) with MFA enforced, MFA on your cloud console, source control and email, and a named list of exceptions, usually a few service accounts. Settle, too, who owns MFA on accounts the customer administers. When attackers stole data from Snowflake customer accounts in 2024, Mandiant found no evidence that the access stemmed from a breach of Snowflake’s own enterprise environment, and found that “The impacted accounts were not configured with multi-factor authentication enabled” (Mandiant, June 2024). Snowflake now requires a second factor for human users who sign in with a password, in a rollout finishing this fall (Snowflake documentation).

Encryption. The documents we read have settled on Advanced Encryption Standard (AES) 256-bit at rest and TLS 1.2 or higher in transit. Oracle wants AES-256 on supplier laptops and external drives too, and Illinois wants encryption that meets the current Federal Information Processing Standard (FIPS) 140 and lets the state manage its own keys. Confirm encryption for every bucket, database, snapshot and log sink, enforce full-disk encryption on laptops through MDM, and sign Illinois-style language only if you run validated cryptographic modules and support customer-managed keys.

Background checks. Citi wants seven years of employment history, and Oracle checks “all personnel,” with the depth “proportional to risk” (Oracle, June 2026). Sign for the people you actually screen, usually employees and contractors with production access, and borrow the qualifier Snowflake uses in its own addendum, “to the extent permitted” by law (Snowflake Security Addendum).

An annual independent penetration test. Oracle requires one from an independent third party “at least annually,” and Cooley and Amazon ask for annual tests too. One good external test a year against your production application and its API, with a summary you can share, covers most of these. Our penetration testing work is built to produce the report an enterprise buyer’s security team accepts, and Jon’s Pentest Once a Year? covers what buyers will add on top of the annual test in 2027.

Remediation deadlines. These vary more than anything else. Amazon wants critical vulnerabilities remediated in 7 days and high ones in 30 (Amazon seller data security guidance). The University of California asks for “commercially acceptable efforts to remediate, within twenty (20) business days, any vulnerability rated as CVE High or Critical,” meaning entries in the Common Vulnerabilities and Exposures (CVE) list rated high or critical. Citi allows 180 days for high-risk findings from its own assessments. Write a severity-based schedule you actually meet, and make sure the clock starts when a finding applies to your systems rather than at publication.

Subprocessors. Every exhibit flows down. Microsoft wants subcontractors bound to terms “no less protective of Microsoft” (Microsoft Supplier Data Protection Requirements v12), AT&T writes “no less stringent,” and Meta wants service providers to comply “as if they were in your place.” Count yours honestly, including your model provider, email, analytics, support desk and logging vendors, publish the list, and give notice of changes; Common Paper uses 10 business days’ notice and 30 days to object.

Insurance. The University of California scales required cyber coverage from $500,000 per occurrence for its lowest protection level to $10,000,000 for its most sensitive data when you hold 70,000 records or more (University of California insurance requirements). Morgan Lewis wrote last year that limits of $2 million to $5 million are not uncommon for small and medium vendors (Morgan Lewis, September 2025). Sign the limits you carry, and check additional-insured and cancellation-notice requests with your broker first.

Return and deletion. The University of California wants its data back within 30 days of the end of the agreement, with written certification; the Bonterms cloud terms give 60 days after a request (Bonterms Cloud Terms). Name your backup expiry, and use Common Paper’s fallback for copies you can’t reach: where return or destruction is “impracticable,” the provider keeps protecting what remains.

Artificial intelligence. This is the fastest-growing clause in the stack, and you’ve already met Oracle’s, Illinois’ and Blue Cross Blue Shield of Michigan’s versions. Federal agencies were told by the Office of Management and Budget (OMB) in April 2025 to make sure contracts “permanently prohibit the use of non-public inputted agency data and outputted results to further train publicly or commercially available AI algorithms” (OMB M-25-22). The market default is already on your side: the Common Paper AI Addendum says a provider “may not use Customer’s Inputs or Outputs to Train any Model” unless the cover page says otherwise (Common Paper AI Addendum). Signing honestly means knowing every model provider you send customer data to, and its training and retention terms. If your product reaches outside tools through Model Context Protocol (MCP) servers, the same honesty applies to those connections, which Jon covers in Your MCP Server Passed Review, Then It Changed.

Messaging apps. Citi’s requirements say “Communicating Citi business with Citi personnel on non-Citi approved messaging platforms, such as WhatsApp, WeChat, LINE, Slack, Signal, Telegram, iMessage, SMS, Viber, and any other interactive electronic platform, is prohibited” (Citi Requirements for Suppliers, September 2026). Read that with your sales team in mind: the friendly text to your champion about the renewal is Citi business on an unapproved platform. Tell your account executives before the first one goes out.

Most of these promises map onto controls a SOC 2 audit already tests, which is a big part of why the report shortens security reviews. If you’re still deciding whether you need one, start with our plain-English guide to SOC 2.

How to diff the exhibit against what your team actually does

Engineers already know how to compare what a document says with what a system does. It’s a diff. Do the same to the exhibit: every “shall” on one side, what your team does today on the other, and a short list of changes in between.

A security officer described his own version of this comparison on LinkedIn last week, and his reason for doing it himself is the best one I know: the lawyers can read the clause, and only the people who run security know whether it’s true.

The best use of AI I found as a CISO wasn't in the SOC. It was in contract review.
When I moved from IT into security, I never expected 20% of my job to be reviewing contracts and security questionnaires. Nevertheless, I always read every client and vendor agreement with security terms myself. Our attorneys were fantastic, but they didn't know whether we actually complied with NIST SP 800-88 or the dozens of other specific requirements buried in a client's security exhibit.
So I gave our enterprise AI my standard security exhibit and compared every new agreement against it. The AI flagged where the client's terms differed from ours and pointed me to the sections that needed a human. I still read the language myself. But I read the right parts first, and I stopped missing things.
Security questionnaires are a different story. More on that next week.
Where have you found AI actually useful in security work, beyond the SOC?

Jason Penney · Information Security Officer · September 30, 2026

Load the post from LinkedIn

1. Pull every promise into a register. Go through the exhibit and the DPA clause by clause and make one row for each “shall,” “must” and “will,” with the clause number. Give each row the fields an auditor would want: the requirement in your own words, its source clause, an owner, the control that satisfies it, where the evidence lives, and when someone last checked (Tranquility Cybersecurity on ISO 27001 A.5.31). ISO 27001:2022 has controls for exactly this: A.5.31, Legal, statutory, regulatory and contractual requirements, and A.5.20, Addressing information security within supplier agreements (ISO 27001:2022).

2. Mark the truth. Pick one of four for each row: true with evidence, true without evidence, partly true, or not yet. Be strict. In our experience a young company lands many rows on true without evidence, and those are the cheapest to fix, because the work is already happening and you only need to keep the proof.

3. Map each row to your controls. A SOC 2 report pays off twice here. Linford & Co, an audit firm, explains that a SOC 2 system description depicts the company’s principal service commitments, and that “The principal service commitments may be identified for inclusion from the contracts with user entities, in their terms and conditions, or in their service level agreements” (Linford & Co). Your contracts feed your audit, and a clause written for one customer, like a 24-hour notice window, may not appear in your system description at all. When it doesn’t, your report is silent on it and the reassessment will ask.

4. Fix it or redline it. For every row marked partly or not yet, decide: change what you do, or change what the contract says. Chad Aboud, general counsel at AudienceView, describes the vendor’s side of this in four moves, and the third is the diff itself: “take their DPA and do a map against yours” (Contract Nerds). His fourth is the register in its simplest form: copy the operational concerns into a meeting invite with the people who run your hosting and data security.

5. Give every row an owner and a date. An unowned promise is the one that surprises you at renewal. Whoever runs on-call can own the notice clause, and whoever manages your laptops can own the sanitization clause.

6. If you already signed, fix what you can and paper the rest. For rows you can’t fix inside the term, propose an amendment or side letter that says what you’ll have in place and by when, before the reassessment finds the difference for you. A dated commitment is something a third-party risk team can track. Substanto, which makes questionnaire software, put it plainly in September: “A questionnaire with 3 honest ‘not yet’ answers and clear dates tells them you have a functioning security programme” (Substanto, September 2026). Then keep the dates.

Here are five rows from a made-up exhibit typical of what we see. Take the first. Clause 7.2 promises notice within 24 hours of any suspected incident. The team has an on-call rotation, so the promise is mostly kept, but the only evidence is pager history and nothing is written down, which makes it true without evidence. The next move has two parts: write the runbook this week, and at the next amendment, propose 24 hours after confirmation.

And here is the reality check for the twelve clauses we see most, with what it takes to sign each one honestly, the evidence a big-company reviewer accepts, and counter-language that’s already market.

Clause	What it takes to sign it honestly	Evidence a reviewer accepts	Counter-language that’s market
Notice within 24 hours of a suspected incident	Night-time detection, an on-call rotation, a named contact, a notice template, counsel and forensics on call	Pager history, a written runbook, a tabletop record	48 hours after becoming aware, with unsuccessful attempts excluded (Bonterms), or 72 hours (Common Paper)
Media sanitization per NIST SP 800-88	MDM erase for laptops, key deletion for customer data, retention settings for logs and backups	Erase records, key deletion events in the cloud audit log, your provider’s SOC 2	Consistent with NIST SP 800-88 (current revision), including cryptographic erase for cloud storage
Right to audit on demand	A current SOC 2 Type II report and an audit protocol you can follow	The report, a bridge letter, a penetration test summary	Once a year, at the customer’s expense, by an independent auditor, in business hours (Bonterms)
MFA on all access	SSO with MFA enforced, and a named list of exceptions	An identity provider report	Name the scope: privileged sessions, remote access, internet-facing applications, administration (JPMorgan Chase)
AES-256 at rest, TLS 1.2 or higher in transit	Encryption on every datastore, backup and log sink, and on laptops	A cloud configuration export, an MDM compliance report	The same numbers Snowflake promises its own customers (Snowflake)
Annual independent penetration test	One external test a year on the production application and API	An executive summary or attestation letter	At least annually, by one or more independent third parties (Snowflake)
Vulnerability remediation deadlines	A severity-based schedule you actually meet	A ticket export with dates	Critical and high within 30 days, on commercially reasonable efforts (Snowflake)
Subprocessor flow-down	A complete list, bound by terms no less protective than yours	A public subprocessor page and signed agreements	10 business days’ notice of changes and 30 days to object (Common Paper)
Return and deletion within 30 days	A deletion runbook that covers replicas, logs and backups	A deletion confirmation letter and retention settings	Within 60 days of request (Bonterms), with an impracticable-copies fallback (Common Paper)
No AI training on customer data	Knowing every model provider’s training and retention terms	Model provider terms, plus any zero data retention terms you hold	No training unless the cover page allows it (Common Paper AI Addendum)
Background checks for all personnel	A screening policy for employees and contractors with production access	Screening records	Screening “to the extent permitted” by law (Snowflake)
Cyber insurance minimums	A policy whose limits match what you sign	A certificate of insurance	Requirements that match the policies you already carry (Contract Nerds)

A register with these twelve rows, filled in honestly, is the most useful security document a 20-person company can own. Reviewing contracts, from non-disclosure agreements (NDAs) to DPAs, against your own standards is also the job Jon and I built Cyberbase.ai to do.

What moves, and what doesn’t

With a register in hand, the redline gets easier, because you know which clauses you can’t meet and which you simply don’t like. The next question is which of those your customer can change.

Some clauses are the customer’s regulator speaking through the contract, and they rarely move. A bank needs its service providers to tell it “as soon as possible” after an incident that disrupts covered services for four or more hours, because its regulators’ rule says so (12 CFR part 53). A defense prime must flow DFARS 252.204-7012 down to subcontractors “without alteration,” with its 72-hour reporting attached (DFARS 252.204-7012). Healthcare business associate terms follow HIPAA’s required contract provisions (45 CFR 164.504), an EU bank’s contracts for critical services carry DORA’s audit and assistance terms (DORA, Article 30), and card networks set their own incident rules (American Express Data Security Operating Policy). When a customer won’t budge on one of these, it usually can’t. If one of these regimes is yours, our HIPAA compliance and Cybersecurity Maturity Model Certification (CMMC) Level 2 programs are built around exactly those floors.

Everything else is the customer’s template, and templates move: the hours above the legal floor, the trigger, audit frequency, notice, cost and on-site rights, whether a SOC 2 or ISO 27001 report satisfies them, insurance limits, the liability cap and remediation deadlines. Procurement teams trade these every day.

It helps to know what normal looks like. Common Paper publishes a benchmark from agreements run on its platform, which likely skew toward startups and mid-market companies. In its cloud service agreements (CSAs), “85% of CSAs select this option and sets the amount to 1x,” a general liability cap of one year’s fees; “Only 13% of CSAs include Increased Claims,” the super-cap category; and unlimited claims are “rare, appearing in roughly 1% of CSAs.” Security terms grow with the customer: “Although 37% of CSAs include a security policy, requiring some type of security policy becomes more and more likely as customers become larger enterprises,” and “Only 9% of CSAs include corporate insurance requirements” (Common Paper Cloud Service Agreement). Bonterms’ default for a breach of its security or DPA terms is an enhanced cap of “three times (3x) the General Cap” (Bonterms Cloud Terms). And TermScout’s 2021 review of 471 standard click-through agreements and 60 negotiated contracts found specific breach notice provisions in only 34 percent of the standard forms, against more than half of the negotiated ones (TermScout, August 2021). Your own paper is often quiet about notice; the customer’s exhibit is where the clock gets set.

None of this is legal advice, so run any language you plan to propose past your own counsel before it goes into a redline. Then negotiate in a way that keeps the deal moving.

Accept with clarification. Most clauses only need defining. Keep the 24 hours and add “after confirmation,” a preliminary first notice, and the Bonterms exclusion for pings and port scans.

Phase dates in. If you can’t meet a requirement today, agree to it with a date, such as “in place by June 30, 2027.” A third-party risk team can track a date, which is most of what it wanted from the clause.

Save something for procurement. Andrea Austin, then vice president of enterprise sales at InsideView, said it on a SaaStr panel: “You need to save something for procurement, because if they don’t feel like they’ve won, then they’re going to hold your deal up” (SaaStr, November 2016). Decide in advance what you can give, like 48-hour notice or an annual questionnaire, and what you can’t, like an attempted-breach trigger or unlimited liability.

Apply the rule in both directions. Jason Lemkin’s advice about your own contracts: “Whatever you do, don’t ask your customers to sign a contract you honestly wouldn’t sign without reservation” (SaaStr, January 2021). The mirror image is this post’s whole argument: don’t sign an exhibit you honestly couldn’t perform.

Turn a missing certification into a dated condition. Thomas Ptacek, writing on Fly.io’s blog in 2022: “If it helps, remember that you can probably make a big purchase order from that Fortune 500 customer contingent on getting your Type I in the next year” (Fly.io, July 2022). He also has a memorable line about what the report does in these deals.

"SOC2 is like the corporate GPL of security. It's an infectious secret handshake company security teams swap in lieu of filling out security questionnaires."

tptacek, commenting on Hacker News, May 2026, in a thread with more than 170 points

The GPL is the General Public License, the open-source license that carries its terms into everything built on it. His point is that SOC 2 spreads the same way: your customer has one, so it asks you for one.

Push back on outdated requirements, with the source in hand. A clause that asks for something current guidance has dropped is one of the easiest to move.

"and every time we get a vendor security questionnaire I just say 'no, we don't do this because it's old guidance' and link to NIST... no one has ever complained."

beaugunderson, on declining forced password rotation, commenting on Hacker News, June 2025

Watch the portal. If you click through security requirements in a customer’s supplier portal, read them like an exhibit. Common Paper’s standard terms go further and say nothing in “any Customer documentation or online vendor portal” applies unless it’s in a signed agreement (Common Paper standard terms).

When the paper and the practice drift apart

The rest of this post is about opportunity; this section is the information that makes it urgent. Courts and regulators have started reading security promises the way customers do, as statements of fact. The record follows, with what was alleged kept separate from what was decided.

Start with a judge’s sentence every vendor should read. In two rulings on July 31, 2025, in the MOVEit data breach litigation, Judge Allison D. Burroughs of the federal court in Massachusetts largely denied motions to dismiss. On claims against companies that had shared data with vendors using MOVEit, she wrote, at a pleading stage where nothing had been proven, that the allegations “suffice, if barely, to support a plausible inference that a reasonable company under the circumstances would have confirmed that the direct user’s assurances were backed up by reality” (In re MOVEit, D. Mass., July 31, 2025; National Law Review, September 2025). Your customer’s lawyers now have a reason to check whether your assurances are backed up by reality, and the exhibit’s audit and reassessment clauses are how they check.

The SEC’s case against SolarWinds tested whether a website security statement is a representation. In its October 2023 complaint, the SEC alleged that the “Trust Center” section of SolarWinds’ website held the company’s Security Statement, and that employees sent it to customers who asked about security practices (SEC complaint, October 2023). In July 2024 the court dismissed most of the case but let securities fraud claims based on that statement proceed, treating it as part of the “total mix of information” (Harvard Law School Forum on Corporate Governance, December 2025). The parties reported a settlement in principle in July 2025, and on November 20, 2025, the SEC dismissed the remaining claims with prejudice (Covington, November 2025). No court ever found the statements false, but the idea that a public security statement can matter to the people relying on it got past a motion to dismiss.

Clorox v. Cognizant is the contract version. In July 2025 Clorox sued Cognizant, which provided help desk services to it, seeking $380 million plus punitive damages over the 2023 cyberattack. The complaint alleges that Cognizant’s agents reset credentials for the attacker without following the agreed verification procedures, and says “Cognizant is on tape handing over the keys to Clorox’s corporate network to the cybercriminal” (Security Boulevard, July 2025). Those are allegations. Cognizant responded that “Clorox hired Cognizant for a narrow scope of help desk services which Cognizant reasonably performed” (Cybersecurity Dive, July 2025). Either way, the yardstick in that dispute is the procedure written into the contract.

Delta v. CrowdStrike is about the liability cap. In May 2025 a Georgia state court judge dismissed Delta’s claims of intentional misrepresentation and fraud by omission and let its negligence and computer trespass claims proceed. A CrowdStrike lawyer told The Register he believes Delta’s claims “will be capped in the single-digit-millions or otherwise be deemed meritless” (The Register, May 2025). That ruling decided only which claims survive the pleading stage.

Blackbaud shows what a vendor incident looks like in the vendor’s own filings. In its annual report for fiscal 2024, it says that after its 2020 ransomware attack “we have received approximately 260 specific requests from customers for reimbursement of expenses incurred by them related to the Security Incident,” all of them resolved, closed or treated as abandoned, and that insurers representing customers have filed subrogation claims in court (Blackbaud 10-K, fiscal 2024). That’s where an exhibit’s indemnity, cap and insurance language gets read.

The Delve story is the one founders talk about over dinner. In March 2026 an anonymous writer who described themselves as a former customer of Delve, a compliance automation startup, alleged on Substack that the company’s trust page “presented our company as fully secure before we had completed any compliance work, enabling us to close deals based on misrepresented security claims,” and wrote: “We were unable to answer most questions honestly without jeopardizing the deals we were trying to land” (DeepDelver, March 2026). TechCrunch reported the allegations, along with Delve’s response that “Final reports and opinions are issued solely by independent, licensed auditors, not Delve” (TechCrunch, March 2026), and the Hacker News thread reached 836 points (Hacker News, March 2026). These are allegations, and Delve disputes them. Days later, TechCrunch noted that LiteLLM, an open-source AI project just hit by malware through a compromised dependency, still displayed SOC 2 and ISO 27001 certifications obtained through Delve (TechCrunch, March 2026). The second quote above describes the exact moment this post is about: a buyer asking for the evidence behind an answer.

Oh damn, I thought this WAS a joke

... but no, LiteLLM *really* was "Secured by Delve" (the company that rubber stamped all of these audits, and seems to have been on the edge of fraudlent auditing, but useless for sure)

And so unspririsingly LiteLLM was compromised, badly

Gergely Orosz (@GergelyOrosz) · March 24, 2026

To be fair this was due to an OSS tool running in CI (a security scanner) being compromised (same threat actor)

Compliance is largely irrelevant

solst/ICE of Astarte (@IceSolst) · March 24, 2026

Practitioners said the quiet part on Hacker News back in 2021, in a thread about security questionnaires.

"Everybody lies on these. They'll just say a best practice, or they'll quickly run a scanner in response to the question, or they give you the policy that no one actually follows, or they'll give a partial truth, like saying that they use 2FA, when they only use 2FA in some places, etc."

lawnchair_larry, who works in security, commenting on Hacker News, January 2021, in a thread with more than 140 points

"If you're hacked and leak your customer's data, and it turns out that you materially lied on your customer's security questionnaire/due diligence, you could be sued by your customer for damages, and your insurance company could refuse to defend you."

theevilsharpie, answering whether lying on a questionnaire has legal consequences, on Hacker News, January 2021

Patrick McKenzie, who writes and podcasts about the plumbing of financial infrastructure, put the principle in one sentence on Complex Systems in March, in an episode about compliance theater: “When you say things which are untrue to induce someone to do business with you, that’s fraud” (Complex Systems, March 2026). The protection is simple to state and takes work to keep: promise what you do, and keep the evidence that you do it.

Regulators can make it personal. The Federal Trade Commission (FTC) order against Drizly, announced in October 2022, follows its chief executive, James Cory Rellas, to future companies: if he becomes a majority owner, CEO or senior officer with security responsibilities at a business that collects consumer information from more than 25,000 individuals, he must implement an information security program there. The FTC’s Samuel Levine: “CEOs who take shortcuts on security should take note” (FTC, October 2022).

And the cost of one exception is on the public record. UnitedHealth Group’s chief executive told the Senate Finance Committee in May 2024 that on February 12, criminals used compromised credentials to remotely access a Change Healthcare Citrix portal, and that “The portal did not have multi-factor authentication” (Witty testimony, May 2024). The Department of Health and Human Services put the number of people affected at approximately 192.7 million (Department of Health and Human Services, Change Healthcare questions). Most of the bank and enterprise exhibits in this post ask for MFA on remote access; that’s the line item it protects.

None of these involves a startup that signed an exhibit last quarter, and all of them point the same way. The companies that come through these moments well are the ones whose paper and practice match, and a 20-person team can get there in a week.

What makes a big-company reviewer say yes fast

Now the good news, which is most of the point. Big-company reviewers are trying to get to yes. They have a queue, a template and a risk tier for you, and the vendors who move fastest hand over the evidence before anyone asks.

A named security contact. This is Yash’s emergency point of contact again, and the Common Paper DPA builds it in as a Provider Security Contact that the parties name on its cover page. Put a name and a monitored address in the contract, and answer within a day.

A SOC 2 Type II report. Thomas Ptacek’s description of what it’s for is the most honest one I know.

"The reality is, SOC2 is a sales-enablement tool."

tptacek, replying to someone who asked whether SOC 2 is security theater, on Hacker News, March 2026, in a thread with more than 120 points

In the same comment he wrote that “the overwhelming weight of the evidence is that ~practically nobody actually reads SOC2 reports; they just check the box for each vendor and move on.” The tilde is his, shorthand for “roughly.” Plan for both readers: a current report closes the box for the reviewer who checks it, and the rest of this list gives the reviewer who reads it something to find. If you need the report itself, our SOC 2 Type 2 program runs it end to end.

A trust center. A security person at a large enterprise described the baseline on Hacker News: “I’d expect some kind of audit, pentest results, and more available in some type of trust center. And that’s before we even send a security questionnaire that digs into your processes and controls” (hiatus on Hacker News, May 2025). In Whistic’s 2022 survey, “80 percent of vendors said they would be willing to make security documentation available publicly to customers and prospects” (Whistic, May 2022). Publish what you can, and put the rest behind a click-through NDA.

We're aware of recent reporting about Delve’s compliance practices. Lovable is not a Delve customer. We proactively moved to Vanta in late 2025, before any of this came to light.

Our SOC 2 Type II was independently audited by Prescient Assurance. We’re currently undergoing an independent internal audit of our ISMS, recertifying ISO 27001, and have our next SOC 2 Type II scheduled for Q3 2026.

Security is not an afterthought at Lovable. It's a company-wide commitment backed by a dedicated team and continuous investment. Our current compliance practices are all here:

Lovable (@Lovable) · March 20, 2026

A penetration test summary. The NYDFS letter tells regulated companies to review “security attestations (e.g., SOC2, ISO 27001), penetration testing summaries” when they assess vendors (NYDFS, October 2025). A short summary from an independent tester, less than a year old, answers a whole section of most questionnaires.

A certificate of insurance. The bank regulators’ guidance expects contracts to have vendors “provide evidence of coverage, as appropriate” (Federal Reserve copy of the guidance). Get the certificate from your broker once and keep it in the folder.

Fast, honest answers. This one costs nothing but attention.

"it was a huge competitive advantage to have someone who knows their stuff (a founder who wrote most of our code) complete them fast and get them back."

BlueTie, who ran sales at a startup, commenting on Hacker News, June 2023

The data says speed is worth real money, with the caveat that most of it comes from companies that sell the fix. Whistic’s 2022 surveys of 315 security respondents and 303 SaaS sales respondents found that 45 percent had seen deals pushed back because they couldn’t respond to a security review in time, 34 percent had lost a deal for the same reason, and salespeople spent more than 10 hours a month on security reviews (Whistic, May 2022). SecurityPal reported last month that “Questionnaires now average nearly 100 questions” and that “August, September, and October are the busiest months for security questionnaires,” which means right now (SecurityPal, September 2026). The Standardized Information Gathering (SIG) Lite questionnaire runs roughly 125 to 150 questions depending on the release, and SIG Core runs to several hundred: 825 in the 2022 release by Drata’s count, and 855 in the figure I used when I wrote about questionnaire growth for Cyberbase in April. The SIG is revised on an annual cycle, which is why published counts differ (Drata, February 2026; ComplyDog, August 2026; Cyberbase, April 2026). Vanta, another vendor, says “the average company spends 5-15 hours on each security review” (Vanta, via the Cloud Security Alliance, March 2025). Discount them as vendor numbers and they still point the same way.

Just had a company asking me to complete an 82-question security questionnaire so that *they* can use Vue Devtools, for free.

Ironically the compliance questionnaire service they are using is built with Vue 😂

Evan You (@evanyou) · February 16, 2023

The clearest example of an exhibit acting as a deal gate is still Microsoft’s: no new purchase orders until a supplier’s SSPA status is Green, and for new suppliers, “work cannot start until this is complete” (Microsoft SSPA program). A vendor whose status stays Green has a sales advantage it built in the back office.

Jon described the person who makes all of this work on episode 104, contrasting two kinds of security people who can walk into the same meeting. The first makes the room brace for delays. The second is the one the room is glad to see, he said, because that person helps everyone “understand what are our security commitments to our in-house goals and our customers.” For a vendor, the commitments to customers are the exhibit.

Listen · Jon McLachlan on episode 104, from 19:07

Jon wrote up the rest of that conversation with Yash in The Human in the Loop Is Going Away.

We sign these too

I’ve spent this whole post on your customer’s paper, so it’s fair to say how we handle ours. YSecurity is a vendor too. Every engagement we run sits under a master services agreement with a security addendum, and we hold ourselves to it the way this post suggests you hold yourself to yours: a register of what we’ve promised and to whom, a named contact for security issues, and evidence we keep current instead of assembling it when someone asks. It’s unglamorous work, and it’s what keeps a reassessment from turning into a project.

This is also where the companion webinar comes in. The wrong security hire burns a pipeline in a specific way: nobody owns these promises, so every exhibit becomes a fire drill and every reassessment a surprise. The right hire, in-house or on-demand, keeps the register. We wrote up the trade-offs between building a team, renting one and going without in In-House, On-Demand, or YOLO?, and the case of a fractional security leader for the day a buyer asks to meet yours in What Is a vCISO?, vCISO being short for virtual Chief Information Security Officer.

If you want the founder’s tour of the frameworks these exhibits lean on, Jon and I recorded one in February 2024, the introduction to our Founder’s Guide to Compliance on episode 37.

Listen · Jon McLachlan and Sasha Sinkevich on episode 37

One week to know what you promised

You can do all of this in a week without hiring anyone first. Here’s the version we’d run.

Day 1: Find every exhibit. Search your shared drive and your customer relationship management (CRM) system for Exhibit, Addendum, Security Requirements and DPA, including anything accepted through a supplier portal. Note each customer’s renewal date as you go.

Day 2: Register every promise. One row per “shall,” with the clause number, in one spreadsheet across all customers. Where two customers ask for the same thing in different words, the strictest version is the one you have to meet.

Day 3: Mark the truth. True with evidence, true without, partly, not yet. Ask the people who do the work rather than the people who wrote the policy, and attach the proof to every row marked true with evidence.

Day 4: Fix the fast ones. MFA on the service accounts that don’t have it, key deletion in your offboarding runbook, retention settings on logs and backups, a real on-call rotation. Most of it is configuration, and each fix turns a promise into something you can show.

Day 5: Write the incident path. A named contact, a notice template that can go out with partial facts, and a decision about who calls the customer and who calls counsel. Then check what your own vendors promised you, so the path doesn’t depend on luck.

Day 6: Paper the rest. An amendment or a side letter for what you can’t meet yet, with dates, sent before the reassessment asks.

Day 7: Own it. Give the register an owner, put the renewal dates on a calendar, and write the fallback language you’ll propose in the next deal, so the next exhibit starts from your playbook.

When you report it to your board, the register is the second row of the security slide your board deck is missing: what changed since we last looked, on both sides of the contract.

If you’d like a second pair of eyes, send us the exhibit. Our Sales Support team reads it the same day and tells you what we’d keep, fix and redline, working alongside your counsel, and if a reviewer is waiting on a questionnaire, we’ll take that too. And if you’d rather review your contracts against your own policies and playbook, Cyberbase can do that inside your own cloud account.

The exhibit you signed last quarter will be read again: at the reassessment, at the first incident, at the renewal. Each reading is a chance to show your customer that your paper and your practice say the same thing.

Sign what you can show.