This issue starts where the blog starts: Europe gave every breach one clock, and a US company runs a dozen that disagree. Around that I kept three items that change a decision this quarter, from New York's financial regulator, from California, and from NIST. The extra analysis is a worked example of the one document that matters on a bad day.
Europe Has One Breach Clock. The US Has Dozens.#
Under the European Union's General Data Protection Regulation (GDPR), a breach involving personal data goes to one regulator within 72 hours of you becoming aware of it. That has been true since 2018, and nobody is lobbying to simplify it. A US company with the same breach starts a stack of clocks instead.
If you are public, the Securities and Exchange Commission (SEC) gives you four business days to disclose a material incident, counted from when you decide it is material, not from when it happened. In April, five financial-industry trade groups asked the SEC to scrap or narrow that rule, and as of the blog's writing the agency had not ruled. Underneath sit state consumer-notice laws, some with a set number of days (30, 45, or 60) and many with only "without unreasonable delay." New York's financial regulator wants 72 hours. The federal health-privacy law, HIPAA, allows up to 60 days to notify patients.
Winning the SEC fight removes one clock from a long list. The federal incident-reporting rule from issue #14 is still in White House review, and when it lands it stacks on top of everything above rather than replacing any of it.
What it changes for you: pick the fastest clock you are actually exposed to, build one response timeline to it, and let slower filings ride on the same confirmed facts. Name one person, not a committee, who decides that a clock has started. The blog has the full Monday-morning list.
New York's Regulator Says a New AI Model Can Force a Redo of Your Risk Assessment#
On September 10, the New York Department of Financial Services (NYDFS) published an industry letter on the annual risk assessment its cybersecurity rule, Part 500, already requires. It creates no new obligation, but lawyers expect examiners to lean on it. Beyond the annual update, you must redo the assessment after any material change in cyber risk. The letter's examples include major system migrations, mergers, significant outsourcing, significant developments in cybersecurity technology such as frontier AI models, and the adoption of emerging technologies.
NYDFS also expects a risk register that links each risk to a specific control, with written reasons for every risk you decide to accept. A PDF produced once a year does not show that.
What it changes for you: if you are a covered bank, insurer, or other licensed financial business, find the date of your last assessment and ask whether an AI rollout, migration, or outsourcing deal since then should have triggered a new one. If you are not covered, the letter is a free template for what a regulator will accept as a defensible assessment.
California Ended One Kind of Website-Tracking Lawsuit. Keep Your Tag Audit.#
On September 30, Governor Newsom signed SB 690. From January 1, 2027, private parties can no longer sue under one section of the California Invasion of Privacy Act (CIPA), section 638.51, over cookies, pixels, and similar tools on websites and apps. Plaintiffs had used that section heavily, because it treated tracking code like a phone-tracing device. The change reaches suits filed on or after January 1, 2025, so pending cases can be challenged.
The catch is what stays. The separate wiretapping section, 631, is untouched, the Attorney General can still bring these cases, and the Governor's signing statement asked lawmakers to revisit other CIPA provisions in 2027.
What it changes for you: tell counsel to review any pending demand letter or suit that rests on section 638.51, since it may now be dismissible. Do not relax your cookie, pixel, and consent-banner audit. Expect claims to move to section 631.
The Federal Playbook for Stolen Login Tokens Is Final#
On September 15, NIST (the National Institute of Standards and Technology) and CISA released the final version of NIST IR 8587, "Protecting Tokens and Assertions from Forgery, Theft, and Misuse." Think of a token as a signed visitor badge your identity system hands out after you log in. If someone steals the machine that prints badges, or its signing key, they can forge any badge they like. The report covers protecting that key, verifying tokens, setting lifetimes, revoking them, logging their use, and responding when a key may be compromised. It also says the same protections apply to tokens that AI agents carry.
In a separate post on NIST's blog, two of its identity specialists make the agent point sharper: many early AI agent setups repeat old login mistakes, such as an agent using a person's own password, keys that never expire, and far more access than the job needs. Their advice is to give each agent its own login, use keys that expire quickly, and grant access only when it is needed.
It is written for federal agencies and cloud providers, but CISA encourages all organizations to review it. Read the report itself for the specific lifetime and rotation numbers rather than trusting a summary, including mine.
What it changes for you: you rarely hold the signing key; your identity and cloud vendors do. Add three questions to your next vendor review: how do you protect signing keys, how long do tokens live, and how fast would you tell us if a key leaked? In issue #13 I asked what your agents can touch. This is the layer underneath that question.
One Level Deeper: Write Down the Moment You Knew#
Most breach programs track deadlines. The thing that hurts you is the unwritten decision that starts each one. Each clock above starts at a different moment: awareness, a determination that an event qualifies, a judgment of materiality. If those moments exist only in people's memories, two filings will describe the same incident differently, and the gap becomes the story.
Here is an illustrative case, not a real company. A public financial firm with California customers sees suspicious access Monday at 9:00. At 17:00 it confirms that personal data was accessed. Wednesday at 10:00 the executives decide it is material.
- Monday 17:00: the "qualifying event" decision. The 72-hour regulator clock now runs to Thursday 17:00.
- Wednesday 10:00: the materiality decision. Four business days later is Tuesday, so the SEC filing is due then.
- State consumer clocks: most start at discovery or determination, and states differ, so the log should hold both Monday 9:00 and Monday 17:00.
Three clocks, three start times, one incident. The fix is a decision log with one line per determination: the question, the time, who decided, and the facts they had. Fill it in as you go, and have every filing quote from it. If a regulator asks when you knew, you answer from a record instead of a recollection.
How This Impacts Your Organization#
The principle doesn't change with company size: one incident will meet several rulebooks, and your job is to run it from one set of facts. What changes is which clocks apply to you and where your leverage sits.
Large Enterprises (1,000+ employees)
Your risk is fragmentation: securities counsel, privacy counsel, and the sector-regulator team each hold a clock, and nobody holds the log. Your leverage is that you can staff one owner for the "clock started" call. This quarter, have that person run a tabletop using the decision-log format above, and have security confirm whether any AI rollout since your last risk assessment should have triggered a new one.
Mid-Size Organizations (100–999 employees)
You feel this fastest, with the clocks of a large company and no legal bench. The overcorrection to avoid is five separate playbooks, one per rule. Build one timeline to your fastest clock. Ask outside counsel once for a one-page list of the deadlines that apply to where your customers live. Add the three token questions to your next identity-vendor renewal. If you run a website in California, keep your tag audit going.
Small & Growing Organizations (under 100 employees)
Honest counsel: you probably aren't subject to the SEC rule or the federal reporting rule, so don't build an enterprise program. Find out which states your customers live in and write down the shortest deadline. Keep a one-page decision log template ready. If you have EU customers, treat 72 hours as your floor. Encrypt sensitive data, since properly encrypted data can take a breach out of notification in many states.
Curated Links#
- Europe Has One Breach Clock. The US Has Dozens. (companion blog post) — DLegendDigital.com/blog
- Cybersecurity-Focused Regulation S-K reconsideration summary — jdsupra.com (Mayer Brown)
- ICBA groups urge SEC to rescind cyber incident rule — independentbanker.org
- NYDFS issues extensive guidance on cybersecurity risk assessments — mayerbrown.com
- NYDFS industry letter on cybersecurity risk assessments — alstonprivacy.com
- Governor Newsom signs SB 690 — beneschlaw.com
- SB 690 signed into law: what it means for CIPA — bakerdonelson.com
- NIST and CISA finalize token protection report (NIST IR 8587) — content.govdelivery.com (CISA bulletin)
- NIST and CISA finalize playbook to stop token theft and forgery — helpnetsecurity.com
- Why agentic AI needs a strong identity foundation — nist.gov (NIST blog)
One thing to take from all of it: the deadline is rarely the hard part. The hard part is agreeing, in writing, on when the clock started.
On the blog this cycle: Europe Has One Breach Clock. The US Has Dozens — and the SEC May Make It Worse. — the full state, sector, and federal map, and what to do on Monday morning.
Hit reply and tell me what you're wrestling with — I read every one.
— Charles Redding, Founder, DLegendDigital