A written risk management plan is the artifact bank examiners ask for first, yet most institutions do not treat it as the operating document it needs to be. The OCC Heightened Standards, the FFIEC IT Examination Handbook, and NCUA enterprise-risk expectations all assume a current, documented plan exists and that day-to-day risk activity reflects it.
For a bank or credit union, a risk management plan is a written document defining how the institution identifies, assesses, responds to, monitors, and reports on risks across the enterprise. This guide focuses on that financial-institution view.
What Is a Risk Management Plan?
The plan is not the framework and not the program. The framework is the conceptual model the plan is built on: COSO ERM 2017, ISO 31000:2018, the FFIEC IT Examination Handbook, or the NIST Risk Management Framework.
The program is the continuous operational practice the plan describes. The plan ties the framework and the program together. A risk register, by contrast, is the inventory of identified risks and their attributes; the plan describes how the register is built, scored, and maintained.
For a bank or credit union, the plan should map directly to the FFIEC IT Examination Handbook’s Management booklet expectations on risk identification, measurement, monitoring, and control. The OCC’s Comptroller’s Handbook on Corporate and Risk Governance walks through expectations for institutions subject to its Heightened Standards.
Core Components of a Risk Management Plan
A defensible plan contains eight components, each present in PMBOK, ISO 31000, COSO ERM 2017, and the FFIEC handbook in some form.
The table below maps each component to its primary source standard and the examiner-ready artifact it produces:
| Component | Primary source standard | Examiner-ready artifact |
|---|---|---|
| Scope and objectives | ISO 31000:2018 (clause 6.3.2) | Plan section 1: written scope statement |
| Risk taxonomy and categories | COSO ERM 2017, FFIEC IT Handbook | Risk register with consistent categories |
| Risk methodology | PMBOK 7th edition, ISO 31000:2018 | Likelihood × impact scoring rubric, inherent vs residual logic |
| Risk appetite and tolerance | COSO ERM 2017, OCC Heightened Standards | Board-approved appetite statement and KRI thresholds |
| Roles, three lines of defence | IIA Three Lines Model 2020, OCC 12 CFR Part 30 Appx D | RACI matrix, board reporting structure |
| Reporting and escalation cadence | FFIEC IT Handbook Management booklet | Heat maps, board pack, exception reports |
| Resources and technology | COSO ERM 2017 | Software inventory, budget allocation |
| Review and approval workflow | ISO 31000:2018 (clause 6.6) | Annual review log, board sign-off, change record |
Scope and objectives describe what the plan covers and what it excludes. An enterprise plan should clarify the bank’s mortgage subsidiary, its insurance affiliate, and its third-party processors.
A risk taxonomy is the consistent vocabulary the institution uses across functions. Most banks adopt a hybrid taxonomy:
- Top-level categories aligned to Basel III (credit, market, operational, liquidity, strategic, reputational)
- Sub-categories tailored to their business mix.
The methodology defines how risks are scored. The choice between qualitative likelihood-and-impact scales, semi-quantitative scoring, and fully quantitative loss modelling is a function of the institution’s data maturity.
Inherent versus residual logic is the methodology detail examiners most often probe. Risk appetite and tolerance statements translate the board’s strategic posture into thresholds the second line can monitor against.
Roles, responsibilities, and the three lines of defence describe:
- Who owns identification
- Who challenges
- Who provides assurance
The Institute of Internal Auditors refreshed its Three Lines Model in 2020, and most current FI plans now reflect the updated language. Reporting and escalation cadence describes how risk information moves up the organization. Resources and technology describe the operating system that supports the plan, and the review workflow describes how the plan stays current.
Step-by-Step Process to Develop a Risk Management Plan
Building a plan from scratch is a six-step process drawn from ISO 31000:2018 and PMBOK 7th edition. Mature institutions cycle through the same steps annually as a refresh.
- Establish Context: The plan owner documents the internal environment (business mix, geography, technology stack, three-line structure), the external environment (regulatory perimeter, peer benchmarks, macro conditions), and the strategic objectives the institution is pursuing.
- Identify Risks: Workshops with first-line owners, a review of prior examiner findings and internal audit issues, key risk indicators trending in the wrong direction, loss event data, and third-party feeds all feed the draft risk register. Conduct likelihood and impact scoring, inherent versus residual evaluation, and prioritisation against the appetite statement. Risk-and-control self-assessment (RCSA) workshops are the typical mechanism in financial services.
- Response Planning: Choose between accepting, mitigating, transferring, and avoiding for each risk identified. Controls map to the risks they address.
- Implement and Monitor: Conduct control testing, KRI updates against thresholds, and issue tracking through remediation.
- Report and Review: This includes board cadence, examiner-ready artifacts, and a scheduled refresh of the plan.
A realistic timeline for a community bank building a first-time plan is eight to twelve weeks. The annual refresh runs four to six weeks. Larger institutions with more complex risk surfaces plan for longer.
Risk Management Plan Templates and Standards
Practitioners rarely build a plan from a blank page. Several standards-based templates supply the structural skeleton, and the choice between them is mostly a function of audience and regulator.
- PMBOK 7th edition supplies the project plan template (scope, methodology, register, response strategies, monitoring, and closure).
- ISO 31000:2018 supplies a principles-based framework adaptable to any organization.
- COSO ERM 2017 supplies the enterprise template: five components (governance and culture; strategy and objective-setting; performance; review and revision; information, communication, and reporting) and twenty principles.
- The FFIEC IT Examination Handbook Management booklet supplies the examiner-ready expectations.
- NIST SP 800-30 Revision 1 supplies IT-risk-specific assessment guidance most institutions layer on top of the enterprise plan.
- The HHS Risk Management Plan Template is a federal-grant-style template with open distribution.
Choosing among templates is mostly about audience. A community bank refreshing its enterprise plan starts with COSO ERM 2017, layers FFIEC handbook expectations, and references PMBOK only for the project work the plan governs.
A credit union substitutes NCUA Supervisory Letter 13-12 for the OCC standards. A bank-owned insurance subsidiary additionally references the NAIC Own Risk and Solvency Assessment (ORSA) Guidance Manual.
How Software Operationalises the Risk Management Plan
A written plan delivers value only when it operationalises into daily work. This is where a risk management system earns its place. The risk register, control library, KRI dashboards, issue tracking, board reporting, and audit trail live in one environment.
Workflow automation moves issues through identification, assessment, remediation, and closure with attribution and timestamps. Regulatory-change feeds notify the second line when a rule changes that touches a control. Examiner-ready exports replace the multi-week scramble to reconstruct evidence.
Platforms such as Predict360 implement this in a banking-specific way, where the modules are pre-mapped to FFIEC handbooks and OCC bulletins, so the plan’s components flow into operational evidence. This includes the:
- The risk-register
- Control-library
- Regulatory change
A plan operationalised in software produces the documentation regulators expect. The connection back to the plan is the audit trail. When an examiner asks who approved a risk-acceptance decision, the plan describes the workflow and the software produces the evidence.
Frequently Asked Questions
What is the difference between a risk management plan and a risk management framework?
A risk management plan is a written document describing how a specific organization will identify, assess, respond to, monitor, and report on risks. A risk management framework is the conceptual model the plan is built on (COSO ERM 2017, ISO 31000:2018, NIST RMF, or FFIEC). The framework supplies the structure while the plan tailors it to the institution.
Who is responsible for the risk management plan in a bank or credit union?
The chief risk officer or head of risk owns the plan operationally. The board approves it and reviews material changes annually. The first line operationalises it, the second line independently challenges, and the third line provides assurance through internal audit. The OCC Heightened Standards make these accountabilities explicit for covered banks.
How often should a risk management plan be reviewed?
Annually at minimum. Material changes should trigger an interim refresh. The PRA’s 2023 thematic review and US examiner feedback both flag refresh discipline as a common weakness.
What is the difference between a project risk management plan and an enterprise risk management plan?
A project risk management plan covers a single delivery effort (its scope, schedule, and budget). An enterprise risk management plan covers the institution’s full risk surface under a single governance structure. The project register should roll up to the enterprise register where exposures are material.
For a deeper view of how the plan operationalises across multiple risk domains, the integrated risk management explainer covers the IRM operating model and the consolidation pattern most institutions follow.
Stay informed about the latest in compliance and risk management technology.
Sign Up- GRC Insights
- Industry Updates
- Product Information
- Additional Resources