How Bank Internal Audit Functions Test Compliance with SR 26-2

What the third line is being asked to conclude

SR 26-2 is a Federal Reserve supervisory letter dated April 17, 2026, expected to be most relevant to banking organizations with more than $30 billion in total assets that the Federal Reserve regulates. As of November 2026, that is the applicability statement an audit program should record in its scoping memo, along with the institution's own conclusion on how the letter applies.

Internal audit sits in the third line of defense. Its job is not to restate management's compliance assertions or to perform the first or second line's controls. It provides independent assurance on whether the controls that implement the letter exist, are suitably designed and operate. Part 30, Appendix A expects an internal audit system appropriate to the institution's size and the nature and scope of its activities, and expects the audit committee or board to review the effectiveness of that system. Independence is therefore a program design requirement. Testers should not have built, owned or operated the controls they test.

The first working document is a mapping from each expectation in the letter to one or more control objectives, with an approver recorded. Auditors who skip this step tend to test whatever documentation is easiest to collect rather than what the letter expects.

Scoping the audit universe

Scope follows the audit universe. The universe should be built from a complete and current inventory of material processes, products, services and functions, each with a risk assessment that includes emerging risks. It should be documented and reviewed at least during annual planning and whenever significant changes occur. For this audit, a new model, a material model change or a new AI-enabled use case in a consequential decision is a trigger for refresh.

The audit plan is derived from the control risk assessment, and the audit committee should review and approve the control risk assessment and plan scope at least annually. Record why each SR 26-2 area is in or out of scope in a given cycle. Examiners read scope decisions as closely as findings.

• Reconcile the model and AI use-case inventory against independent sources such as procurement records, system access lists and change tickets, not only the first line's register.
• Rank each use by decision impact, customer effect, model complexity, vendor dependence and rate of change.
• Include third-party and vendor models, and check whether contracts provide audit rights and describe the reports the bank is entitled to receive.
• Document exclusions and the reasoning, and state the planned timing and frequency of coverage.
• Obtain audit committee approval of scope, and revisit it when the environment, activities or systems change materially.

Design effectiveness, operating effectiveness and sampling

Control testing determines either the appropriateness of a control's design or its operating effectiveness. Keep the procedures separate, because a control can be well designed and not operate, or operate consistently and still not address the objective.

Design testing is a walkthrough plus document inspection. For each control objective, ask who performs the control, what triggers it, what inputs it uses, what exception handling exists and what record it leaves. Conclude whether, if performed as described, the control would meet the objective. A control that leaves no retrievable record can be designed adequately and still be untestable, which is itself a design observation.

Operating testing asks whether the control ran as designed across the period. Select items from a population the auditor obtains directly, such as system-generated change lists, access records or inference-level records, rather than a population supplied as a management extract. Sample size and method should reflect the risk of the control and its frequency. Manual, periodic controls usually call for sampled inspection. Automated controls that produce complete system records can often be tested against the full population or a configuration review plus a smaller confirmation sample. Whatever the approach, record the population, how completeness was established, the selection method and every exception.

Point-in-time documents such as a policy, a validation report or an attestation support design conclusions. They are weak support for operating conclusions about a system that makes decisions continuously.

Evidence by control area and how durable it is

The table below maps common model risk control areas to evidence an auditor can obtain independently. It is a working aid for the program, not a statement of what the letter requires. Durability describes whether the record is system-generated, retained and reviewable later without relying on recollection.

• Inventory and risk tiering: Evidence: register, tiering rationale, reconciliation to procurement and access data. Durability: moderate. Common gap: shadow AI use absent from the register.
• Validation and challenge: Evidence: validation reports, issue logs, approval records. Durability: moderate. Common gap: report is dated before later changes.
• Change management: Evidence: change tickets, approvals, deployment records. Durability: high where system-generated. Common gap: changes to prompts, thresholds or tools outside the ticketing process.
• Access and usage: Evidence: entitlement lists, usage records, tool-call records. Durability: high when produced by the system. Common gap: records that show access but not what was done.
• Exceptions and escalation: Evidence: override records, human approval records, escalation timestamps. Durability: varies. Common gap: approvals held in email or chat.
• Ongoing monitoring: Evidence: performance reports, threshold breaches, follow-up actions. Durability: moderate. Common gap: reports show results but not action taken.

Reporting findings and validating remediation

An audit report generally presents purpose, scope and results, including findings and conclusions, supported by adequately documented work. For SR 26-2 work, each finding should trace to a control objective, a test procedure, the population and sample, and the specific exceptions. A reviewer who was not on the engagement should be able to follow the chain without asking the auditor.

Rate findings on the risk to the objective, not on the volume of exceptions. State plainly where a conclusion is limited because the control left no independent record. That is a legitimate finding, and it is more defensible than inferring operation from policy.

When an issue owner says remediation is complete, perform validation work before closure. Re-test the control over a period long enough to show it operates, and use the same independent population approach as the original test. Protect workpapers for integrity, confidentiality and availability, remembering that supporting documents may contain customer data, and retain them in a form examiners can review. If audit work is co-sourced or outsourced, the audit committee should consider the extent of reliance on the vendor.

Where runtime enforcement can supply audit evidence for AI systems

For AI-enabled systems used in consequential decisions, the evidence question is concrete: what was the system permitted to do, and what did it do? Controls that act only before deployment or after the fact leave the auditor reconstructing operation from documents. Controls enforced in the execution path produce records at the moment of each action, which supports operating effectiveness testing against a full population.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. It can allow, redact, block, rate limit or escalate an interaction or tool call for human approval, and that enforcement generates continuous audit-ready evidence. Deployment is self-managed in the customer cloud, with configurable retention and data residency, which matters when an auditor needs records to remain available for examiner review. Evidence is mapped to frameworks including NIST and NAIC. Trussed is deepest in insurance, another regulated financial sector, and has not been presented here as deployed at banks.

The scope is deliberate. Enforcement covers individual interactions and tool calls. It does not replace model validation, model lineage or end-to-end tracing of agentic workflows, and an audit program should test those through other controls. Auditors should still test the enforcement layer itself: its policy configuration, change history, retention and who can alter it.