US Bank Computer-Security Incident Notification Rule Guide: 36-Hour Notice and Provider Duties

US banking organisations must tell their primary federal regulator about a serious computer-security incident as soon as possible and no later than 36 hours after determining it has occurred, and their technology providers must warn them as soon as possible when an incident disrupts covered services for four or more hours. The Computer-Security Incident Notification Rule was issued jointly by the OCC, the Federal Reserve Board and the FDIC on 23 November 2021 and has applied since 1 May 2022. It is short, but the judgements it requires (what counts as a notification incident, when a determination has been made, which provider contact to call) have to be made under pressure at 2am. This guide covers scope, the two duties, the clock, enforcement, the identity and AI agent angle, and how to build the process. Status line: text checked on eCFR (current to 20 October 2026) on 27 October 2026, with no amendment found. It is for bank CISOs, incident response and compliance leads, and fintech, core processor and cloud providers that serve banks.

Key takeaways

• Two duties, two parties. Banking organisations notify their regulator within 36 hours of determining that a notification incident has occurred; bank service providers notify their bank customers as soon as possible when covered services are, or are likely to be, materially disrupted for four or more hours.
• The clock starts at determination, not discovery. The agencies allow a reasonable time to decide whether an incident qualifies, but once the bank has decided, 36 hours is the outer limit and "as soon as possible" is the standard.
• The notice is simple. No form or specific content is required beyond the fact that a notification incident has occurred; email or telephone to the supervisory contact is enough.
• Materiality is about operations, not data. The trigger is material disruption or degradation of the ability to serve a material portion of customers, of material business lines, or of operations that matter for US financial stability. Customer data breach notice is a separate regime.
• Providers do not judge for the bank. A service provider need not decide whether an incident is a notification incident for its customer; it must simply tell the bank-designated contact, which means banks must give providers that contact in advance.

Scope: who and what is covered

Designated financial market utilities are excluded from the definitions of both banking organisation and bank service provider, because they have their own regime.

Definitions that decide the outcome

• Computer-security incident: an occurrence that results in actual harm to the confidentiality, integrity or availability of an information system or the information it processes, stores or transmits. Attempts that cause no harm are not incidents under the rule.
• Notification incident: a computer-security incident that has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, the banking organisation's (1) ability to carry out operations or deliver products and services to a material portion of its customer base, (2) business lines whose failure would cause a material loss of revenue, profit or franchise value, or (3) operations whose failure or discontinuance would threaten the financial stability of the United States.
• Bank service provider: a bank service company or other person that performs covered services, meaning services subject to the Bank Service Company Act. This catches core processors, payment processors and many cloud, SaaS and managed service providers.

Examples the agencies gave

The final rule's preamble lists incidents that would generally be notification incidents, while stressing that each bank must decide case by case:

• A large-scale distributed denial of service attack that disrupts customer account access for an extended period, for example more than four hours.
• A failed system upgrade or change that causes widespread user outages for customers and employees.
• An unrecoverable system failure that results in activation of the business continuity or disaster recovery plan.
• A computer hacking incident that disables banking operations for an extended period.
• A ransomware attack that encrypts a core banking system or backup data.

Note that a failed upgrade with no malicious cause can still be a computer-security incident, because the definition turns on actual harm to availability, not on an attacker.

Key obligations

How the 36-hour clock works

• Determination, not belief: the final rule replaced the proposed "good faith belief" standard with the bank's determination that a notification incident has occurred. Only then does the 36-hour period begin.
• Reasonable time to determine: banks are not expected to decide immediately on learning of an incident, but the agencies expect a reasonable period, including outside business hours. Weekends do not stop the clock.
• "Reasonably likely" counts: a bank does not have to wait for the disruption to happen; an incident that is reasonably likely to cause material disruption is notifiable.
• Content: no specific information is required beyond the fact that a notification incident has occurred. In practice, expect the supervisor to ask follow-up questions on scope, cause, customer impact and recovery, so have a holding statement ready.
• Four hours is a duration, not a deadline: for providers, "four or more hours" describes how long covered services are disrupted. The deadline itself is "as soon as possible".

How it fits with other US notification duties

The 36-hour notice is to the prudential regulator and is about operational disruption. It does not replace customer notice of unauthorised access to sensitive customer information, state breach notification laws, SEC Form 8-K disclosure for public companies (within four business days of a materiality determination), NYDFS Part 500 notice for New York licensed entities (72 hours), or CIRCIA once its final rule applies. Map them together in one decision tree. See the Cyber Incident Reporting Requirements Map, the NYDFS Part 500 Guide and the SEC Cybersecurity Disclosure Rules Guide.

Timeline and current status

Enforcement and penalties

• No rule-specific penalty: the rule does not set its own fines. A failure to notify is a regulatory violation that the agencies address through supervision: examination findings, matters requiring attention, and where warranted the general enforcement tools available to the federal banking agencies, such as cease and desist orders and civil money penalties.
• Service providers are examinable: the Bank Service Company Act allows the agencies to examine and regulate covered services performed for banks, which is the hook for the provider duty. Banks should also make the duty contractual.
• Supervisory relationship: late or missing notice damages trust with the examination team and typically leads to closer scrutiny of incident management, third-party risk and business continuity. See the FFIEC Cybersecurity Guidance Guide.
• Public enforcement record: we found no published enforcement action that cites the rule alone as of 27 October 2026. Treat this as a reason to document decisions, not as a sign of low risk.

