← Back to Legal

Data retention schedule

Last reviewed 20 October 2026 · Next scheduled review 29 July 2027

Controller of record: Mentum. Contact: privacy@mentumjobs.com (data protection), dpo@mentumjobs.com (privacy contact, no Data Protection Officer is designated), security@mentumjobs.com (security reports), support@mentumjobs.com (operational).

Anchors: Privacy Policy, Terms of Service, Data Processing Agreement, Sub-processor list, Acceptable Use Policy, Service Level Agreement, Cookie Policy.

Launch notification list

We delete unconfirmed launch email addresses after 7 days, all entries after 6 months from joining, and entries 30 days after we send the launch email, whichever is sooner. You can remove your address using the link in either email or ask privacy@mentumjobs.com to erase it. Joining the list does not create an account, and we do not use it for other marketing.

This Data Retention Schedule is Mentum's published statement of how long each category of personal data is kept, what event starts the retention clock, and how the data is destroyed at the end of its period. It is the operational counterpart to the Privacy Policy: the Privacy Policy explains what Mentum processes and why. This Schedule sets the how long and how it ends.

1. Purpose and scope

1.1 Purpose

This Schedule discharges Mentum's obligation under UK GDPR Article 13(2)(a) to inform data subjects of “the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period”. It also operationalises Article 5(1)(e) (storage limitation) by binding every personal-data category to a defined retention period, deletion trigger, and destruction mechanism.

1.2 What this document is not

• It is not the Privacy Policy. The Privacy Policy is the canonical disclosure of lawful bases, data categories, recipients, transfers, and data-subject rights. This Schedule presupposes that policy and goes deeper on retention only.
• It is not the Data Processing Agreement. The DPA governs the contractual processor terms between Mentum and its paying customers. This Schedule describes Mentum's controller-side practice.
• It is not Mentum's internal Records of Processing Activities (ROPA). ROPA is the Article 30 record and goes wider (lawful bases, recipients, transfers) and shallower (no per-table cron timing). Where this Schedule and ROPA disagree, this Schedule is authoritative for retention timing and ROPA is corrected at its next review.

1.3 How to read this alongside the Privacy Policy

• The Privacy Policy gives the summary retention statements that a candidate or employer can read in two minutes.
• This Schedule gives the per-table retention statements that a DPO or auditor can verify against the code and migrations.

2. Lawful basis recap

Mentum's processing rests on the following Article 6 bases (see Privacy Policy § 3 for the full mapping):

• Article 6(1)(b), Contract. Account creation, matching, chat, interview booking, employer search of candidate profiles, adviser conversations for candidates who have opted in. This is the lawful basis for the majority of retention rows below.
• Article 6(1)(a), Consent. Marketing communications, AI-feature opt-in, and cookie categories beyond strictly necessary. Consent records themselves carry a statutory retention period (see § 9).
• Article 6(1)(f), Legitimate interests. Security telemetry, application audit logs, abuse prevention. Balancing-test outcomes are recorded in Mentum's internal ROPA.
• Article 6(1)(c), Legal obligation. Consent retention under UK GDPR Article 7(1) and Article 17(3)(e). Breach-register retention under Article 33, PECR record-keeping. See § 9.

3. Two retention concepts you'll see in this document

This Schedule uses two distinct end-of-life mechanisms, and the distinction matters.

3.1 Deletion

The row is physically removed from the database. After the daily retention sweep, a hard DELETE (or a chain of foreign-key-cascading deletes) takes the data out of the live system. The only residual copy is in Supabase's encrypted, time-limited backup window (see § 10). Most rows on this Schedule are deleted at end-of-life.

3.2 Pseudonymisation

The row is preserved, but the identifying columns are nulled or replaced with the literal token [Removed]. The remaining row preserves relationships, employer records and statistics. It can still be linked back to the person. Two specific cases use pseudonymisation rather than deletion:

• The 36-month inactivity sweep on candidate profiles. A candidate who has not logged in for 36 months has their personal identifiers blanked from candidate_profile while structural columns are retained for aggregate analytics.
• Chat messages after a match closes. Closed-match chat content is replaced with a retention notice. The surrounding metadata (sender, timestamp, match reference) is preserved for employer-side recordkeeping.

In both cases the row is still personal data under UK GDPR, because it can still be linked back to the person, so your rights still apply to it. Full removal happens when you delete your account (§ 8).

4. Retention schedule for candidate data

The following table is the authoritative per-category retention schedule for personal data Mentum processes about candidates. Underlying table names are shown in code font after the plain-English category name for auditor cross-reference.

Headline read

