PIPEDA Candidate Data Retention: A Practical Guide

PIPEDA candidate data retention is purpose-based: a covered organization keeps personal information only as long as the purposes identified at collection require it. No universal Canadian rule says every resume must be deleted after 30 days, one year, or two years. Your schedule must account for the employer’s jurisdiction, each record’s purpose, candidate access, and any legal preservation duty.

This guide provides an operating framework, not legal advice. The applicable Canadian privacy rules depend on the organization, province, role, data flow, and record type. Confirm your schedule with Canadian privacy and employment counsel.

What does PIPEDA require for candidate data retention?

PIPEDA requires covered organizations to define why they collect candidate information, restrict its use to that purpose, and retain it only as long as the purpose requires. When the information is no longer needed, it should be securely destroyed, erased, or made anonymous.

The Office of the Privacy Commissioner of Canada (OPC) turns that principle into five practical duties in its guidance on limiting use, disclosure, and retention:

1. Document the purpose for each collection and any later new purpose.
2. Set minimum and maximum retention periods.
3. Keep decision records long enough for the individual to exercise access rights.
4. Review holdings so information does not survive past the schedule.
5. Destroy or anonymize information with safeguards appropriate to its sensitivity.

Retention follows a lifecycle, not a single number. A resume under active review serves a current hiring purpose. The same resume in a speculative talent pool serves a future-matching purpose. Interview notes may need a short post-decision window for access or a complaint. Bundling all three records into one indefinite “candidate profile” obscures those differences.

Does PIPEDA apply to every Canadian employer?

No. PIPEDA’s employment rules apply directly to federal works, undertakings, and businesses, while provincial private-sector laws may govern other employers. The first retention question is not “How many months?” but “Which law governs this organization and this record?”

The OPC’s guide to PIPEDA and employee records lists federally regulated sectors such as banking, telecommunications, broadcasting, aviation, and interprovincial transportation. Amendments made through the Digital Privacy Act extended those federal employment provisions to applicants as well as employees.

The OPC’s PIPEDA requirements summary and its federal-provincial Q&A explain this patchwork. Putting “PIPEDA compliant” at the top of a national policy does not resolve it.

A useful jurisdiction record identifies the employing entity, sector, candidate’s work location, employer’s province, storage locations, processors, and cross-border flows. Counsel can then map the rules to those facts instead of inferring them from the candidate’s postal address.

What counts as candidate personal information?

Candidate personal information includes both facts supplied by the applicant and opinions or inferences created during hiring. A retention job that deletes only the uploaded resume can leave most of the sensitive record behind.

The OPC says personal information includes factual or subjective information about an identifiable person. In a hiring system, that can include:

• name, contact details, location, and identifiers;
• resume, work history, education, and portfolio links;
• compensation expectations and availability;
• interview recordings, transcripts, and scheduling metadata;
• interviewer notes, ratings, votes, and recommendations;
• code assignments and reviewer comments;
• reference responses and background-check results;
• emails, rejection reasons, accommodation information, and complaints;
• inferred skills, rankings, risk flags, or AI-generated summaries.

Some fields are more sensitive than others, but the fact that a recruiter created one rather than a candidate submitting it does not make it harmless. The OPC’s workplace privacy guidance recommends collecting only what is necessary for a stated purpose and explaining its use. It even suggests letting interview candidates blur video backgrounds to avoid incidental collection.

Start with a data inventory that traces the record across your careers page, applicant tracking system (ATS), email, calendar, video platform, assessment tool, shared documents, exports, backups, and analytics. A policy limited to the ATS row misses much of the hiring record.

Does PIPEDA set a fixed candidate-retention period?

PIPEDA does not prescribe one fixed period for all candidate records. It requires a reasoned minimum and maximum tied to purpose, access rights, legal requirements, and secure disposal.

