Candidate data and privacy
Defines which candidate data to collect, who may access it and how long to keep it. Supports controlled exports and deletion while leaving hiring decisions to people.
recruitment-data-lifecycle
See how it helpsWhen is it useful?
Use this skill when recruitment features collect, share, retain or remove applicant information. It turns your organization’s approved data policy into concrete behavior across records, attachments, exports and connected systems.
What does it help you do?
- Maps which applicant data is needed, who may access it and where copies or derived records exist.
- Models retention rules and holds separately for active applications, closed applications and talent pools.
- Prepares reviewable export or deletion plans and tracks incomplete downstream actions; destructive deletion requires explicit approval.
Try asking this
Map how our ATS stores CVs, interview notes and exports. Apply our approved retention rules and prepare a deletion preview that respects active applications and legal holds.
Detailed documentation
Read the skill’s original instructions, examples and checks in their authored language.
Show less
Recruitment data lifecycle
When to use
When a recruitment feature collects, shares, exports, archives or removes applicant information. Translate the organization's approved privacy and retention policy into concrete data behavior; do not invent legal grounds or retention deadlines.
Workflow
- Inspect the installed ATS/connector versions, schema, storage and real data paths. Inventory candidate identity/contact data, CVs and attachments, applications, interview notes, scorecards, offers, communication metadata and integration payloads. Include derived search indexes, caches, exports, analytics, backups and downstream processors. Record the owner, purpose and access boundary for each category using minimized samples.
- Collect only fields necessary for the stated recruitment purpose. Keep voluntary demographic or accommodation information separate from general recruiter records and restrict it to the authorized purpose. Do not infer sensitive attributes from names, photos, CV language or other proxies. Do not introduce automated sensitive-attribute ranking or rejection; hiring judgments remain with authorized humans using approved job-related criteria.
- Resolve the approved retention rules with the responsible policy/legal owner: triggering event, duration, scope, exceptions, applicant notice and applicable hold. Distinguish an active application, a closed application and a separately authorized talent-pool record. A candidate with two applications may have different retention obligations for each; closing one application must not automatically erase or extend the other.
- Make retention enforceable across primary and derived records. Track the relevant policy version and cutoff, but do not log unnecessary personal data in the audit record. Legal holds must block the affected purge and record an authorized owner and release process. Restricted data must not remain available through an export link, search index or attachment URL after access is revoked.
- For export, verify requester identity, organizational scope and the authorized subject/record set. Resolve shared records and third-party information before including interviewer notes or other people's data. Produce a reviewable manifest, use an appropriately protected delivery channel and apply an expiry/access policy. An administrative export capability is not permission to send the dataset to an arbitrary recipient.
- For deletion, first produce a dry-run manifest of the environment, exact target records, dependent artifacts, downstream recipients, holds and recovery limits. Obtain explicit human approval naming the environment, target and purpose before destructive deletion, including local task copies or test databases. Apply the authorized operation in bounded batches with per-target results; reconcile downstream processing and preserve only the minimum audit evidence allowed by policy.
- Report what actually happened: hidden from the interface, access revoked, primary data deleted, derivative copies removed, downstream deletion pending, or backup expiry scheduled. Inspect actual backup/versioning behavior and document how deleted data stays excluded after a restore. Do not claim complete erasure while retained copies or unknown downstream outcomes remain.
Evidence and verification
Deliver the purpose/access inventory, policy ownership gaps, retention/hold matrix and an export or deletion plan with affected counts. Use synthetic fixtures to test cross-organization denial, a candidate with multiple applications, an active legal hold, a partial downstream failure, a stale download link and a derived index that would otherwise retain personal data.
Verify the authorization and preview without running destructive operations unless the required approval exists. Record exact checks and unresolved obligations. Replaying a retention job must not repeatedly disclose data, remove held records or recreate an expired export.
Boundaries
- This skill implements approved policy; it does not provide legal approval or choose a jurisdiction's lawful basis, disclosure duty or retention period. Escalate a concrete unresolved policy question to its responsible owner.
- Do not use production CVs or interview notes as model evaluation fixtures, training material or unrestricted support logs.
- A code rollback cannot restore deleted applicant data. State recovery limits before the authorized mutation and preserve held evidence without broadening access.
Primary reference
Verify the connected provider's actual object/API coverage and deletion/export behavior; API availability alone does not establish legal permission:
Included files 1
SKILL.md