A Matter Requiring Attention on software change controls lands with a specific weight: the examiners have written, formally, that your change management doesn't demonstrate control, and the board now owns a remediation commitment with a deadline. For technology leaders at banks and regulated financial institutions, the MRA moment is usually not a surprise about practice — teams mostly do assess, approve, and test changes — but about proof: the examination sampled changes and the evidence couldn't carry the weight. Remediation, done right, fixes the proof architecture, not just the finding.
This guide covers how to read a change-control MRA, the remediation plan that satisfies examiners on re-review, and the evidence build that closes the matter permanently instead of renting a clean exam.
Strip the supervisory language and change-control MRAs reduce to a sampling failure with one of three roots. Population: deploys occurred that mapped to no change record — the "unauthorized change" framing that alarms boards. Attribution: approvals existed but couldn't demonstrate authority or timing — email chains and meeting minutes that don't bind to the deployed artifact. Continuity: testing or verification evidence expired or never linked. Identify which root(s) your MRA describes, because the remediation differs: population problems need workflow coverage; attribution problems need policy-executed approvals; continuity problems need capture-at-source with durable retention. A plan that answers the wrong root produces a clean paragraph and a repeat finding.
Supervisors evaluate remediation plans on sustainability. The structure that works: root cause stated plainly (evidence architecture, not individual lapses — blaming people commits you to firing your way to compliance); structural remediation — every production change anchored to a structured change request scoped by system, authorization executed as approval policy recording identity, role, and timestamp against the artifact, and test and deployment evidence bound automatically with examination-grade retention; self-testing cadence — a quarterly sampling drill with results reported to the board committee that owns the MRA. Milestones should be capability dates ("all in-scope changes policy-approved by Q2") rather than activity dates ("procedure revised"), because capability is what re-review samples.
The difference between MRA closure and MRA recurrence is validation. Before your response date, run the examination against yourself: pull the deploy population for the remediated period, sample as the examiners did, and produce full chains — timed, documented, with the Release Compliance Dossier as the artifact per sampled change. Reconcile the population completely; every deploy maps to an authorized change or a documented standing exception. Then package the validation itself as evidence: examiners re-reviewing an MRA weigh a self-test with results far above a procedures binder. Compliance objectives tracking the control's operation give the board its ongoing assurance line — and you a standing answer for the next exam cycle.
Institutions that remediate with procedure revisions and heroic cleanup pass re-review and re-earn the finding two cycles later, because the architecture that produced weak evidence still runs. The permanent fix is the one where evidence generation is a property of shipping: approvals that can't be backfilled, populations that reconcile by construction, retention that outlives lookback. That version costs a quarter of implementation and returns it every examination thereafter — and it converts the MRA from a supervisory wound into the budget authorization the evidence architecture always needed.
An MRA on change controls is examiners telling you your proof failed, with a deadline. Respond with architecture: structured changes, policy-executed approvals, automatic evidence binding, and a self-testing cadence you report upward. Validate with your own sample before they run theirs — and close the matter in a way that never lets it reopen.
An evidence failure surfaced by sampling, with one of three roots: population (deploys mapping to no change record), attribution (approvals that can't demonstrate authority or timing), or continuity (testing and verification evidence expired or unlinked).
Root cause stated as architecture rather than individual blame, structural remediation — structured changes, policy-executed approvals, automatic evidence binding with examination-grade retention — and a quarterly self-testing cadence reported to the owning board committee.
Run the examination on yourself: pull the deploy population for the remediated period, sample as the examiners did, produce full chains timed and documented, and reconcile the population completely — then package the self-test as evidence.
They rent a clean re-review while the architecture that produced weak evidence keeps running — the finding recurs cycles later. Sustainable closure means evidence generation as a property of shipping: approvals that can't be backfilled and populations that reconcile by construction.