# Consent records and data governance

Intervieux logs every candidate consent grant or revocation as a new append-only row rather than an edit, building an EEOC-style record-keeping trail, backed by a documented retention policy and a real account-deletion path that removes that consent history along with everything else when a candidate asks to delete their account.

A consent record that can be quietly edited or overwritten isn't a record, it's a snapshot of whatever it currently says. Keeping every grant and revocation as its own row means the full history of what a candidate consented to, and when, stays intact even after their preference changes.

## What it does

Every time a candidate grants or revokes a consent, AI-analysis consent, talent-pool visibility, or an acknowledgement of the retention policy among them, a new row is written to the consent_records table. Nothing already written is ever updated in place. Each row captures what kind of consent it was, whether it was granted, where it came from, which job application it was tied to if any, the user agent, and when it happened. An admin can pull a candidate's full consent history through a dedicated export endpoint. This is documented explicitly as the EEOC-style baseline for record-keeping, evidence of what a candidate actually agreed to, preserved rather than overwritten.

## How it works

1. **A consent action happens** — A candidate grants or revokes a consent, whether that's opt-in for AI analysis, opt-in for talent-pool discoverability, or acknowledging the retention policy.
2. **A new row is appended, never an edit** — That action is written as a brand new row in consent_records, with the kind of consent, whether it was granted, the source, the related job application if any, the user agent, and a timestamp. The previous row, if one exists for that candidate, is left untouched.
3. **The full history stays queryable** — Because nothing is overwritten, pulling a candidate's consent history returns every grant and revocation in order, not just their current state.
4. **Admins can export a candidate's record** — A dedicated admin export endpoint returns a candidate's consent history by user ID, for compliance review or in response to a specific question about what a candidate consented to.
5. **Deletion removes it along with everything else** — If a candidate deletes their account, consent_records for that user is one of the tables removed as part of that synchronous deletion process, rather than being retained independently of the rest of their data.

## Append-only means the history can't be rewritten

A record system built on updates can lose its own history the moment someone edits a row. Consent records never update in place, every change is its own new row, so the sequence of what a candidate consented to and when is preserved exactly as it happened.

## Retention is documented, and its gaps are named openly

The current retention policy keeps most candidate data, including interview transcripts and consent history, for as long as the account exists. A time-based auto-purge on a fixed schedule is explicitly called out as not yet built, a documented follow-up rather than an unstated gap.

## Deletion is real and covers consent records specifically

Account deletion runs through a defined, ordered sequence of table deletions ending in removing the Supabase Auth user itself. Consent records are included in that sequence by user ID, they are not treated as a permanent record that survives a candidate's own request to delete their account.

## Employer-side notes are a known, separate case

Recruiter notes and ratings an employer writes about a candidate live in employer-owned tables and are not removed by that candidate deleting their account, since they're the employer's own record of a hiring decision. This is documented as a known limitation to revisit if policy requires a different answer.

## Who this is for

This is for an employer that needs a defensible, EEOC-style record of what a candidate actually consented to and when, and for anyone evaluating Intervieux on data governance who wants a documented retention policy and a real deletion path rather than a vague privacy statement.

## Frequently asked questions

### Can a consent record be edited after it's created?

No. Consent records are append-only, every grant or revocation writes a new row rather than editing an existing one, so the full history of a candidate's consent choices stays intact.

### What does an EEOC-style audit trail mean here?

It means the system keeps a durable, unedited record of consent actions, what was granted or revoked, the source, and when, in a form that can hold up as evidence of what a candidate actually agreed to, rather than a mutable current-state field.

### What happens to consent records if a candidate deletes their account?

They're deleted along with the rest of the account's data. Consent history is not retained independently once a candidate requests account deletion; it's included in the same deletion sequence as their profile, applications, and interview data.

### Is there a retention time limit on candidate data?

Not yet on a fixed schedule. Current v1 retention keeps most candidate data for as long as the account exists, and a time-based auto-expiry policy is documented as an explicit follow-up rather than something already built.

## Related pages

- [Full candidate event timelines](/features/candidate-timeline)
- [Semantic talent search](/features/talent-search)
- [The ATS REST API](/features/ats-api)
- [Frequently asked questions](/faq)

## Keep a real consent record, not a current-state field

Every grant and revocation is preserved as its own row, backed by a documented retention policy and a real deletion path.

Start practicing free: https://www.intervieux.ai/register · Hire with Intervieux: https://www.intervieux.ai/employers/signup