Breach notification is the obligation to inform affected parties (regulators, customers, data subjects) when a security incident compromises personal data or breaches confidentiality. The obligation comes from multiple sources at once: GDPR (72-hour controller-to-regulator notification, controller-to-data-subject when high risk), HIPAA (60-day breach reporting), state breach-notification laws (varied timelines, all 50 US states have one), CCPA/CPRA, sector-specific regimes (FFIEC for finance, FTC Safeguards for non-bank financial), and contractual obligations in the DPA.
The contract piece is what shows up in DPAs and security exhibits. Processors are typically required to notify the controller of a security incident "without undue delay" after becoming aware of it, with specific information (nature of the incident, categories of data affected, likely consequences, measures taken). The "without undue delay" standard is the GDPR phrase; in practice, contracts often pin it to a hard window (24 hours, 48 hours, or 72 hours) because the controller needs time to make its own regulatory deadline.
The drafting trap on the vendor side is accepting an unreasonably short notification window without understanding what triggers it. "Aware of an incident" is not the same as "confirmed an incident occurred." Notification on suspicion creates a flood of false positives that desensitizes the customer to real incidents. Notification on confirmation gives the vendor time to investigate but risks missing the customer's downstream regulatory deadline. The cleanest contracts split the obligation: a quick "potential incident" heads-up at suspicion, plus a full Article 33-style report at confirmation.
Operationally, the playbook only works if the vendor has a real incident-response process behind the contract language. A contractual 72-hour clock against a vendor with no documented IR program is a paper compliance exercise. A 24-hour clock against a vendor with a tested IR runbook is a workable promise.