How to Identify Affected Customers for a Regulation S-P 30-Day Notice After an AI Agent Data Incident

What the amended rule requires

As of November 2026, the amended incident response and customer notification provisions appear in 17 CFR 248.30. Covered institutions must maintain written policies and procedures for a program reasonably designed to detect, respond to, and recover from unauthorized access to or use of customer information, including customer notification procedures. That program must include procedures to assess the nature and scope of an incident and to identify the customer information systems and types of customer information that may have been accessed or used without authorization.

The institution must notify each affected individual whose sensitive customer information was, or is reasonably likely to have been, accessed or used without authorization. Notice is due as soon as practicable, and no later than 30 days after the institution becomes aware that unauthorized access or use has occurred or is reasonably likely to have occurred. The duty covers incidents at a service provider that is not itself a covered institution. The institution must provide the notice or ensure that it is provided, and the notice must be clear and conspicuous.

Two provisions shape scoping work. Notice is not required if a reasonable investigation of the facts and circumstances shows the sensitive customer information has not been, and is not reasonably likely to be, used in a manner that would result in substantial harm or inconvenience. And if the institution cannot identify which individuals were affected, it must notify all individuals whose sensitive customer information resides in the system that was, or was reasonably likely to have been, accessed without authorization. The second provision makes precise identification valuable, because it is the difference between a targeted notice and a system-wide one.

Mapping agent activity to customer records

Agents complicate step four because exposure can occur at several points in a single task. A customer's data may enter a prompt, appear in a retrieval result, be passed as input to a tool, return in a tool output, be echoed in a model response, or be written to a downstream system. Each is a distinct place where access or use may have occurred, and each needs a record that ties the event to a customer identifier.

Before an incident, settle two definitions with counsel and write them into the response program. First, how the institution applies the rule's defined term for sensitive customer information to the data types agents handle. Second, how it treats unauthorized access or use in agent terms. Cases that need a stated position include data retrieved but redacted before reaching the model, a tool call that was blocked, data sent to a third-party model, and data held by a service provider. Deciding these positions during an incident wastes days of a 30-day window.

Then build the mapping from the evidence you have. Start from the affected system and list the customer records the agent could reach. Narrow that list using interaction and tool-call records that show which identifiers actually appeared. Where a third-party model or service provider received data, you need a record of what was sent, because the notification duty extends to incidents at service providers. If the records show a group of customers' data was reachable but cannot show which were touched, the fallback applies and the notice population is the whole system.

Applying and documenting the harm determination

The exception for substantial harm or inconvenience requires a reasonable investigation, so the investigation file matters as much as the conclusion. Record what was examined, which facts were relied on, who reviewed them, and when the decision was made. A conclusion without a described investigation is difficult to defend.

Agent incidents raise specific questions the file should answer. Was the sensitive information actually exposed to a model or tool, or was it redacted or blocked first? Where did it go, and who can use it there? If it reached a third-party model or service provider, what can that party do with it, and what evidence can it supply? Interaction-level records showing that data was blocked or redacted can support a finding that sensitive customer information was not accessed or used. They only do so if the records are specific to the interaction and can be tied to the customers in question.

Assign ownership in advance for three decisions: the awareness determination, the harm determination and the notice decision. Record approvals for each. Keep the Regulation S-P analysis separate from other regimes. The FTC Safeguards Rule and the bank Interagency Guidelines are different frameworks with their own thresholds and timelines, and their language should not be imported into a Regulation S-P file.

Where runtime enforcement fits

Trussed enforces policy in the execution path of models, agents, tools and MCP servers, at the level of individual interactions and tool calls. Policy decides whether each interaction is allowed, redacted or blocked, and that enforcement produces audit-ready evidence at the time it happens, not after the fact. For scoping, this gives the institution a durable record of what was permitted to pass and what was stopped for a given interaction, which can narrow the affected population and substantiate the reasoning behind it.

The boundaries are specific. Trussed does not provide end-to-end tracing of agentic workflows or transaction-level governance, and it does not make the notice determination. The institution still defines sensitive customer information, decides what counts as unauthorized access or use, runs the harm investigation and issues notice. Retention is configurable and deployment can be self-managed in the customer cloud, which lets compliance teams set evidence retention against the notice window. Evidence of this kind supports a documented determination. It does not guarantee a regulatory outcome.