The OPC’s PIPEDA self-assessment tool tells organizations to set minimum and maximum periods. It also says to keep information used in a decision long enough for the individual to access it afterward. This prevents two opposite mistakes:

• Keeping everything indefinitely: “We may hire this person someday” is not a useful maximum.
• Deleting immediately after rejection: the candidate may still have an access right, while the organization may have a complaint, investigation, limitation-period, or other preservation duty.

PIPEDA also creates a specific hold when information is already subject to an access request. Subsection 8(8) requires the organization to preserve that information as long as the person needs to exhaust recourse under the Act. A deletion job needs a hold mechanism, not merely a timer.

The final period is a documented legal and operational judgment. It should explain why the organization needs a record, which event starts the clock, what pauses deletion, and what happens at expiry. Copying another company’s “24 months” without that reasoning gives you a number, not a defensible schedule.

How should you separate candidate record types?

Separate records by purpose and lifecycle event before assigning any period. The schedule below deliberately uses triggers and decision criteria rather than invented Canadian deadlines.

The 24-month breach rule is narrow. Section 6 of the Breach of Security Safeguards Regulations requires a record of every breach for 24 months after the organization determines it occurred. It does not require keeping the underlying resume, interview recording, or entire candidate profile for 24 months. Design the breach record to show what happened without creating a second archive of personal information.

How do you build a defensible retention schedule?

A defensible candidate-retention schedule connects each data class to a purpose, owner, trigger, period, hold rule, and verified disposal action. It must work across systems, not sit in a policy that nobody can execute.

1. Map jurisdiction before choosing a period

Record the employing entity, industry, province, work location, public or private status, and cross-border flows. Flag employers in Alberta, British Columbia, and Quebec, plus federally regulated employers, for their specific regimes. Include employment, human-rights, litigation, tax, and sector requirements in the same analysis.

2. Inventory the full candidate record

List every system and field used before, during, and after a hiring decision. Include copies in email, calendar events, assessment tools, video services, exports, data warehouses, support tickets, and backups. Name an owner for each copy.

3. Write one purpose per record class

“Recruiting” is too broad. Separate current-role assessment, future-role matching, accommodation handling, fraud prevention, decision evidence, and security-incident evidence. Each purpose governs both use and retention.

4. Define the clock and the holds

Use a machine-readable event such as rejected_at, withdrawn_at, hired_at, consent expiry, or case closure. Name the events that pause disposal: an access request, complaint, investigation, preservation notice, or other legal hold. Give one person authority to release each hold.

5. Set minimum and maximum periods

The minimum must preserve legitimate access and legal needs. The maximum keeps “just in case” retention from becoming permanent. Record the counsel-approved reason beside the number, then review it when the law, purpose, or system changes.

6. Specify deletion and anonymization precisely

Specify what gets purged, overwritten, detached, aggregated, or retained. Cover attachments, extracted resume data, free-text notes, search indexes, caches, replicas, and processor backups. State whether deletion is immediate or proceeds through a documented backup cycle.

7. Test and prove the schedule

Run a sample candidate record through expiry. Check the primary record, attachments, search results, exports, integrations, and restore procedures. Keep proof of the test without reconstructing the candidate profile you meant to remove.

Review the schedule whenever you add a processor, collect a new field, introduce AI analysis, enter a province, or change the hiring purpose. A static policy cannot govern an evolving data map.

Can you keep rejected candidates for future roles?

You can maintain a talent pool only when future matching is a clear, lawful purpose with its own retention controls. Do not quietly turn a rejected application for one role into indefinite sourcing data for every later role.

PIPEDA requires purposes to be identified at or before collection. In PIPEDA Finding 2012-003, the OPC found that a job seeker was not adequately told why personal information was being collected. The lesson is direct: a vague privacy policy cannot repair an undisclosed purpose after collection.

A clear talent-pool notice tells the candidate:

