The OCC's 2026 Cybersecurity Report Changed the Standard. Documenting Controls Isn't Enough Anymore.

TL;DR

• The OCC’s June 2026 Cybersecurity and Financial System Resilience Report shifts the examination standard from documentation to demonstrated capability. Having a BCP binder or an IR plan PDF isn’t the answer anymore — examiners want evidence you’ve tested it.
• The report names five examination expectations: understand your risks, establish appropriate controls, manage critical dependencies, prepare for disruptions, and demonstrate that you can respond and recover.
• Community banks are explicitly in scope: the report says institutions should no longer assume size makes them less attractive targets.
• Automated attacks now operate at scale — the speed of exploitation has changed, which means patching cycles and detection time matter more than they did even two years ago.
• The control list hasn’t changed much. What’s changed is the proof standard: showing tested, working controls instead of documented, assumed ones.

The OCC’s 2026 Cybersecurity and Financial System Resilience Report won’t generate the headlines that consent orders do. It’s an annual congressional submission, not an enforcement action. But it’s one of the cleaner signals the OCC sends about what examiners are actually measuring — and the 2026 edition contains a shift that compliance and risk teams should read carefully.

The shift is this: documenting that you have controls is no longer sufficient. The report is explicit that in many cases, the more valuable first step is determining whether your existing cybersecurity program works as intended — which means testing it, not just writing it down.

That’s a different examination. It’s also a harder one to pass if your program was built around policy completeness rather than operational validation.

Where the 2026 Report Sits in the Regulatory Landscape

The OCC submits this report annually to Congress under the Cybersecurity Enhancement Act. The 2026 version covers OCC examination observations, the threat landscape for OCC-supervised institutions (national banks, federal savings associations, federal branches and agencies of foreign banks), and the OCC’s own cybersecurity practices.

It is not a rule or guidance document. Violations of it cannot be cited directly. But OCC examination teams use the report’s framework when they evaluate institutions, and the “examination expectations” section maps closely to what examiners raise in their reports of examination.

The 2026 report’s core message: cybersecurity is an operational resilience issue, not an IT function or periodic compliance exercise. That framing has implications for how the risk is owned, governed, and validated.

The Five Things Examiners Now Expect

The 2026 report describes what regulators expect institutions to be able to demonstrate. These aren’t five new requirements — they’re an elevation of the standard for what “compliance” means on five dimensions that have existed in FFIEC guidance for years.

1. Understand Your Risks

This sounds basic. It isn’t. Understanding your risks in the OCC’s sense means mapping your assets, knowing what data you hold, identifying which systems and processes are critical to operations, and maintaining a current picture of how those elements connect. An institution that hasn’t updated its asset inventory since it was built in 2022 and then added three cloud services doesn’t understand its current risk.

The SVB independent review published this week found that supervisors knew about vulnerabilities as early as March 2022 but failed to act. One root cause was that risk identification and risk escalation were disconnected — the signal was there, the response was not. Understanding your risks means having a current, accurate picture and a documented path from that picture to action.

Examiner question: Show us your asset inventory. When was it last updated? Does it reflect your current vendor and cloud footprint?

2. Establish Appropriate Controls

Appropriate controls means two things: the controls are well-matched to the risks you’ve identified, and the controls are actually configured and working, not just specified in a policy document.

The 2026 report names the control list explicitly: vulnerability management, multifactor authentication, access controls, endpoint protection, employee education, network monitoring, and timely patching. None of these are new. What’s new is the emphasis on tested, configured controls over documented, assumed ones.

Multifactor authentication is the clearest example. An institution can have an MFA policy, an MFA vendor, and an MFA training program — and still have exceptions, service accounts, legacy systems, or administrative interfaces that bypass MFA. A policy that says “MFA is required” isn’t the same as MFA actually working across all access points. Examiners are checking the latter.

Examiner question: Walk us through your MFA implementation. What’s covered? What’s excluded, and why? When did you last verify coverage?

3. Manage Critical Dependencies

Institutions have always had third-party relationships. What has changed is the examination standard for understanding and managing those relationships in a resilience context.

The 2026 report frames this specifically around critical dependencies — systems, vendors, and interconnected processes without which the institution can’t operate. This is not the same as “do you have a third-party risk management program.” It’s “do you know which of your vendors would stop your institution if they went down, and do you have tested plans for what happens if they do?”

For community banks, this conversation almost always surfaces a small number of core banking providers. FIS, Fiserv, and Jack Henry collectively serve the large majority of community bank technology infrastructure. An outage at any of them doesn’t just affect one bank — it’s a sector-wide event. The cloud provider outage BCP analysis documented how regulators expect concentration risk at the vendor level to be managed and tested.

The proposed interagency TPRM guidance — proposed on September 11, 2026 — shifts to a harm-based risk standard that directly aligns with the OCC’s critical dependency framing. These two documents are converging on the same examination: show us that you know what happens if your critical vendors fail, and show us you’ve tested your response.

Examiner question: Who are your critical vendors? What’s your tested contingency plan if your core banking provider has a multi-day outage?

4. Prepare for Disruptions

