A useful consent event log records decisions without copying the payload

A consent event should help answer what a person chose, for which purpose and under which wording. It rarely needs to contain the entire customer message, the full account profile or a copy of an identity document.

The event log and the evidence it references have related but different jobs. The log records a decision and its progression. Controlled evidence stores preserve the material needed to interpret that decision. Designing them separately can improve both privacy and reviewability.

Begin with the question the record must answer

For a hypothetical retailer, a useful question might be: “Was promotional messaging enabled for this customer under the notice shown at the counter, and was the later withdrawal applied?”

The answer needs a chain of events. It does not require every item the customer purchased or every conversation with the cashier.

The DPDP Act’s section 6(10) will place the burden of proving notice and consent on the Data Fiduciary where consent is the basis in a proceeding. As of 22 October 2026, the relevant core provisions are scheduled to commence on 13 May 2027 under the commencement notification. The event design here is a readiness proposal, not a statement that the duty is already operative.

Give each field a reason to exist

A candidate event can record an event identifier, a protected subject reference, the purpose identifier, the choice, the notice version, the capture channel and the relevant time. It can also record the authenticated system or operator responsible for capture where that is needed for accountability.

Each field should answer a review question. A purpose identifier should resolve to a specific purpose description. A notice version should resolve to the wording actually used. A channel value should distinguish a counter interaction from an online form if that affects interpretation.

Avoid copying the full notice into every event if a controlled, immutable version record can provide the same evidence. However, retaining only a version label without preserving its content leaves an evidentiary gap.

A content hash can help check whether an artefact has changed. By itself, it cannot reconstruct a missing notice or establish that a particular customer saw it.

Model changes as events

Treat a withdrawal, a correction and an integration acknowledgement as different events with clear relationships. Overwriting a single “consent = yes” field loses the sequence that explains the current state.

For the retailer, the sequence could be a captured choice, acceptance by the central service, a later withdrawal and acknowledgements from messaging systems. The final permission used for sending should follow a defined state rule, not whichever event arrived last at a downstream system.

If an operator corrects a capture error, preserve what changed and why. Avoid silently rewriting history to make the current state appear consistent.

The event log should also distinguish an attempted action from a completed one. “Withdrawal requested” and “withdrawal applied to the sending system” are materially different facts.

Keep payloads out of the convenience fields

Free-text notes are a common route for unnecessary personal data. An operator may paste a customer’s message into a field intended for a short explanation. A debugging layer may attach the entire request body to an otherwise minimal event.

OpenTelemetry’s sensitive-data guidance recommends limiting sensitive telemetry and describes removal or transformation controls. Apply the same minimisation reasoning to event ingestion, error handling and exports.

Use structured reasons where they are sufficient. If a case needs supporting correspondence, store it in the restricted case system and reference it from the event. Access to an operational event view need not automatically grant access to the underlying correspondence.

Test the record with a real review task

Give a reviewer a synthetic customer journey containing a choice, a withdrawal, a delayed acknowledgement and a corrected error. Ask them to reconstruct the state at a specified point in time.

The review should reveal whether the record is sufficient and whether it exposes unnecessary material. Use these checks:

• Every identifier resolves within the reviewer’s authorised scope.
• Notice and purpose versions remain available and interpretable.
• Requested, accepted and applied states are distinguishable.
• Corrections preserve a visible history.
• Logs, exports and error paths avoid duplicating source payloads.
• Retention follows a documented purpose and applicable requirements, rather than an assumed universal period.

A useful event log preserves the decisions needed for accountability. Its quality comes from precise relationships and reliable state, not from collecting the largest possible bundle of customer data.