Published

A financial firm's provider reports unauthorised access to account-opening files. Your team needs to answer three questions: Who may be affected? Is notice required? What happened to each notice? One connected incident file should show the answers and the evidence behind them.
Keep the evidence and the affected-person list.
Keep the reasons and any approved notice.
Keep delivery outcomes and unresolved actions.
Record both awareness times and the facts that establish them. Provider alerts and customer notices have different triggers:
72 hours
As soon as possible, no later than this limit.
Starts when the provider becomes aware of a security breach resulting in unauthorised access to a customer information system it maintains.
The institution's oversight procedures must be reasonably designed to ensure this provider notification. SEC guidance
30 days
As soon as practicable, no later than this limit.
Starts when the institution becomes aware that unauthorised access to or use of customer information occurred or is reasonably likely to have occurred.
The notice obligation concerns affected individuals' sensitive customer information, subject to the rule's exceptions. SEC overview
These limits do not add up to “72 hours plus 30 days”. The institution's clock may already be running. Waiting for a final report or an approval meeting does not reset it.
The SEC compliance guide covers broker-dealers, including funding portals, investment companies, SEC-registered investment advisers, and transfer agents registered with the SEC or another appropriate regulatory agency. Compliance dates were December 3, 2025 for larger entities and June 3, 2026 for smaller entities. Both have passed. Confirm your firm's coverage and any additional state or sector obligations.
Connect the affected files and versions to people. Check shared accounts, provider copies, and information held for other financial institutions. Separate confirmed facts from unresolved scope.
Original evidence, collection details, customer mappings, the matching method, and reasons for including or excluding each person.
Missing logs do not establish that someone was unaffected. If specific affected individuals cannot be identified, the rule generally requires notice to everyone whose sensitive information resides in the affected system, with exclusions where the institution reasonably determines their information was not accessed or used without authorisation.
Compliance records the decision. Where notice is required, reviewers approve the incident-specific wording and recipient list. Use a prepared template checked against the notice requirements.
The decision and its basis, deadline, approver, exact notice version, and recipient list used for each batch.
The decision concerns sensitive customer information: information whose compromise could reasonably risk substantial harm or inconvenience. Record the reasoning behind any exception or authorised delay.
Match delivery results to the approved recipient list. Assign failed messages, returned mail, and missing results for follow-up or an approved alternative channel.
Each notice, sending reference, channel, time, provider result, retry, and unresolved action.
“Accepted by the email provider” does not mean “received or read”. Keep those outcomes separate. The institution remains responsible for required notices even when a provider sends them on its behalf.
Under the final rule, an institution may decide against notice after a reasonable investigation if it determines that sensitive information has not been, and is not reasonably likely to be, used in a way that would cause substantial harm or inconvenience. National-security or public-safety delays require the rule's Attorney General process.
Notice requirements include clear written notice through a means reasonably expected to reach the individual. Cover the incident, information involved, dates where reasonably determinable, contact channels, and required account-monitoring, fraud-alert, credit-report, and identity-theft guidance. Retain a written agreement if a provider notifies on the institution's behalf.
Verify logging across application, storage, export, and provider routes before an incident. For S3, CloudTrail object data events need configuration; they are not logged by default or included in ordinary Event history. A generated download link alone does not prove retrieval. Restrict raw customer data and privileged advice to the appropriate reviewers.
Keep policy versions, provider oversight records, findings, decisions, notices, and delivery evidence. Retention requirements vary by institution and record type. Define the schedule, starting event, access needs, and holds. Coordinate disposal of working copies and unnecessary customer data, and test that a reviewer can retrieve the response file.
Use the provider incident in a tabletop exercise. Ask the team to show:
Connect the awareness timeline, affected-person analysis, notification decision, and exact approved notices in one incident record. Reconcile required notices with delivery results and unresolved actions, then retain the evidence needed to explain the response.
The open-source foundation — API-first, deployable into your own AWS account, and free to use. Right for architecture validation and early implementation.
Production-ready editions for departments and complex workflows. Start with a Proof-of-Value deployment or go straight to production.
For governance-heavy environments with residency, sovereignty, assurance, and multi-jurisdiction requirements. Talk to us about the right deployment model.