◆ Quick answer
An issues management tracker should include issue ID and title, how the issue was identified (self-identified, audit finding, regulatory exam, third-party review), risk category, impact and likelihood ratings, issue owner and business area, date identified, target remediation date with extension justification, nested action plans, status, second-line reviewer, days open and days overdue, root cause category, and a progress check-in log.
Guide vs. template
This guide explains what belongs in the template. The paid template gives you the editable working files so you're not rebuilding from a blank page.
Paid template includes
- ◆ Issues Register with automatic risk rating, days open, days overdue, and status flags
- ◆ Checks column that flags target dates past the limit for the risk rating without an extension justification, ratings below the regulatory floor for MRAs, MRIAs and consent orders, and finding IDs that don't match the Exam tab
- ◆ Exam & Regulatory Findings tab: regulator reference, finding type, management response, and response and remediation deadlines
- ◆ Root Cause Analysis tab: 5-Whys worksheet with root cause category and systemic-issue flag
What is this template for?
An issues management tracker is the working register risk and compliance teams use to carry every finding — a Matter Requiring Attention (MRA) from an exam, an internal audit finding, or a self-identified gap — from identification through remediation to validated closure. The useful version does four things a plain to-do list can't: it rates each issue for impact and likelihood so severity is comparable across the register, it breaks each issue into nested action plans with their own owners and dates, it tracks aging and overdue days so escalation is automatic rather than political, and it requires second-line review before anything gets marked closed.
◆ Audience
Who needs this.
- ◆ You're managing Matters Requiring Attention (MRAs) or audit findings in a spreadsheet with no status, ownership, or aging visibility.
- ◆ Your risk committee keeps asking about overdue issues and you can't answer without rebuilding a deck.
- ◆ You're a compliance team of 1–3 people juggling 10–100 open findings from exams, audits, and self-identification.
- ◆ Your bank partner asked to see your issues management process and what you have isn't presentable.
- ◆ Issues get "closed" by the same person who owned them, with no evidence and no second-line sign-off — and internal audit noticed.
◆ Required fields
What every row needs.
The fields that make this template defensible to an auditor, bank partner, or examiner — and what goes in each.
| Field | Why it matters | Example |
|---|---|---|
| Issue ID, title, and description | A stable ID lets action plans, reviews, and reporting reference the issue unambiguously. | ISS-2026-002 — Critical cloud vendor missing current SOC 2 Type II report: primary cloud infrastructure vendor has not provided a SOC 2 Type II report for the current period |
| How the issue was identified | Source type drives regulatory sensitivity and reporting. Self-identified issues demonstrate a working risk culture; repeat exam findings are the opposite. | Self-Identified; Internal Audit; Regulatory Exam; Bank Partner; Third-Party / SOC Report; KRI Breach |
| Impact and likelihood ratings | A documented rating scale makes severity comparable across the register and defensible when challenged. Impact 4 – Severe means things like >$5M loss, >100K customers affected, or a consent order. | Impact 3 – Significant × Likelihood 3 – Likely → High on the 4×4 heat map. Remediation limits follow the resulting risk rating: Critical 30 days, High 60, Medium 90, Low 180 |
| Issue owner and business area | One named accountable owner per issue — not a department. Orphaned issues are the ones examiners find still open two years later. | Sarah Chen, BSA Officer — Compliance / AML; Alex Kim, VP Engineering — Engineering |
| Target remediation date, revised date, and extension justification | Silent date slippage is how a 90-day fix becomes an 18-month embarrassment. Extensions are allowed; undocumented extensions are not. | Original target stays on the record; a revised target date needs a written extension justification naming the approver, and overdue days count from the revised date |
| Nested action plans with their own owners and dates | Issues don't get remediated as monoliths. Each action plan is separately owned, dated, and statused, so "In Progress" means something specific. | AP-004a — Automate the provisional credit trigger at business day 8 (In Progress); AP-004b — Remediate the 7 late disputes and re-sample 40 new ones (Complete) |
| Second-line reviewer and reviewer status | The person who fixed the issue doesn't get to declare it fixed. Independent validation before closure is what exam-ready looks like. | James Rivera, Risk Manager — reviewer status: Not Yet Required while remediation is in progress; sign-off required at closure |
| Days open, days overdue, and escalation flag | Aging is the metric management actually acts on. Automatic overdue counts remove the awkward judgment call about when to escalate. | Days open calculated from date identified; the flag shows overdue once the target (or revised target) date passes, and a separate check flags a target date beyond the limit for the rating with no extension justification |
| Root cause category | Closing the symptom without the cause is how issues reopen. Categorized causes feed trend reporting — five "Process" root causes in one function is a finding in itself. | People; Process; Technology; External |
| Progress notes / check-in log | A dated running log is the difference between "we're on it" and demonstrable progress when a reviewer or examiner asks. | 2026-06-02: Vendor confirmed rules engine supports P2P. 2026-08-20: 12 of 18 scenarios live in user acceptance testing. |
◆ Worked example
Example issue with nested action plans
| Issue | ISS-2026-001 — BSA/AML transaction monitoring does not cover P2P transfers: automated monitoring does not cover peer-to-peer flows launched in Q1 2026, leaving ~15% of volume unmonitored. Self-identified; Compliance Risk; Impact 4 – Severe × Likelihood 3 – Likely = Critical (30-day limit). |
|---|---|
| Ownership and dates | Issue owner: BSA Officer. Second-line reviewer: Risk Manager. Identified 2026-05-12; target 2026-06-11 (30 days); revised target 2026-10-15 with a written extension approved by the CRO and a daily manual review of large P2P transfers as a compensating control; status In Progress; root cause category: Process. |
| Action plan 1 | AP-001a — Configure 18 P2P detection scenarios with the transaction monitoring vendor. Owner: AML Ops Lead; due 2026-09-15. Progress: 12 of 18 scenarios in user acceptance testing on 8/20; all 18 in production 9/12. |
| Action plan 2 | AP-001b — Lookback: run 6 months of P2P transactions through the new rules and file SARs if warranted. Owner: AML Ops Lead; due 2026-10-15; starts after AP-001a. |
◆ Implementation roadmap
How to roll this out.
Load every open finding into one register
Owner · Risk or compliance lead
Output · All exam findings, audit issues, and self-identified gaps in a single tracker with IDs, sources, owners, and dates — no more parallel spreadsheets
Rate each issue using a documented severity matrix
Owner · Issue owner with risk challenge
Output · Impact × likelihood ratings on a 4×4 scale with defined financial, customer, regulatory, and reputational thresholds — and remediation limits tied to the resulting risk rating (Critical: 30 days; High: 60; Medium: 90; Low: 180), with a higher minimum rating for MRAs, MRIAs and consent order items
Break each issue into owned, dated action plans
Owner · Issue owner
Output · Nested action plans under each parent issue, each with its own owner, due date, status, and dependencies
Assign second-line reviewers and define closure standards
Owner · Risk manager / second line
Output · A named independent reviewer per issue and a closure checklist: remediation complete as documented, evidence collected, root cause addressed, sign-offs recorded
Run aging and escalation reporting on a monthly cadence
Owner · Risk or compliance lead
Output · Dashboard view of open issues by risk rating, overdue counts, aging, and what is due in the next 30 days — the snapshot your risk committee actually wants
◆ Ready to use it?
Download the Issues Management Tracker & Template.
Use the guide to understand the structure, or buy the editable template to move faster.
◆ FAQ
Frequently asked questions.
What fields should an issues management tracker include? ⌄
At minimum: issue ID and title, how the issue was identified, risk category, impact and likelihood ratings, issue owner and business area, date identified, target remediation date with extension justification, nested action plans with their own owners and dates, status, second-line reviewer, days open and overdue, root cause category, and a dated progress log. The fields that separate a real tracker from a to-do list are the severity ratings, the second-line review, and the aging math.
How do I rate the severity of an issue? ⌄
Use a documented impact × likelihood matrix rather than gut feel. Rate impact 1–4 across financial, customer, regulatory, and reputational dimensions — for example, Severe (4) means >$5M loss, >100K customers affected, or consent-order-level regulatory exposure, while Minor (1) means <$100K and no external visibility. Rate likelihood 1–4 based on frequency indicators (Almost Certain = has occurred multiple times in the past 12 months). The heat map combines the two into a risk rating, and the rating drives the remediation clock: Critical issues get 30 days, High 60, Medium 90, Low 180.
What is the difference between an issue and an action plan? ⌄
The issue is the problem — a transaction monitoring coverage gap, a missing vendor SOC 2 report. Action plans are the discrete work items that remediate it, nested under the parent issue with their own owners, due dates, and statuses. An issue stays open until all its action plans are complete and a second-line reviewer validates closure. Tracking only at the issue level is how "In Progress" becomes a status that means nothing for six months.
When does an issue need a due date extension, and how should it be documented? ⌄
Any time the original target remediation date will be missed. Record a revised target date plus a written extension justification, and keep the original date visible — the tracker should show both the slip and the reason. Undocumented date changes hide slippage, and silent slippage is the signature of a weak corrective action program.
Who should perform second-line review before closure? ⌄
Someone independent of the remediation — typically a risk manager or second-line analyst who was not the issue owner. Their closure check confirms the remediation was completed as documented, evidence was collected, the root cause (not just the symptom) was addressed, and related items were updated. First-line self-closure without independent validation is a common weakness auditors and examiners look for, because it is how issues come back as repeat findings.
How is an issues tracker different from a risk register? ⌄
A risk register inventories risks that could happen and scores exposure. An issues tracker manages problems that already exist — control gaps, findings, deficiencies — through to remediation. They connect: a serious issue often reveals a risk that belongs in the register, and a risk assessment often surfaces issues. But merging them into one sheet muddles two different lifecycles: risks are monitored indefinitely, issues are driven to closure.