What it means for AI agents and non-human identities

Many incidents that cross the materiality line now start with a machine identity: a stolen API key at a provider, a compromised service account in a core banking integration, or an automation that runs out of control. The rule is technology-neutral, so these are judged by their effect on operations.

• Provider credential compromise: if a core processor or fintech partner revokes all API credentials to contain a breach, the resulting outage of covered services can trigger the provider's notice and the bank's own determination. Plan for mass credential rotation as a disruption scenario. See the Third-Party Risk Management Guide.
• Identity provider failure: loss or compromise of the workforce or customer identity platform can stop online banking and branch operations at once, and is a strong candidate for a notification incident.
• Service account abuse: integrity harm, such as an attacker using a payments service account to alter transactions, is a computer-security incident even without an outage. Whether it is notifiable depends on material effect on operations or business lines. See the Service Account Security Guide.
• AI agents in operations: an agent with write access to customer records or payment queues that misbehaves, or is manipulated through prompt injection, can cause the same harm as a human attacker. Include agent kill switches and agent activity logs in incident playbooks. See the AI Agents in Financial Services Security Guide.
• Evidence: machine identity logs (token issuance, key use, agent tool calls) are often what lets a bank decide quickly whether harm actually occurred, which is the first test.

Compliance steps

1. Confirm your agency and channel. Record the designated regulator contact (OCC supervisory office, Board-designated contact, or FDIC case manager), with backup contacts and out-of-hours numbers, in the incident response plan.
2. Write materiality criteria. Define "material portion of customers" and "material business lines" for your bank in advance, with thresholds (customers affected, duration, channels down, revenue at risk) that the incident team can apply.
3. Name the decision owner. Assign who makes and records the determination (for example the CISO with the chief risk officer), and who sends the notice. Record the time of determination, because that starts the clock.
4. Prepare templates. A two-line regulator notice and a holding statement covering what is known, impact, and next update time.
5. Inventory bank service providers. Identify which providers perform covered services and confirm each has your bank-designated point of contact, ideally a monitored shared mailbox and a phone line, not an individual.
6. Update contracts. Add the notification duty, the four-hour disruption trigger, contact details, and expectations for follow-up information and credential revocation support.
7. Exercise it. Run tabletop exercises covering ransomware on core systems, a provider outage, an identity provider compromise and a failed change, timing the path from detection to determination to notice. See the Incident Response Plan Template.
8. If you are a provider: build a customer contact register keyed by bank, an internal four-hour disruption monitor, and a notification workflow that does not depend on the systems that may be down.

Framework mapping

Detection and measurement

• Median time from incident declaration to recorded determination decision, measured in exercises and real events.
• Percentage of notification incidents notified within 36 hours of determination (target: 100%, and well inside).
• Percentage of covered-service providers holding a current bank-designated contact.
• Number of provider disruptions of four or more hours learned of from the provider first, against those detected internally first.
• Exercises per year covering provider and identity platform scenarios.

Common failure patterns

• Waiting for certainty: treating "determination" as needing a complete forensic picture, when the rule asks for a reasonable time and covers incidents reasonably likely to cause material disruption.
• Confusing the regimes: assuming that customer breach notice or an SEC filing satisfies the 36-hour regulator notice, or the reverse.
• Stale provider contacts: the provider has an old named individual's email, so the warning goes to someone who has left.
• Ignoring non-malicious failures: a botched change or upgrade that takes down digital banking is treated as an IT problem rather than a potential notification incident.
• No record of the decision: the bank cannot later show when it determined the incident was notifiable, which makes the timeliness of notice impossible to defend.

Practitioner checklist

• Record your primary federal regulator's designated contact, backups and out-of-hours route in the incident plan.
• Define material portion of customers, material business lines and financial stability operations for your bank.
• Name the determination owner and log the determination time for every significant incident.
• Keep a short regulator notice template and a holding statement ready.
• Give every covered-service provider a monitored bank-designated contact and confirm it yearly.
• Write the four-hour provider notice duty and follow-up expectations into contracts.
• Exercise ransomware, provider outage, identity compromise and failed change scenarios against the clock.
• Include machine identity and AI agent compromise in incident criteria and logging.
• Map this rule with SEC, NYDFS, state breach and CIRCIA duties in one decision tree.

Standards and references

• eCFR: 12 CFR part 53, Computer-Security Incident Notification (OCC)
• eCFR: 12 CFR part 225 subpart N (Federal Reserve Board)
• Federal Register: Computer-Security Incident Notification Requirements for Banking Organizations and Their Bank Service Providers
• OCC: Bulletin 2021-55, Computer-Security Incident Notification final rule
• Federal Reserve: SR 22-4, Contact information for computer-security incident notification
• FDIC: FIL-12-2022, Computer-Security Incident Notification implementation

This guide summarises the federal banking agencies' Computer-Security Incident Notification Rule as of 27 October 2026 and is not legal advice. Related NHI Mgmt Group resources: FFIEC Cybersecurity Guidance Guide · Cyber Incident Reporting Requirements Map · GLBA Safeguards Rule Guide · Banking Cybersecurity Programme Guide · Financial Services Cyber Regulation Map