The conventional wisdom suggests updating your workflows whenever an industry framework changes. With EDRM 2.0 introducing four structural shifts, many are wondering if they should adjust their process maps to match. The answer is no, and understanding why reveals how reference models truly function.
Why EDRM 2.0 Isn't a Workflow
EDRM 2.0 isn't a workflow and never was. The trustees describe it as "intentionally broad, flexible, and high-level" and "a reference model, not a prescriptive workflow or an exhaustive technical standard." These aren't disclaimers; they're the essence of the model.
Despite this, the profession often treats the diagram as a project plan. Vendors market based on which parts they cover. Training materials present it as a sequence. RFPs quote it as if the phases were milestones. The trustees grouped public commentary into eight sections, and one commenter questioned whether the redesign was worth it. This question is more significant than it appears.
Here's what the update actually changed: Information Governance now underpins the entire lifecycle. Four early-stage activities form a Data Acquisition framework. Disposition becomes a phase, defined as "a systematic, defensible process to retain, delete, transfer, or return data after use." Analysis now spans every stage instead of being isolated.
None of this dictates how your next matter should proceed.
The Evidence Behind the Model
About 150 volunteers developed the model over two years. Public comments were collected for 30 days starting June 30. The trustees sorted submissions into eight sections. Only one section led to changes. The rest requested alterations to the diagram's content or terminology, but the trustees provided written responses explaining why no changes were made.
This ratio is telling. Commenters wanted Processing removed from the Data Acquisition grouping due to different tools and skills required. The trustees retained it, stating, "Data Acquisition is used as an umbrella grouping in the model. It's not intended to redefine Processing as Collection or suggest that the activities are technically identical."
Another commenter suggested adding an Early Data Assessment node. The trustees explained that assessment occurs at different times in different matters, and the continuous Analysis band covers it. Someone else wanted the volume curve split into separate acquisition and culling processes. The trustees noted that such detail isn't the model's purpose.
The pattern is consistent. The trustees defended the IGRM placement against a commenter who argued it overstates governance, as not all relevant data in organizations is governed. They responded with a caveat: the diagram "communicates a conceptual relationship between the models rather than an assessment of the maturity or effectiveness of any particular organization's Information Governance program."
The model describes possibilities, not what you've built.
Several public comments raised issues already settled by the project team through voting. "The result of each vote was given greater weight than individual public comments, though the substance of each individual comment was still considered," the trustees wrote. This rule for a volunteer consensus body kept the structure intact.
What to Do Instead
Test your statement-of-work language against the Data Acquisition grouping before buyers start quoting it. The grouping reflects current tool capabilities. In-place indexing allows identification, preservation, and processing to occur together rather than sequentially. If your contracts still list these as separate deliverables with distinct timelines, you're adding unnecessary friction to procurement.
Use the Disposition definition to evaluate your Records Control Schedule. The phase is defined as "a systematic, defensible process to retain, delete, transfer, or return data after use." If your retention schedule doesn't include transfer or return, you're missing two of the four disposition outcomes the model identifies.
Monitor the emerging thought leadership phase, as the terms established there may influence future procurement documents. Security teams gain a framework that names deletion as a phase, bolstering the case for minimizing breach-hold data. Legal operations should understand the diagram before it's cited in an RFP.
Don't redraw your process maps to match the model. The model isn't a process map; it's a vocabulary. Use it to describe your actions, not dictate them.
When the Conventional Wisdom Is Right
You should pay attention when an industry framework changes, but not for the reasons you might think. The diagram's authority comes from adoption. It organizes how lawyers, technologists, and judges discuss electronic evidence, a role it's played since 2005. When the shared vocabulary shifts, your ability to communicate across disciplines shifts too.
The Analysis band now spans every phase instead of being isolated. This change reflects reality: analysis is continuous, not a single event. If you're still describing analysis as a discrete phase after processing, you're using outdated language.
The relevance triangle now levels off after Production instead of climbing past it. The Analysis element ends with Disposition instead of extending beyond it. These adjustments, prompted by public comment, matter if you're creating training materials or explaining the lifecycle to new team members.
The conventional wisdom is correct about one thing: when 150 contributors spend two years on a framework, you should read what they produced. Just don't treat it as a checklist. Consider it a map that helps you ask the right questions in the right sequence, and use your judgment to answer them.
