Consent records are immutable (append-only)

GDPR Article 5(2) requires you to demonstrate accountability for all processing decisions — an audit trail you can retroactively rewrite is not an audit trail. Article 7(1) requires you to demonstrate that consent was given; if the row showing consent was later updated, you have no proof of the original grant. CWE-472 (External Control of Assumed-Immutable Web Parameter) captures the class of vulnerability where data assumed to be authoritative can be silently altered. A consent record that can be UPDATEd can be altered after the fact — by a rogue employee, a compromised service account, or a migration that inadvertently clears historical grants — leaving you unable to prove lawful basis for past sends.

Audit all write paths to the consent table and replace every UPDATE or upsert with an INSERT. Then enforce the constraint at the database level so no future code can accidentally violate it:

-- Option 1: PostgreSQL RULE blocks UPDATE and DELETE at the SQL layer
CREATE RULE consent_no_update AS ON UPDATE TO consent_records DO INSTEAD NOTHING;
CREATE RULE consent_no_delete AS ON DELETE TO consent_records DO INSTEAD NOTHING;

In application code, a consent revocation always inserts a new row with granted = false — it never touches the existing grant row:

// Correct — append a revocation record
await db.consentRecord.create({
  data: {
    contactId: contact.id,
    scope: 'marketing',
    granted: false,
    source: 'unsubscribe-link',
    policyVersion: CURRENT_POLICY_VERSION,
    createdAt: new Date()
  }
})

Search src/ for any db.consent*.update or UPDATE consent_records and replace them before deploying the database constraint.