Versioning consent text without losing the customer context

A consent record becomes difficult to explain when it points to a notice that has since changed. The customer may have seen a shorter purpose, a different translation or a screen with another set of choices. Keeping only today’s wording can erase that context.

Versioning should preserve the meaning of the decision at the time it was made. It should also help the team decide whether a later change is an editorial correction, a new purpose or a change requiring a different customer interaction.

Keep the notice and the event separate

Create a controlled notice register. Each published version should have a stable identifier, its approved text, language, purpose references, publication period and approval record. A customer’s event can then point to the version displayed.

This avoids storing the same full notice in every event. It also avoids relying on a public webpage that might be edited without preserving its previous content.

The DPDP Act’s section 6(10) places the burden of proving the required notice and consent on the fiduciary when consent-based processing is questioned in a proceeding. A versioned register is one practical evidence design; the Act does not prescribe this exact database schema.

That provision belongs to the substantive phase scheduled for 13 May 2027 under the commencement notification. The design is useful readiness work, while existing duties and business commitments should be assessed separately.

Record what the customer actually encountered

A meaningful event needs more than “accepted version 3”. Which purpose did the version concern? Which language was displayed? Was the choice made by the customer through an account, or entered through an approved assisted process? Was saving completed?

Store only the context needed to answer those questions. A screenshot of the customer’s entire session may expose unrelated account details and still fail to show the final recorded action. Prefer structured evidence where it can accurately represent the interaction.

OpenTelemetry’s minimisation guidance offers a useful general principle: keep data that serves the defined operational purpose. Apply the same discipline to consent evidence, with a separately reviewed retention policy.

Internal references may still be personal data when they link back to a customer. Protect the record accordingly.

A hypothetical translation update

Suppose a neighbourhood fitness studio offers an optional monthly newsletter. Its English and Hindi notices are approved together. Later, an editor improves the Hindi wording without changing the described purpose.

The team should create a new approved version and record its effective date. Earlier choices continue to point to the wording the customer saw. The release record explains that the change was linguistic rather than a broader use of data.

Now imagine the marketing team wants to share the list with an unrelated business. That is a different proposed processing activity. Updating the text silently and attaching all old choices to the new version would misrepresent the historical decision.

The team must assess the new purpose and applicable ground, then determine the appropriate notice and customer interaction. Version numbers are evidence identifiers, not a mechanism for expanding consent.

Avoid versioning the wrong object

A software release number does not necessarily identify a notice version. One application release may contain several languages, experiments or channel-specific screens. Conversely, the same approved notice may survive many software releases.

Keep the relationship explicit. If a website experiment changes the prominence or separation of choices, preserve the variant as part of the relevant interaction context. A text-only change log may not explain what the interface actually asked.

Also define who can retire a notice version. Retiring it should prevent new use without making old evidence inaccessible to authorised reviewers. Deletion of obsolete drafts and retention of published evidence require different decisions.

For historic consent, section 5(2) contains a specific transition provision: the fiduciary gives the required notice as soon as reasonably practicable and may continue the processing until withdrawal, subject to the provision and applicable law. Do not declare every earlier consent invalid merely because the organisation creates a new version register. Review the actual history and the applicable commencement context.

Reconstruct one choice before expanding the system

Choose a fabricated event from an earlier test release. Ask a colleague who did not build the feature to reconstruct the purpose, language, displayed wording, customer action and downstream eligibility result.

Use this release checklist:

• Assign a stable identifier to each approved published version.
• Preserve language and purpose relationships.
• Distinguish wording changes from processing changes.
• Link events to the version actually displayed.
• Keep publication and retirement dates reviewable.
• Restrict editing of published evidence.
• Test whether a historical choice can still be explained.

A useful versioning design lets the team answer a plain question: what did this person agree to at that moment? It should preserve that answer even as the product, language and operating systems evolve.