Privacy laws rarely list security controls. They say "appropriate" or "reasonable" and leave you to work out what that means for your data. Regulators then work it out for you after a breach. This page translates the legal language into the controls that keep coming up, and collects the notification deadlines you will be racing if those controls fail.
We build the controls described here. Opsware designs and implements infrastructure, access controls, secrets handling and monitoring as part of its DevOps work.
It is written for the privacy lead or engineer who needs to show that the security program covers personal data properly, not for a security team building one from scratch. Frameworks such as ISO/IEC 27001, SOC 2 and the NIST Cybersecurity Framework go much further; the point here is the overlap with privacy law.
What the laws actually say
GDPR Article 32. Controllers and processors must implement "appropriate technical and organisational measures" to ensure a level of security appropriate to the risk, taking into account the state of the art, cost, and the nature and purposes of processing. The article names four measures "as appropriate": pseudonymization and encryption; the ability to ensure ongoing confidentiality, integrity, availability and resilience of systems; the ability to restore availability and access in a timely manner after an incident; and a process for regularly testing and evaluating the effectiveness of the measures (Regulation (EU) 2016/679). The UK GDPR carries the same text.
California. The CCPA requires businesses that collect personal information to implement reasonable security procedures and practices appropriate to its nature (Cal. Civ. Code 1798.100(e)), and gives consumers a private right of action when certain unencrypted or unredacted personal information is breached because of a failure to do so (1798.150). Statutory damages under that section were adjusted for inflation in 2025 to between $107 and $799 per consumer per incident, or actual damages if greater (CPPA announcement).
California's cybersecurity audit regulations. Approved in September 2025 and in effect since January 1, 2026, these require an annual independent cybersecurity audit for businesses whose processing presents "significant risk to consumers' security," defined as either deriving 50% or more of annual revenue from selling or sharing personal information, or meeting the CCPA's revenue threshold and processing the personal information of 250,000 or more consumers or households, or the sensitive personal information of 50,000 or more consumers, in the preceding year (11 CCR 7120). First audit reports are due on a schedule set by revenue:
| Annual gross revenue | Audit period | First report due |
|---|---|---|
| Over $100 million (2026 revenue) | Jan 1, 2027 to Jan 1, 2028 | April 1, 2028 |
| $50 million to $100 million (2027 revenue) | Jan 1, 2028 to Jan 1, 2029 | April 1, 2029 |
| Under $50 million (2028 revenue) | Jan 1, 2029 to Jan 1, 2030 | April 1, 2030 |
After that, audits are annual, with an executive's certification of completion submitted to the agency (11 CCR 7121, 7124; final regulation text). The regulations matter beyond California because they are the most specific list any US privacy regulator has published of what a security program for personal data should contain. That list drives most of the sections below.
Other US state laws. The comprehensive state privacy laws modeled on Virginia's require controllers to maintain reasonable administrative, technical and physical data security practices appropriate to the volume and nature of the data, and require processors to help controllers meet them. Some states have standalone security statutes with more detail, notably Massachusetts' regulation requiring a written information security program (201 CMR 17.00) and New York's SHIELD Act. Sector rules layer on top: HIPAA for health data, GLBA's Safeguards Rule for financial institutions, and the NYDFS cybersecurity regulation for New York-licensed financial services firms.
Elsewhere. Brazil's LGPD requires security, technical and administrative measures to protect personal data (Art. 46) and requires systems to be structured to meet security requirements (Art. 49). Quebec's private-sector law requires measures to protect personal information that are reasonable given its sensitivity, purpose, quantity, distribution and medium.
Encryption
Encryption shows up in almost every regime, and in two roles: as a control, and as an escape hatch from notification. Under the GDPR, notifying individuals is not required where the data was rendered unintelligible, for example by encryption (Art. 34(3)(a)). California's breach statute applies to unencrypted data, or encrypted data where the key or security credential was also taken and could make it readable (Civ. Code 1798.82(a)); the CCPA's private right of action covers nonencrypted and nonredacted data (1798.150). The audit regulations list encryption of personal information "at rest and in transit" as a component to assess.
In practice: TLS for everything in transit, including internal service traffic; encryption at rest for databases, object storage, backups and laptops; keys held in a managed key service with access separate from the data; and field-level encryption or tokenization for the most sensitive fields (government IDs, payment data, health data) so that a database dump is not a breach of those fields. Write down where keys live, because the notification analysis after an incident turns on it.
Access control and authentication
Most breaches of personal data involve someone, or some credential, with more access than they needed. The California audit regulations are unusually concrete here: multi-factor authentication, including phishing-resistant MFA for personnel and service providers; strong, unique passwords where passwords are used; least-privilege access for employees, contractors, service providers and third parties; a limited number of privileged accounts, used only when needed, ideally through just-in-time privileged access management; controls on account creation; and revocation when someone's role changes or they leave (11 CCR 7123(c)(1)-(3)).
For privacy teams, the useful question is whether access maps to purpose. If support staff can query the full customer table when they only need order history, that is both a security gap and a data minimization problem. Your data map should record who has access to each system, and access reviews should check it.
Logging and monitoring
Logs are what let you answer the questions every breach notification asks: what was accessed, whose data, when, and by whom. Without them, the safe answer is "everything," and you notify everyone. The audit regulations list centralized storage, retention and monitoring of audit logs, plus network monitoring, intrusion detection and data-loss prevention.
Two privacy-specific points. First, log access to personal data, not just logins: queries against customer tables, bulk exports, and admin actions in SaaS tools. Second, logs are themselves personal data (IP addresses, user IDs, sometimes query contents), so set retention deliberately and keep them out of your general analytics stack.
Backups and continuity
GDPR Article 32 asks for the ability to restore availability and access in a timely manner; the California regulations ask about business continuity and disaster recovery plans, including data recovery capabilities and backups. A ransomware incident that destroys personal data without exfiltrating it is still a personal data breach under the GDPR, because it is a loss of availability.
Backups also intersect with privacy rights. Deleting a person from production does not delete them from last month's backup. California's regulations let you delay deletion in archived and backup systems until they are restored or used (11 CCR 7022(d)), but that only works if your restore procedure re-applies deletions. Build the suppression list check into the restore runbook. More on this in the data subject request automation guide.
Vulnerability management and secure development
The audit regulations name internal and external vulnerability scans, penetration testing, vulnerability disclosure programs such as bug bounties, security patch management, change management, secure configuration of on-premises and cloud environments, and secure development practices including code review and testing. They also ask about hardware and software inventories, segmentation, and limiting ports, services and protocols.
For personal data specifically, make sure scanning and testing cover the systems your data map says hold the most sensitive data, not just the internet-facing ones. Test environments seeded with production data are a recurring source of breaches; mask or synthesize the data, which the regulations also expect for certain sensitive fields displayed in applications.
Retention and disposal
Data you no longer hold cannot be breached. The California audit list includes retention schedules and proper disposal by shredding, erasing or making records unreadable. Under the GDPR, the storage limitation principle requires the same outcome for a different reason. Retention is where privacy and security programs most obviously share work; both should own the schedule.
Vendor security
Processors handle a large share of most companies' personal data. GDPR Article 28 requires you to use only processors that provide "sufficient guarantees" of appropriate measures, and the contract must oblige them to meet Article 32. California requires written contracts with service providers and contractors, and the audit regulations list oversight of service providers, contractors and third parties as a component.
A proportionate vendor process: tier vendors by the sensitivity and volume of personal data they touch; collect a current SOC 2 Type II report or ISO 27001 certificate for the top tier, and read the exceptions; put security obligations, breach-notification deadlines and audit rights in the data processing agreement; and watch their sub-processor list for changes. A processor's breach-notification clause should give you time to meet your own deadlines, which with a 72-hour regulator clock means hours, not days.
Breach notification deadlines
When the controls fail, the clock starts. These are the deadlines most often in play; many have conditions (a risk-of-harm threshold, a number of affected residents) that determine whether they apply at all.
| Regime | Regulator or authority | Individuals |
|---|---|---|
| EU GDPR (Arts. 33-34) | Within 72 hours of becoming aware, unless unlikely to result in a risk; processors notify controllers without undue delay | Without undue delay where there is a high risk |
| UK GDPR | Within 72 hours to the ICO | Without undue delay where there is a high risk |
| EU NIS2 Directive (Art. 23), for covered entities' significant incidents | Early warning within 24 hours, notification within 72 hours, final report within one month | Recipients of services informed where appropriate |
| Brazil LGPD (Art. 48; ANPD Resolution 15/2024) | 3 business days from learning that personal data was affected, where there is relevant risk or harm; doubled for small agents | 3 business days; doubled for small agents |
| Quebec private-sector act (s. 3.5) | "Promptly" to the Commission d'accès à l'information where there is a risk of serious injury | Promptly, same threshold |
| Canada PIPEDA (s. 10.1) | As soon as feasible to the Privacy Commissioner, where there is a real risk of significant harm | As soon as feasible |
| California (Civ. Code 1798.82, as amended by SB 446) | Sample notice to the Attorney General within 15 days of notifying individuals, if more than 500 residents are affected | Within 30 calendar days of discovery or notification, since January 1, 2026, subject to law-enforcement and scoping delays |
| Colorado (C.R.S. 6-1-716; Attorney General guidance) | Attorney General within 30 days if 500 or more residents are affected | No later than 30 days after determining a breach occurred |
| Florida (Fla. Stat. 501.171) | Department of Legal Affairs within 30 days if 500 or more residents are affected | No later than 30 days after determining or having reason to believe a breach occurred |
| Texas (Bus. & Com. Code 521.053) | Attorney General within 30 days if 250 or more residents are affected | Within 60 days of determining a breach occurred |
| HIPAA (45 CFR 164.404-408; HHS summary) | HHS within 60 days for breaches affecting 500 or more people; smaller breaches annually | Without unreasonable delay, no later than 60 calendar days after discovery |
| NYDFS (23 NYCRR 500.17) | Within 72 hours of determining a cybersecurity incident occurred | Governed by New York's general breach law |
| SEC (Form 8-K Item 1.05; SEC rule announcement), public companies | Within four business days of determining an incident is material | Public disclosure via the filing |
Every US state has a breach notification law, and the triggers, definitions of personal information and deadlines vary. The trend is toward fixed outer deadlines of 30 to 60 days, as California's 2026 change shows. Keep a jurisdiction table in your incident response plan, keyed by where affected people live, and review it yearly.
Incident response that works for privacy
The California regulations ask for a documented incident response plan and evidence that you test it. For personal data, the plan needs a few things a generic security plan often lacks:
- A named privacy decision-maker on the incident team who owns the notification analysis, with counsel.
- A quick path from system to data categories. When an engineer says "the support database," someone needs to know within the hour what personal data it holds and whose. This is the data map's most valuable job.
- The jurisdiction table above, plus contacts for each regulator.
- Pre-drafted notices for regulators and individuals, reviewed in advance, with placeholders for facts.
- A breach register. The GDPR requires you to document every personal data breach, including ones you decided not to notify, with your reasoning (Art. 33(5)). Quebec requires a register of confidentiality incidents as well.
- Vendor notification paths, because a large share of incidents start at a processor.
Where this connects
- Data mapping and discovery
The inventory that tells you what an incident exposed.
- Data processing agreements
Security and breach clauses for processors.
- Sub-processor lists
Tracking who your vendors share data with.
- California's CPRA and the 2026 regulations
The rest of the regulation package, including risk assessments.
- Privacy regulators directory
Who to notify, country by country.
Need this built?
If you would rather have this implemented than read about it, tell us about your project and we will reply with questions or a rough plan.