• Many records remain until account deletion. The 24-month deactivation and 36-month pseudonymisation sweeps do not erase every child record. For a profile that has never logged in, account creation starts the inactivity clock. There is no general timed deletion of profile-less auth accounts or draft jobs.
• The two pseudonymisation points are deliberate. The 36-month sweep is the inactivity floor. Closed-match chat is the per-match floor. Both are explicit choices rather than incomplete deletion logic.
• The match_details row is the only “preserved-but-anonymised” employer-facing artefact is preserved because deleting it would corrupt the employer's hiring record. The candidate identifier is removed. The row remains as a hiring-decision record under employment law.
• An account that was never completed is removed on an event, not a clock. Choosing “Log in with Google” on the login page without a Mentum account leaves a login record that holds nothing but the email address, has no role and no profile, and cannot be used. Signing up by email with the same address deletes that record before the new account is created. It is not a sweep: a record nobody signs up over is retained until then.

5. Retention schedule for employer and job data

Employer check records

An employer's right-to-work and DBS records become due for deletion 6 months after the hiring process for that job ends, whether or not the job itself is deleted. A passed right-to-work check with an expiry date is kept until 30 days after that date if this is later than the 6-month date. Earlier erasure and parent deletion can remove the records sooner.

If the employer used an online share code, we delete it as soon as they settle the check, and a code that's never settled is deleted after 30 days, measured from the check date or the last update if no check date was recorded. Our nightly clean-up works in batches, so deletion can happen after the due date. Employers keep their own legal evidence of the check outside Mentum.

Headline read

• Employer accounts have no inactivity timer. Unlike candidate accounts, an employer account remains live until the user actively deletes it. This is deliberate: long-running employer relationships are a normal commercial pattern.
• Jobs go through three states with three clocks. Active (90 days posted with no matches), then inactive (6 months for hard delete, measured from the last update to the row and falling back to its creation date where it was never updated), with Adzuna-sourced descriptions further accelerated to a 30-day text NULLification once the parent goes inactive.
• Analytics tables intentionally outlive jobs. 6-to-24-month windows for market and skill analytics support employer dashboards that compare period-over-period. They hold aggregated analytics, not candidate-attributable data.

6. Retention schedule for operational and audit data

These tables matter less to a typical end user but are the artefacts auditors and DPOs ask about during procurement.

Headline read

• Operational logs run on three-band retention. Security and access logs hold the longest (12–24 months). Pipeline logs hold mid-term (6 months) and the raw LLM-cost log short-mid-term (90 days, with a permanent non-attributable daily aggregate). Transactional Redis state holds short-term (minutes to a day).
• Email send-log retention is enforced twice. A standalone 04:20 UTC cron supplements the main 04:15 UTC retention sweep. It is kept as a separate job so the email log's deletion can be checked on its own. Both jobs are idempotent.
• Consent records and the breach register survive account deletion. These are spelled out below.

7. AI-generated artefacts

Mentum applies data-minimisation controls at the boundary with its LLM providers: OpenAI for the standard AI workloads (gpt-6-luna) and for the eight premium response surfaces (gpt-5.6-luna), and Google Gemini for embeddings, skill estimation, reading scanned CV files where that fallback is switched on, and as the standard-route fallback. The data flowing outbound varies by feature:

• CV parsing and CV optimisation are the two paths where name-bearing CV text is sent to an LLM provider, because the name appears in the CV body. Both go to OpenAI. A scanned, image-only PDF is first transcribed by Google Gemini, as uploaded, where that fallback is switched on. On the parsing path National Insurance numbers, dates of birth and postal addresses are stripped before the call. On the optimisation path they are not, because redacting them would corrupt the rewritten CV the candidate asked for. Parsed CV data is persisted to structured fields on candidate_profile.
• Match explanations, skill estimation and culture-fit run on the standard route (OpenAI, except skill estimation, which runs on Google Gemini) and strip the candidate name before fan-out: the provider sees structured profile data without the identifier.
• Enhanced insights, career trajectory, adviser conversations, Career Compass and interview practice run on OpenAI's premium route with the same minimisation (name omitted, high-risk personal data stripped).

AI-generated outputs, including match explanations, insights, adviser transcripts and trajectory caches, are subject to the candidate-side retention rows in § 4. There is no Mentum-side provider persistence beyond those rows. On the Google side, the Google Cloud Data Processing Agreement is in effect for the paid Gemini API Mentum uses (see the sub-processor list). OpenAI doesn't use our API data to train its models, and we haven't opted in to that. We ask OpenAI not to store responses, but it may still keep some data for a limited time under its own terms, so we don't claim it keeps nothing. OpenAI's data processing agreement and transfer terms for our production account will be in place before real candidate data is sent to it. Batch API files for job-description extraction contain listing text, not candidate data, and are deleted when the batch settles, with a 7-day provider-side expiry as the backstop.

