SR 26-2 vs FFIEC IT Examination Handbook: Where AI Model Risk Meets IT Controls

Scope and intent: two different organizing principles

The Federal Reserve publishes SR 26-2 as Revised Guidance on Model Risk Management (the letter page is dated April 17, 2026). It is principles-based. It states that model risk management practices appropriately vary among banking organizations based on their risk profiles and model usage, and that each organization is ultimately responsible for adopting practices that are appropriate and effective for the risks it faces. Its attachment says all components of the model lifecycle benefit from governance supported by clear policies and effective controls. The themes are governance, policies, inventory, validation and internal audit.

The FFIEC IT Examination Handbook has a different shape. It is a multi-booklet set of 11 booklets, covering topics such as IT risk management, cybersecurity, third-party management, architecture, infrastructure and operations, development, acquisition and maintenance, and audit. The Architecture, Infrastructure, and Operations booklet was issued on June 30, 2021 and replaced the 2004 Operations booklet. The booklets include examination work programs, and the OCC has said its examiners use the handbook for detailed IT information and work programs.

In short, SR 26-2 asks whether the institution manages the risk of a model across its life. The FFIEC booklets ask whether the technology environment around it is controlled. An AI system sits in both frames at once, and the two are best read as complementary. As of November 2026, the sources reviewed for this page do not state SR 26-2's operative date, so confirm timing against the primary text.

Side-by-side by control objective

Organizing by control objective avoids comparing document structures that were never designed to line up. The mapping below is an analytical aid, not language taken from either document. Each row ends with the question that tends to fall between the two functions.

• Inventory: SR 26-2 describes an inventory with enough information to understand model risk individually and in aggregate. The FFIEC IT risk management material addresses IT risk management structure. Open question: does one AI system inventory serve both teams, and who documents why a system is in or out of model scope?
• Access and permissions: SR 26-2 is not framed around user access. The Federal Reserve's IT guidance names authentication and user access controls as vital to information security. Open question: what is an AI agent's identity permitted to do per interaction and per tool call?
• Change and monitoring: SR 26-2 covers the model lifecycle under governance. The FFIEC Development, Acquisition, and Maintenance and AIO booklets cover change and operations. Open question: who owns monitoring of what the system does in production, as distinct from how it performs?
• Third-party dependencies: The FFIEC Management booklet addresses an effective third-party management program. Open question: how are hosted models, tool servers and coding assistants reflected in both the model inventory and the third-party program?
• Incident response: Incident handling sits primarily with IT and security programs. Open question: when an AI action causes harm, how does the record reach model risk, and who decides on escalation?
• Evidence and documentation: SR 26-2 expects policies and internal audit evaluation of whether practices are implemented. The FFIEC set includes an Audit booklet and work programs. Open question: can one evidence set answer both?

Where the two frames meet and where they diverge

The overlap is clearest in governance and audit. SR 26-2 treats internal audit as evaluating whether model risk management practices are rigorous and effective and whether policies are implemented accordingly. The FFIEC Audit booklet serves a similar function for IT. Both expect written policy, and both expect someone independent to test whether the policy is real.

The divergence is in vocabulary and trigger. Model risk teams speak of model definitions, tiers, validation and findings. IT and security teams speak of systems, assets, configurations, access and incidents. A system may be in scope for one function and not the other. One public commenter on a Federal Reserve proposal characterizes SR 26-2 as excluding deterministic rule-based processes from the model definition. That is a commenter's reading, not a Fed statement, but it illustrates why scoping needs a documented rationale. A system outside the model definition can still be fully inside the IT control environment.

Validation is another divergence. Model validation is a model risk activity. The FFIEC booklets do not substitute for it, and IT controls do not replace it. Treating the frames as complementary means each function keeps what it owns and agrees on where the handoffs are.

The runtime layer between the documents

Consider the question an examiner might plausibly ask: what was this AI system permitted to do in production, and what did it actually do? This is a practitioner scenario, not a stated requirement of either document.

Answering it requires two records. The first is the policy in force at the time: which actions were allowed, which data had to be redacted, which calls were blocked or required human approval. The second is the per-interaction record of what happened under that policy. Model documentation describes intended behavior. IT configuration records describe the environment. Neither by itself shows the decision made on a specific prompt or tool call.

Because both frames are principles-based or topic-based, the institution decides how to close this gap. Many will start with access controls and monitoring they already have. The tradeoff is that controls applied around the AI system, or reviewed after the fact, can show what was configured but not always what was enforced on each interaction. Controls in the execution path can produce that record directly, at the cost of adding a component that must itself be governed, tested and retained.

One approach: policy enforcement in the execution path

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. Enforcement happens at runtime, not after the fact, and the enforcement decision itself generates audit-ready evidence. That evidence is mapped to named control objectives from frameworks including NIST, NYDFS and NAIC. Institutions would map it to their own SR 26-2 and FFIEC control objectives. The platform can be self-managed in the customer's cloud, with configurable retention and data residency. Trussed has run continuously in production in a regulated enterprise for more than 18 months.

The scope is deliberately narrow. Trussed does not perform model validation and does not provide model lineage or dataset provenance. Those remain with model risk functions. It also does not guarantee compliance with SR 26-2 or the FFIEC handbook. Accountability for adopting effective practices stays with the institution.