The 2026 report says institutions must be prepared for disruptions. Preparation, in the OCC’s framing, means tested plans, not documented plans.

The distinction matters because BCP/DR documentation has been table stakes for years — the compliance box was checked when the institution had a written plan. The 2026 standard is that the plan has been tested under realistic conditions, gaps were identified, and those gaps were remediated.

This connects directly to the SVB independent review finding about operational readiness to borrow from the Federal Reserve’s discount window. SVB had contingency funding in its plans. It didn’t have the operational capability to access that funding quickly when it needed to. The difference between having a plan and having a working plan is the difference between documentation and demonstrated capability.

What preparation looks like under the 2026 standard:

The NYDFS Delta Dental consent order post-incident analysis illustrated exactly this: having an IR plan that’s technically present but untested and insufficiently specific produces exam findings independently of the breach itself. The response is independently enforceable from the original incident.

Examiner question: When did you last run a tabletop exercise? What did you find? What was remediated, and what’s still open?

5. Demonstrate Response and Recovery Capability

The fifth expectation is the culmination of the others: when something actually goes wrong, the institution must be able to demonstrate it can respond and recover.

This is the “prove it” standard. Not “your policies say you can respond in four hours.” Not “your contract says the vendor will notify you within 72 hours.” Not “your BCP says you’ll activate within 24 hours.” Show us you can actually do it.

For examination purposes, demonstration happens in two ways: through tested exercises (where you document what happened, how long it took, and what broke) and through actual incident handling (where your response to a real event is examined after the fact).

The OCC examines actual incident response after significant events — not just checking whether an institution had a plan, but evaluating whether the response matched the plan, whether decisions were timely and documented, and whether the post-incident review produced actionable improvements. That’s the examiner standard going forward.

The Automation Threat Has Changed the Timeline

The 2026 report specifically notes that automated attacks now operate at greater speed and scale. Threat actors are using automation to discover vulnerabilities, generate credential stuffing payloads, and move laterally through networks faster than human analysts can track manually.

What this means for patching cycles: a vulnerability that would have been exploited within 30 days of disclosure now gets exploited within days. Institutions that patch on a 30-day or 90-day cycle for non-critical systems are operating with a window that automated attackers can exploit before the patch is applied.

What this means for detection: network monitoring that generates alerts but doesn’t route them to human review quickly enough produces a detection window that automated attacks exploit. The OCC report’s emphasis on network monitoring is specifically about detection speed, not just detection capability.

What this means for community banks: smaller institutions with limited security staff are disproportionately exposed to automated attacks because they rely more heavily on automated tools without dedicated human oversight. The OCC’s explicit statement that size doesn’t create protection is directed at exactly this group.

What Your Program Needs to Do Differently

The 2026 report’s message isn’t a call to rebuild your program from scratch. The core control set — MFA, patch management, access controls, endpoint protection, monitoring — hasn’t changed. What needs to change is how you validate that those controls work.

Build a testing calendar, not just a policy calendar. Your cybersecurity program calendar should track when each critical control was last tested, not just when it was last reviewed. MFA coverage tested: Q2. Tabletop exercise: Q3. Disaster recovery exercise: Q4. Penetration test: Q1. If you can’t fill in that calendar, you have a documentation program, not a resilience program.

Operationalize your response plans. An IR plan that your team has never walked through produces poor performance when a real incident happens. Run a tabletop. Use a realistic scenario — a ransomware event that encrypts your core banking data, or a credential compromise that triggers a regulatory notification obligation. Document who made decisions, what the gaps were, and what you’ll fix. That documentation is the “demonstrated capability” the OCC is looking for.

Test your critical dependencies. If your contingency plan for a core banking outage is “call the vendor,” you need to know what happens after that call. Has your incident response team ever actually tested the manual fallback procedures? Does your staff know which transactions can be processed on paper and which can’t? The OCC wants to see that you’ve answered those questions, not that you’ve written them down.

Address community bank concentration risk proactively. If your institution is on FIS, Fiserv, Jack Henry, or any similarly concentrated core provider, document your vendor resilience analysis, confirm your contract provisions for notification and recovery, and build an explicit section into your BCP for how the institution operates if that provider has a multi-day outage. Don’t wait for an examiner to ask.

So What?

The OCC’s 2026 Cybersecurity and Financial System Resilience Report isn’t asking for new controls — it’s asking for proof that existing controls actually work. That’s a harder standard than it sounds if your program was built around documentation completeness rather than operational validation.

The gap that the report is describing is widespread. Institutions that run annual policy reviews and send annual questionnaires to vendors often have strong documentation and weak operational readiness. The SVB independent review found the same thing at a much larger scale: supervisors knew the risks, management knew the risks, and the institution still didn’t have the operational capability to execute its own contingency plans.

The OCC is telling you to close that gap now. The examination standard that follows from this report is: show us you’ve tested it, not just written it.

Running a cybersecurity or operational resilience program that’s heavier on policies than on tested procedures? The Incident Response & Breach Notification Kit includes an IR plan template, tabletop exercise guide, breach notification decision tree, and examiner-ready documentation for the exact response capability the OCC is now examining.