8. User-triggered erasure (UK GDPR Art. 17)

A candidate or employer who wishes to exercise the right to erasure (“right to be forgotten”) under UK GDPR Article 17 does so by deleting their account in their app settings, which calls DELETE /api/auth/account.

8.1 What happens synchronously

When the deletion request is accepted (after explicit in-app confirmation), the request handler executes the role-appropriate RPC (delete_candidate_account or delete_employer_account) within the same HTTP request, before the 2xx response is returned. The RPC performs:

• Hard delete of all candidate-owned PII rows, including profile, skills, experience, education, interests, question answers, saved matches, bookmarks, blocked companies, notifications, notification preferences, push subscriptions, accessibility preferences, availability records, and the related child rows.
• Storage-bucket purge removes the CV file and profile photo from object storage.
• Auth account deletion removes the underlying authentication user row, which propagates as a SET NULL or cascade to every other table holding the foreign key.
• FK-cascading behaviour for match-history rows means match_details rows have the candidate identifier set to NULL rather than being deleted, so the employer's hiring record remains structurally intact while the candidate is no longer attributable. Chat messages are scrubbed (content replaced with a deletion notice, with sender and timestamp preserved).

8.2 What does not happen synchronously

• Backup retention. Supabase's point-in-time recovery keeps an encrypted snapshot and a continuous record of changes for 7 days. Deleted rows remain in that recovery window until it expires. There is no separate daily database-backup window while this is on. Mentum has no operational access to the backup contents and does not restore backups except in a documented disaster-recovery scenario (see § 10).
• Statutory carve-outs. Consent records (Art. 7(1) and Art. 17(3)(e)) and breach-register entries (Art. 33) survive account deletion. See § 9.

8.3 Cross-reference

For the procedural detail on exercising any data-subject right (verification, response times, complaint route), see Privacy Policy § 11.

9. Statutory retention carve-outs

Two categories survive account deletion because UK GDPR or PECR requires it.

9.1 Consent records

