AI-Specific Procedures in a Regulation S-P Incident Response Program

What the rule requires and what AI changes

As of November 2026, the amended Regulation S-P requires covered institutions (brokers or dealers, investment companies, registered investment advisers and transfer agents) to develop, implement and maintain written policies and procedures for an incident response program. The program must be reasonably designed to detect, respond to and recover from unauthorized access to or use of customer information. It sits within the institution's broader safeguards policies.

The 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. It must include procedures to contain and control the incident to prevent further unauthorized access or use. It must also include procedures to notify each affected individual whose sensitive customer information was, or is reasonably likely to have been, accessed or used without authorization. Notification is not required if, after a reasonable investigation, the institution determines the information has not been, and is not reasonably likely to be, used in a manner that would result in substantial harm or inconvenience.

The rule is technology-neutral, so the AI adaptations are program design decisions rather than rule text. Four exposure paths deserve explicit treatment: prompts that carry customer information to third-party models, agents and tools that access or move customer records, model outputs that disclose sensitive data, and coding assistants that touch systems holding customer data. Whether a given event is unauthorized access or use depends on what the institution authorized, so each path needs a defined authorization baseline. Because the trigger covers both access and use, an event can qualify even when no external attacker is involved.

Procedure 1: AI system inventory and data-flow scoping

The assessment step asks which customer information systems and which types of customer information were involved. A response team can only answer that quickly if the mapping exists before the incident. The AI inventory should therefore be built as a scoping tool, not as a list of approved products.

For each model, agent, tool, MCP server, AI site and coding assistant in use, record what it is authorized to reach and what it can technically reach. The gap between those two is where unauthorized access or use is most likely to occur.

• Systems and tools: List each AI system, agent and tool, with a named business and technical owner.
• Reachable data: Record the customer information systems and data types each one can reach through connectors, credentials and tool permissions.
• Outbound paths: Identify where prompts, retrieved records and tool-call payloads are sent, including third-party models.
• Authorized versus actual: Document the permitted scope for each path and compare it with actual access.
• Coding assistants: Note which assistants can read repositories, environments or systems that hold customer data.

Procedures 2 and 3: detection, triage and containment

Detection and triage criteria need to name AI paths explicitly. Add scenarios such as customer information appearing in prompts sent to a model that is not approved for it, an agent calling a tool against records outside its task, a model output that discloses sensitive data to a person or system not entitled to it, and a coding assistant reading a system that holds customer data. Each scenario should have an intake route, a severity rule and a clear point at which it becomes an incident under the program. Triage should also record whether the event involved access, use or both, since either triggers the program.

Containment must prevent further unauthorized access or use. For AI paths, the program should define which actions are available and at what level. Taking an entire AI system offline is sometimes necessary, but it is a blunt instrument. Narrower actions include blocking a specific tool call, suspending one agent's credentials, disabling a connector, restricting a data type from leaving in prompts, or routing a class of requests to human approval. Define these actions in advance, name who may invoke them, and record when each was taken. Containment decisions made at the interaction or tool-call level are only possible if the program can see and act at that level.

NIST's generative AI profile recommends incident response plans for third-party generative AI technologies, with defined ownership of response functions and regular rehearsal. That is voluntary guidance, but it is a practical template for assigning containment authority.

Procedure 4: scoping affected customer information

Scoping turns an AI event into an answer the institution can act on: which systems, which types of customer information, which individuals. The AI-specific difficulty is that exposure is spread across interactions and tool calls rather than sitting in one database. Scoping therefore needs records at that granularity: which interactions carried customer information, which tool calls retrieved or moved records, what the output contained, and what was redacted or blocked before leaving the institution.

Build the scoping procedure so it can separate three populations: information that was exposed, information that was present but redacted or blocked, and information that was never in the interaction. The third group matters because it narrows the notification population. The second matters because a documented redaction or block is evidence that the information was not accessed or used without authorization.

NIST recommends testing AI evidence sources, such as prompt and completion records and agent traces, before an incident occurs. A scoping exercise run against a simulated event will show quickly whether the records can actually answer the questions above.

Procedure 5: notification and third-party provider inputs

Notification turns on two determinations: whether sensitive customer information was, or is reasonably likely to have been, accessed or used without authorization, and whether, after a reasonable investigation, the institution concludes it is not reasonably likely to be used in a way that results in substantial harm or inconvenience. For AI incidents, the program should specify what the reasonable investigation consists of and keep a written record for every notification and every decision not to notify. That record should show the scoping evidence, the reasoning and the approver.

AI incidents often involve a third-party model or tool provider, so the program should define what the institution needs from that provider during an incident. Useful inputs include whether customer information was received, how it was handled, whether it was retained or used beyond the request, and what the provider can supply to confirm scope. Agree on contacts, response expectations and escalation paths with each provider before an incident, and rehearse a third-party AI scenario on a regular schedule. Run after-action reviews and feed the findings back into the procedures.

Keep this program separate from other regimes. The FTC Safeguards Rule has its own incident response plan and notice requirements for the entities it covers, and those should not be read into Regulation S-P.

Where runtime policy enforcement supports each procedure

Several of these procedures depend on acting at the level of a single interaction or tool call, and on having records created at that moment. Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. For each interaction or tool call, policy can allow, redact, block, rate limit or escalate for human approval. This is enforced at runtime, not reviewed after the fact.

For containment, this gives the response team actions narrower than shutting down a system: block a tool call, redact a data type from a prompt, or require human approval for a class of requests. For scoping, enforcement produces audit-ready evidence as a by-product: which policy applied, what was redacted or blocked, and what was approved and by whom. That evidence helps a team reconstruct what individual interactions and tool calls involved and show what the AI was permitted to do and what it did. Deployment is self-managed in the customer's cloud, with configurable retention and data residency, so retention can be set to the institution's own requirements.

This does not replace the program. Inventory, triage criteria, notification judgment and provider coordination remain the institution's responsibility, and enforcement evidence supports those decisions without guaranteeing compliance.