The State Breach Notification Law Patchwork: Why 'We'll Notify Affected Users' Isn't a Single Answer

Every US state has a breach notification law. None of them are the same law. An MSP that treats 'we'll notify affected individuals' as a single, portable incident response step is planning for a regulatory environment that doesn't exist — the actual obligation depends on which states the affected individuals live in, not where the breached company is headquartered.

The variables that differ state to state

The definition of 'personal information' triggering notification varies — some states count a name plus a driver's license number, others extend to biometric data, health information, or even usernames paired with security questions. The notification deadline varies from 'without unreasonable delay' language with no fixed number to a hard statutory count of days. Whether the state attorney general or a consumer reporting agency must also be notified — and at what breach size threshold — varies. Whether there's a private right of action allowing affected individuals to sue directly, versus enforcement resting solely with the state AG, changes the incident's actual legal exposure.

What this means operationally for an MSP running incident response

• The affected-individual list has to be sorted by state of residence before notification content or timing decisions can even be made, which means the underlying data inventory needs to track where data subjects live, not just how many there are
• A breach affecting residents of a dozen states can require a dozen different notification letters, timelines, and possibly AG filings running in parallel, not one incident response playbook executed once
• 'Encrypted data is exempt' is true in some states and conditionally true in others depending on whether the encryption key was also exposed — worth verifying per state, not assuming globally

Why this is worse for MSPs specifically

An MSP handling data for clients across multiple states, or a client whose customers span multiple states, inherits this complexity by proxy. A single ransomware incident at one MSP-managed client can trigger notification obligations in a dozen different legal regimes simultaneously, each with its own clock already running from the moment of discovery — which means the incident response plan has to include 'determine which states are implicated' as an early, fast step, not something worked out during the notification drafting itself.

'We'll notify affected users' describes an action. It doesn't describe a compliance obligation, because the obligation is actually forty-some different obligations that happen to share a name.

This is exactly the kind of fragmented, evidence-dependent tracking problem the compliance module's three-state, evidence-attached structure is well suited to — the same model used for the frameworks it already tracks extends naturally to treating each applicable state's notification obligation as its own item with its own evidence and status, rather than one undifferentiated 'breach response plan exists' checkbox. Whether state-by-state notification tracking specifically is configured today is worth checking against the current framework list directly rather than assumed; either way, the underlying determination of which states are implicated and what each one requires still belongs to counsel, not the tooling that helps organize the evidence.