Retention: 7 years (84 months). Survives account deletion under UK GDPR Article 17(3)(e) (processing necessary for the establishment, exercise or defence of legal claims) read with Article 7(1) (the controller's burden to demonstrate that consent was given). The 7-year window aligns with the UK limitation period for contract and tort claims under the Limitation Act 1980.

Practical effect: even after a candidate or employer deletes their account, Mentum keeps an attenuated record showing which consent was given, at what time, for what purpose, and when it was withdrawn. The record does not include the substantive personal data the user has erased. It is a metadata receipt.

9.2 Breach register

Retention: indefinite. Retained under UK GDPR Article 33(5). The Article 33 record-keeping obligation has no defined expiry, and the supervisory authority (ICO) may request the historical record at any time during an investigation. The breach register contains incident metadata only. It does not store the affected data subjects' personal data beyond pseudonymised counts and category labels.

9.3 Other carve-outs

• Security telemetry retained for legitimate interest (security_events, data_access_log), see § 6. These are not consent-based and are retained for the duration described regardless of any deletion request, on the legitimate-interest basis (Art. 6(1)(f)) of operating a secure platform. The Art. 21 right to object is balanced against Mentum's documented legitimate interest.
• Application audit logs (audit_errors, audit_runs) are retained for the 12-month window described in § 6 on the same legitimate-interest basis.

10. Backup retention

10.1 Backup window

The production database is backed up by Supabase's Point-in-Time Recovery: a daily encrypted snapshot plus a continuous record of changes, kept for 7 days, so the database can be restored to any moment in that window. Uploaded files (CVs, photos and documents) are not included in that backup. A nightly copy of each uploaded file is kept in a separate encrypted storage bucket for 7 days.

10.2 What this means for an Art. 17 request

A data subject who has exercised the right to erasure will see their data removed from the live database within the same HTTP request (see § 8). The data continues to exist within the encrypted backup window for up to 7 calendar days, at which point the natural rotation removes the backup copy. The same 7-day window applies to the nightly file copies: an erased file leaves every backup within 7 calendar days of being deleted from live storage.

Mentum does not perform partial restores or surgical edits to backup contents because the operational shape of the backup system does not support row-level intervention. If a backup is restored as part of a disaster-recovery event, Mentum will re-run the retention process immediately after the restore so that prior erasure requests are re-applied.

10.3 Recovery targets

Mentum's Service Level Agreement states the following recovery targets, which haven't yet been tested with a full restore drill:

• Recovery Point Objective (RPO): ≤ 5 minutes (PITR Write-Ahead Log window).
• Recovery Time Objective (RTO): ≤ 4 hours for the database tier.
• Storage RTO: ≤ 8 hours for a service outage. A deleted or lost file can be restored from the nightly copy, losing at most a day of changes.

11. How retention is enforced

11.1 Automation

All time-based retention in this Schedule is enforced by pg_cron jobs running in the production database. There is no human review step. The relevant jobs:

• retention-cleanup-daily at 04:15 UTC daily runs the master run_retention_cleanup() PL/pgSQL function which executes every cleanup case in §§ 4, 5, and 6 except the standalone jobs listed below. All cases run in one transaction, so an error in any one case undoes that night's whole sweep, and the next night's run repeats it.
• retention-storage-purge-daily at 05:00 UTC daily drains the pending_storage_purge queue (populated by the 04:15 job when it nulls cv_url) and deletes the actual storage bytes. Runs via pg_net → POST /api/internal/cron/run-retention-storage-purge . The 04:15 job enqueues the object paths. This job removes the files, so CV-file destruction is a two-step flow, not a standalone Python sweeper.
• email-send-log-retention-nightly at 04:20 UTC daily is a standalone job for email_send_log deletion, kept as a separate job so the email log's deletion can be checked on its own.
• purge-candidate-abuse-events at 04:37 UTC daily runs a standalone 90-day sweep of candidate_abuse_control_event (§ 6), bounded to 10,000 rows a run. The minute is chosen so it does not contend with the employer-analytics snapshot that runs at 04:35.
• detect-clipped-cron-runs every 30 minutes is an internal health monitor that flags any cron job whose runtime was clipped by Supabase's 120-second platform default. Writes to cron_health_log (90-day retention per § 6) and surfaces in the on-call alerts.
• cleanup-cv-staging at 04:25 UTC daily. Deletes staged CV uploads after 7 days.
• cjms-inactive-job-purge-daily at 04:45 UTC daily. Deletes precomputed fit scores for jobs inactive for at least 7 days, up to 500,000 rows per run.
• expire-pending-candidate-uploads every 15 minutes. Expires unattached uploads past their window and queues their files for deletion.
• purge_settled_hiring_records at 04:52 UTC daily. Enforces the employer-check and interview free-text clocks in sections 4 and 5 in capped batches.
• Hiring-detail clean-up in the 04:15 UTC sweep. Clears eligible offer and signature evidence, equality answers and their private token, and webhook delivery records. The sweep also removes expired equality answers and webhook deliveries.

11.2 Configurability

The scheduled clean-ups can't be changed by configuration. Each period is written into the code and changes only through a reviewed code change. Only the short-lived Redis timers in § 6, the career-trajectory refresh window and the 7-day file-backup window shown here are read from configuration.

11.3 Trigger types

Two trigger types govern retention:

• Date-based. For “Age over 12 months”, the row's created_at or equivalent column is compared against now() - interval '12 months' within the cron-driven RPC. Most rows in §§ 5 and 6 fall here.
• State-based. “Closed match status” or is_active = false means the row's status column drives the clock, not the calendar. Chat-message pseudonymisation and job-deletion paths fall here.

The 24-month and 36-month candidate-profile inactivity clocks start from the last login, or from the date the account was created if the person has never logged in. Active users have no time-based deletion of their profile.

11.4 Monitoring trail

The sweep doesn't yet keep its own record of what it deleted. The scheduler records that each job ran, its status and how long it took, and a check every 30 minutes flags any run cut short by the platform time limit.

12. Changes to this schedule

Mentum updates this Schedule on an annual cadence (the Next scheduled review date at the top of this page) and off-cycle on any material code change to the retention RPCs, pg_cron schedules, or deletion paths.

• Material changes to a retention period, category or deletion trigger are notified to data subjects via the Privacy Policy banner and reflected in the Last reviewed date on this page.
• Editorial changes, such as clarifications, link updates and formatting fixes, do not trigger re-notification. The Last reviewed date is still bumped so the audit trail is unambiguous.

Data subjects or customers who require a historical version of any prior period of this Schedule may write to privacy@mentumjobs.com and we will provide the relevant prior version.

13. Contact and complaints

For questions or complaints about Mentum's retention practice:

• Privacy contact: dpo@mentumjobs.com and privacy@mentumjobs.com
• Security reports: security@mentumjobs.com
• Operational support: support@mentumjobs.com

If you are not satisfied with Mentum's response, you have the right to lodge a complaint with the Information Commissioner's Office (ICO):

• Website: ico.org.uk/make-a-complaint
• Telephone: 0303 123 1113
• Postal: Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF

You may also lodge a complaint with the data-protection supervisory authority of your habitual residence or place of work within the UK or EEA.

Related: Privacy Policy | Terms of Service | Data Processing Agreement | Sub-processors | Service Level Agreement | Cookie Policy