DataGovernance.ca working methods · Original planning guidance. Examples are illustrative, not client results or a regulatory framework.
Describe what is changing.
Start with the old and proposed field, meaning, source, permission or processing step. Identify the requester, business reason and desired timing. A renamed field is not necessarily a change of meaning; an unchanged name does not prove the meaning is stable. Record whether the request is a correction, a new requirement or a temporary exception. Keep an example of the current behaviour so the review has something concrete to compare.
Trace the affected uses, including the uncertain ones.
Work outward from the source to transformations, reports, exports, vendor transfers and AI indexes that are within scope. Ask the relevant owners to confirm the links. A diagram is a starting hypothesis until those relationships are supported. Mark unverified downstream uses explicitly. The review can remain bounded, but its boundary must be visible to whoever accepts the change. Do not present an incomplete inventory as proof that nothing else is affected.
Agree who can approve the consequence.
The technical person who can deploy a change may not be the person authorised to accept its business or privacy implications. Separate the proposed implementation from the decision about acceptable impact. Record the decision owner, required specialist input, conditions, effective date and any temporary exception. Escalate unresolved legal or contractual questions to the appropriate advisers rather than treating a technical sign-off as an answer.
Test what must work and what must not.
Define expected results before implementation. A renamed column may need a mapping test and a downstream report comparison. A changed definition may need before-and-after results on the same sample. An access change needs negative tests: can the excluded role still retrieve a cached copy, export or indexed passage? Use authorised test data and record what was not tested. A green deployment indicator is not evidence that these outcomes were checked.
Prepare the release and reversal decision.
Agree an owner for the change window, communications and observation. Record the conditions that would trigger a pause, reversal or further investigation. Some changes cannot be cleanly reversed, such as an approved disposal action; those need a different decision and evidence standard. Do not invent a universal rollback promise. Keep the operational plan specific to the system and the authority actually available.
Close the loop with evidence.
Record what was changed, when, by whom, the result of the agreed tests and any unresolved effects. Update the inventory and definition records that are genuinely affected. Let users know when earlier comparisons need qualification. Close a change only when its agreed acceptance criteria are met, not merely because the request ticket is old. Carry unresolved items into a named owner’s queue with a review date.
Start with one concrete example.
Use the related resources to prepare a bounded conversation. Keep confidential records in your approved internal environment.