Skip to content
TruPriv
Module 01

Consent Management

The full consent lifecycle across web, app and API touchpoints, specified clause by clause against the Act and the Rules before a line of code was written. This module also runs standalone, and its onboarding data carries into every module you add later.

The lifecycle

Six stages, each one evidenced.

  1. 01

    Capture

    Sec 5(1), Sec 6(1)

    Granular, purpose-specific, affirmative consent across web, app and API touchpoints. Default-deny: nothing is pre-ticked and no purpose is bundled into another. Notice is served in English plus Eighth Schedule languages, and the version and language actually shown are written onto the artefact.

  2. 02

    Validation

    Sec 6(10)

    A pre-processing gate. Before any processing act, the Data Fiduciary queries the API: does consent exist, is it active, has it not expired, and does the requested use fall inside the consented purpose? All four must pass. It fails closed: an error or a timeout is a refusal, not an approval.

  3. 03

    Update

    Sec 6(1)

    A Data Principal can modify individual purposes without disturbing the others. Each change writes a new artefact version; the prior version is retained and remains retrievable, because the question you will be asked is what the consent was on a given date.

  4. 04

    Renewal

    Scheduler-driven reminders ahead of expiry, with re-affirmation as simple as the original grant. A renewal that is harder than the first consent produces attrition that looks like withdrawal and is not.

  5. 05

    Withdrawal

    Sec 6(4), Sec 6(6)

    As easy as giving. Processing halts in real time, every downstream processor is instructed to cease, and each must acknowledge that it did. The acknowledgements are part of the record, because instructing a processor is not the same as proving it stopped.

  6. 06

    Expiry

    Consent lapses automatically at the end of its validity period and processing halts. No silent extension, no grace period that nobody agreed to.

The consent artefact

The object you produce when someone asks you to prove it.

Stored immutably and versioned. Prior versions are never overwritten, because the question is rarely what the consent is now. It is what the consent was on the day the processing happened.

Every write, and every read of a validation decision, appends to a tamper-evident audit log with cryptographic hashing.

user_id
the Data Principal the consent belongs to
purpose_ids
the specific purposes granted, individually addressable
timestamp
when the affirmative action occurred
session
the session in which it occurred
capture_method
web form, app screen, API, preference centre
notice_version
the exact notice text version that was displayed
notice_language
the language it was displayed in
signature
hash of the record, chained to the entry before it
Also inside Module 1

Consent is the spine. The rest of the obligation sits around it.

Sec 11–14

Data Principal rights, end to end

Access, correction, erasure and nomination through a self-serve portal. Every request is logged, assigned to an owner, tracked against the statutory response window, and closed with an exportable record of what was done and when.

Sec 13, Sec 14

Grievance redressal

Grievances route to a named Grievance Redressal Officer with acknowledgement and response timers running from receipt. A Data Principal must exhaust this before approaching the Board, which makes it the mechanism that decides whether you ever meet the Board at all.

Sec 5

Policy engine

Pushes the correct privacy policy, consent notice and retention policy to each touchpoint and each purpose, and forces re-consent where a change requires it. One place to change a notice, every surface updated, with a version history behind it.