Post-Approval Product Change Review: When to Reopen the Risk Assessment

TL;DR

• A product change risk assessment review compares changed facts with the assumptions that supported the original approval. It is not a fresh questionnaire by default.
• Reopen when the change affects fund flows, legal obligations, customer outcomes, data use, critical vendors, operating capacity, control design, or accepted residual risk.
• Preserve the decision even when the answer is “do not reopen”: changed fact, affected domains, evidence reviewed, rationale, conditions, reviewer, and approval.
• Use targeted reassessment for a contained impact. Use a full reassessment when the product’s purpose, architecture, exposure, or approval basis has materially shifted.

The product was approved six months ago. Since then, Product added a higher transaction limit, Engineering swapped an identity vendor, Marketing changed the fee presentation, and Operations introduced a manual exception queue.

Nobody called it a new product. The original risk assessment is still marked “approved.”

That is exactly why a product change risk assessment review exists. Its job is to answer a narrower, harder question: do the changed facts still fit the decision that was approved? If they do, document why. If they do not, reopen the affected analysis before the change quietly inherits an approval it never received.

The distinction matters because the OCC defines modified products as offerings that differ substantially in “nature, terms, purpose, scale, or use” and alter the underlying risk qualities or characteristics. OCC Bulletin 2017-43, updated in March 2025, also identifies four parts of new-activity risk management: due diligence and approvals, policies and controls, change management, and ongoing performance monitoring. Approval is a control point, not a lifetime exemption from review.

Start with the approved assumptions, not the new feature description

Most change tickets describe what Engineering plans to ship. Risk needs to know what approved premise is no longer true.

Pull the original assessment and extract its decision-critical assumptions into a short baseline:

This comparison prevents a common failure: reviewing the implementation ticket while missing the original legal, operational, or customer-harm theory. A vendor replacement might look like procurement. If that vendor performs CIP verification, sanctions screening, account linking, or adverse-action logic, it is also a compliance-control change.

Owner: Product maintains the change description and intended release date. Second-line Risk or Compliance owns the disposition. The functions that approved affected assumptions own their specialist review.

Use a reopening trigger matrix

Do not reduce materiality to estimated engineering hours or revenue. A two-line configuration change can alter customer eligibility, while a six-month interface rebuild may leave the risk profile unchanged.

Use the following as a triage matrix, then calibrate it to the organization’s products and approval authorities. These are governance triggers, not regulatory safe harbors.

The interagency third-party risk management guidance issued through OCC Bulletin 2023-17 describes third-party risk management as a lifecycle and expects monitoring responsive to changes in the relationship and associated risks. That is useful discipline even when the product change originates internally: compare the current operating reality with what due diligence and approval actually covered.

Choose targeted review, full reopening, or documented no-reopen

The triage output should be one of three dispositions.

1. No reopening

Use this when the facts changed but the approved risk and control conclusions remain valid. Example: a customer-facing label changes with no alteration to eligibility, price, contract terms, disclosures, workflow, data collection, or control operation.

The record should still say:

Disposition: Do not reopen. Copy change only. Compliance compared the redline with approved disclosures PR-104 and confirmed no term, price, eligibility rule, consent, or customer action changed. Screenshot and redline attached. Approval valid as of August 20, 2026.

“Non-material” alone is not a rationale. It is the conclusion that needs support.

2. Targeted reassessment

Use this when a change affects one or more bounded domains but does not invalidate the overall product architecture or approval basis.

Realistic hypothetical: A fintech replaces its email provider. The provider receives customer names and email addresses but cannot initiate transactions, make decisions, or access account credentials. The targeted reassessment covers privacy, security, vendor due diligence, incident notice, retention, and exit. It does not rerun credit, liquidity, or funds-flow analysis unless the facts point there.

Update the original assessment by reference rather than creating a disconnected memo. Link the affected risk IDs, control IDs, conditions, and approval sections.

3. Full reassessment

Use this when the change alters the product’s purpose, customer population, financial architecture, regulatory basis, material customer outcome, critical dependency structure, or accepted residual risk. A move from ACH to instant payments is not merely a rail change if it changes irrevocability, fraud controls, liquidity timing, reconciliation, disclosures, and incident handling.

A full reassessment does not mean deleting history and completing a clean template. Preserve the original approval, create a new version, and show what changed. Otherwise the team loses the audit trail that explains why control design moved.

Route the review to the functions whose assumptions changed

A standing committee is not necessary for every edit. A routing table is.

The difficult ownership problem appears when Product calls a change “technical” and each specialist assumes another function has reviewed the downstream effect. One person—usually Product Risk, Enterprise Risk, or Compliance Operations—must own the routing record and confirm every required disposition is closed before release.

NIST’s SP 800-53 Rev. 5 Change Control control CM-3 provides a useful evidence model for system changes: determine the types of changes subject to control, review proposed changes with security and privacy impact analyses, document decisions, implement approved changes, retain records, monitor change activity, and define oversight. A product-governance record should connect that technical evidence to business, legal, and customer-risk decisions rather than duplicating it.

Build a decision record that can survive a later incident

The record should make sense to someone who was not in the meeting. Include:

1. Change ID and release: ticket, product, owner, planned date, emergency status.
2. Changed facts: plain-English old state and proposed state.
3. Baseline references: original assessment version, approval date, conditions, diagrams, legal memos, and control records.
4. Impact scan: each risk domain marked affected, unaffected with rationale, or pending specialist review.
5. Disposition: no reopen, targeted reassessment, or full reassessment.
6. Decision rationale: the evidence and assumptions supporting that disposition.
7. Conditions: pre-release tests, limits, monitoring, customer notices, or time-bound remediation.
8. Approvals: preparer, independent reviewer, specialists, and original approval authority when required.
9. Implementation evidence: release record, configuration proof, test output, and effective date.
10. Post-change monitoring: metric, owner, review date, threshold, and escalation action.

Attach artifacts; do not paste only conclusions into a GRC record. A later reviewer should be able to reproduce the decision from the evidence binder.

Handle emergency changes without creating an approval loophole

Emergency changes happen: fraud attacks, vendor outages, broken disclosures, production defects. The emergency path should change timing, not standards.

Require a contemporaneous record of the incident or threat, why normal review was impracticable, who authorized implementation, temporary limits, rollback criteria, and customer impact. Then set a retrospective review deadline in policy—an internally chosen service level, not a claimed regulatory number—and escalate overdue reviews.

A useful anti-gaming control is to reconcile emergency releases from the deployment system against product-change review records monthly. Sampling only the change register will never find the releases that bypassed the register.

So What?

This week, take the last ten production changes for one regulated product and map each to the original assessment. Ask one question: which approved fact did this change touch?

If the answer lives only in Slack, Jira comments, or someone’s memory, create the reopening record now. The goal is not to send every change back through a giant committee. It is to stop old approvals from silently covering new facts.

The New Product Risk Assessment provides the assessment, approval, money/data-flow, and pre-launch control structure that a post-approval change review needs to reference.

Related reading

• How to build the product flow-of-funds diagram
• Vendor change notifications and material-change triage
• Risk assessment evidence trails in Excel