• what future matching involves;
• what information will be kept and used;
• the retention or renewal period;
• whether recruiters, processors, or AI-assisted tools can access it;
• how to withdraw or request access;
• what deletion or anonymization does at expiry;
• where to contact the accountable privacy person.

A checkbox alone is insufficient. For federally regulated employment relationships, PIPEDA identifies circumstances where consent is not required for information needed to establish, manage, or terminate the relationship, though advance notice remains important. Provincial rules differ. The goal is a purpose the candidate can understand and a basis counsel can defend.

What must your ATS vendor do?

An ATS can execute your retention schedule, but outsourcing does not transfer the employer’s accountability. The employer must understand where the data goes, then use contracts and oversight to protect it appropriately.

PIPEDA’s accountability principle says an organization remains responsible for information transferred to a third party for processing. The OPC’s 2020 finding on outsourced processing adds that cross-border processing is not prohibited, but the organization should be transparent, assess risk, and use contractual and monitoring controls.

Ask your ATS vendor for specific answers:

• Can retention periods differ for applications, talent-pool entries, and hires?
• Which lifecycle event starts each clock?
• Can an access request or legal hold pause deletion for selected records?
• What happens to resumes, notes, emails, extracted fields, and audit events?
• How are subprocessors, search indexes, replicas, and backups handled?
• Can you export and correct a person’s complete record?
• Can the vendor prove deletion or explain the backup ageing period?
• What happens to all data when the contract ends?

Your contract should limit processing to documented purposes, require appropriate safeguards, cover incidents and subprocessors, and make data return or deletion testable. A security page that says only “encrypted” leaves the retention questions unanswered.

Recruitment files are unusually rich. The Mercor candidate-data breach showed how resumes, identity documents, and interview media can make an ATS a high-value security target. The smallest defensible dataset is easier to secure than an archive nobody remembers owning.

Is deleting identifiers enough to anonymize candidate data?

No. Removing a name or email address does not by itself make a candidate record anonymous. Work history, location, portfolio links, rare skills, interview text, and other datasets may still identify the person.

In PIPEDA Finding 2026-001, the OPC said an organization relying on anonymization must be able to show there is no serious possibility of reidentification, alone or in combination with other available information. The assessment is ongoing because reidentification techniques and available datasets change.

For each expired candidate record, choose deliberately:

• Delete: remove the record and associated content when no continuing purpose exists.
• Anonymize: irreversibly transform the data and document the reidentification analysis.
• Aggregate: keep only statistics that no longer relate to an identifiable person.
• Hold: preserve only the records within a documented legal or access hold.

Pseudonymization is not anonymization. Replacing a name with an internal identifier while keeping the lookup key leaves the record personal. A free-text interview note can still identify someone after the structured fields disappear.

How does Kit support candidate retention?

Kit provides configurable retention, separate application and talent-pool notices, consent evidence, renewal, and automated anonymization. You still decide which law applies, choose the period, manage holds, and validate the resulting policy with counsel.

Kit’s candidate privacy and consent guide explains the current controls:

• a configurable retention period from 1 to 60 months, with a 24-month default;
• editable application disclosure and talent-pool consent text;
• the timestamp, exact text shown, and encrypted IP address recorded at submission;
• talent-pool renewal 30 days before expiry and a reminder 7 days before expiry;
• automatic anonymization after the expiry grace period when consent is not renewed;
• retention-based anonymization for rejected or withdrawn applications, with hired applications excluded from that automatic process.

Those controls turn a written schedule into events the system can execute. They do not select a Canadian jurisdiction, create a legal hold, guarantee that every processor copy has disappeared, or prove that a particular transformation meets the OPC’s reidentification test. Configure the product as one part of your wider program.

Start by separating current applications from future-role matching. Add a clear privacy notice, a counsel-approved retention period, an accountable owner, and a tested disposal path. Review the schedule whenever the purpose, province, processor, or data changes. If you want those controls attached directly to the hiring workflow, you can start a free trial and configure candidate privacy before the next role goes live.