The Reg S-P Amendments: Building a 30-Day Customer Breach-Notification Pipeline

The clock in the amended Regulation S-P does not start when you decide to notify. It starts the moment you become aware of an incident — and if you cannot say within days which customers it touched, thirty days is not enough time.

The SEC adopted its amendments to Regulation S-P on 16 May 2024. Most of the coverage read them as a privacy-notice refresh — update the policy, retrain the staff, move on. That reading misses the substantive change. The amendments require covered institutions to run a written incident response programme and to notify affected individuals “as soon as practicable, but not later than 30 days” after becoming aware that sensitive customer information has been, or is reasonably likely to have been, accessed or used without authorisation. That is not a document you draft once. It is a pipeline that has to fire on demand, under time pressure, on the worst day your firm has had all year. It is a data-mapping and orchestration problem wearing a compliance badge.

What actually changed

Three operational duties sit underneath the amendments, and they apply to a broad set of registrants: broker-dealers, registered investment advisers, investment companies, funding portals and transfer agents.

Free · 4 minutes

When two of your systems disagree, do you know which one to believe?

Fourteen questions on ownership, lineage, and quality — the difference between a number on a dashboard and a number you could defend. Banded finding on screen, full sheet by email.

  1. An incident response programme: written policies and procedures to detect, respond to and recover from unauthorised access to or use of customer information, including assessing the nature and scope of an incident and containing it.
  2. A customer notification duty: written notice to affected individuals no later than 30 days after becoming aware of a qualifying incident, describing what happened, what data was involved and what the individual can do about it.
  3. A service-provider requirement: policies designed to ensure your providers protect customer information and notify you — the standard the SEC set is within 72 hours — when they detect a breach affecting the systems that hold it.

The compliance dates have already passed. Larger entities have been subject to the amended rule since 3 December 2025; smaller entities since 3 June 2026. The distinction is not FINRA’s notion of firm size: broadly, an investment adviser with $1.5 billion or more under management, an investment company with $1 billion or more in net assets, and any broker-dealer that is not a small entity fell into the earlier tranche. If you are reading this having assumed you are still in a grace period, check Table 3 of the final release against your own numbers before you do anything else.

Why 30 days is a data problem, not a legal one

The legal wording is short. The engineering it implies is not. “Becoming aware” is the trigger, and from that point the deadline is fixed regardless of how long it takes you to work out who was affected. You cannot notify individuals you cannot identify. So the real question the rule poses is: when a system is compromised, how quickly can you say which customers had sensitive information in that system?

For most firms, honestly answered, the current time-to-answer is weeks, not days — because the knowledge lives in people’s heads and in undocumented data flows rather than in a queryable inventory. That gap is the whole problem. A firm that has to convene a working group to reconstruct where personal data sits has already lost most of its thirty days to discovery, leaving almost none for drafting, review and delivery. This is the same discipline I have argued for in the context of building the incident-disclosure muscle before the regulation demands it: the notification obligation is downstream of an instrumentation obligation nobody wrote down.

Map where customer information lives before the clock can start

The prerequisite is a data inventory that records, for every system in scope, which sensitive elements it holds and which customers it serves. “Sensitive customer information” here is anything that, if compromised, could create a reasonably likely risk of substantial harm or inconvenience — a Social Security number on its own, or a username paired with the data needed to get into an account. If you can join an incident’s affected systems against that inventory, the population owed a notice falls out as a query rather than an investigation.

The workflow is deliberately mechanical. Take the systems in the breach scope, look each one up in the inventory, keep the ones that hold sensitive elements, and collect the customers those systems serve. The one rule that matters: a system you cannot find in the inventory cannot be cleared, so it stays in scope. Unmapped estate is the enemy of a defensible notification decision.

# Map a breach scope to the individuals owed a 30-day notice under Reg S-P.
# Inputs: the affected systems from the incident, and a data inventory recording
# which sensitive elements each system holds and which customers it serves.

from datetime import date, timedelta

SENSITIVE_ELEMENTS = {"ssn", "account_number", "gov_id", "credential_pair"}

def affected_individuals(breach_systems, data_inventory):
    """Return customers whose sensitive information sits in the breach scope."""
    notify = {}
    for system in breach_systems:
        record = data_inventory.get(system)
        if record is None:
            # Unmapped system cannot be cleared, so it stays in scope.
            raise ValueError(f"System {system} is missing from the data inventory")
        exposed = SENSITIVE_ELEMENTS & set(record["elements"])
        if exposed:
            for customer_id in record["customers"]:
                notify.setdefault(customer_id, set()).update(exposed)
    return notify

def notification_deadline(aware_on):
    """No later than 30 days after becoming aware of the incident."""
    return aware_on + timedelta(days=30)

inventory = {
    "crm-prod": {"elements": ["ssn", "email"], "customers": ["C-1001", "C-1002"]},
    "billing":  {"elements": ["account_number"], "customers": ["C-1002"]},
}
owed = affected_individuals(["crm-prod", "billing"], inventory)
deadline = notification_deadline(date(2026, 8, 27))  # organise delivery well inside this

The snippet is trivial. The hard part is the inventory it reads from — keeping it current as systems, vendors and data flows change. That is the work the rule quietly mandates and that most firms have not done.

The exception you have to be able to evidence

Notice is not required where the institution determines that the sensitive information has not been, and is not reasonably likely to be, used in a way that would cause substantial harm or inconvenience. That exception is a trap if you treat it as a get-out. It is a determination you have to make deliberately, document contemporaneously and be able to defend later. A firm that skips notification without a recorded, reasoned basis has not used the exception — it has simply failed to notify. Build the no-harm determination into the pipeline as a logged decision, with the facts that supported it, not as an unrecorded judgement call made under pressure.

What an examiner will ask to see

When the SEC or FINRA tests this, they will not accept a written policy as proof of a working programme. Expect requests for the incident log showing when awareness was established, the data inventory the affected population was derived from, the notification decisions and their timing, and — where you relied on the exception — the contemporaneous no-harm analysis. Firms already carrying overlapping US cyber obligations, such as the Class A duties under the NYDFS cybersecurity rule, have a head start on the plumbing but still need to prove this specific clock can be met. The same evidential logic applies as in any tight reporting window; I have set out the mechanics for a shorter one in engineering for the AI Act’s 15-day incident clock, and the shape of the build is the same: detect, scope, decide, deliver, all with a timestamp on each step.

Thirty days sounds generous until you realise the rule spends the first three weeks of it on a question you should already be able to answer in an afternoon. Instrument the pipeline now, while nothing is on fire, because you do not get to start building it on the day the clock starts.

Free interactive tool

Website compliance checklist

What your site has to do, based on what it actually does

Answer as much or as little as you like — the list builds as you go. Nothing is stored against your name and no email is required.

Free interactive tool

Interactive deadline calculator

Check which regulations apply to you and when

Regulation across the EU, UK, US and Asia-Pacific has moved considerably in the past eighteen months, and several headline dates have shifted more than once. Twelve questions, about three minutes.

Results are shown on screen — no email required. A dated summary is available to download, and can be sent on if that's more useful. What we do with your answers.

Most technology problems are not technology problems. They are control problems.

The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.

Full Governance by Sixteen Pillars

Govern your business. Prove your compliance.

A board assurance cockpit for EU-regulated financial firms — tamper-evident, hash-chained proof of governance across DORA, GDPR, NIS2, ISO 27001, the EU AI Act and MiCA. In development.

See what's coming