ICIMS data privacy setup comes down to three settings, one candidate-facing page, and one folder. The settings decide whether candidates see a privacy notice and whether you capture their consent. The page (Data Subject Requests) gives candidates a way to exercise their rights. The folder (Restrict Processing) is where expired or withdrawn profiles wait until you purge them.
Get those three pieces right and the rest is messaging. This guide walks through the decisions, the exact setting names, and the parts that need a case with ICIMS Technical Support. It is the guide we wish every TA team had before their first GDPR or CCPA conversation with legal.
One note before we start: nothing here is legal advice. ICIMS gives you the tooling. Your legal team decides how you use it. We help you translate their answers into configuration.
What are the three pieces of ICIMS data privacy?
Picture the whole feature as a front door, a mailbox, and a holding room.
Three settings under Applicant Tracking > General control whether candidates see your notice and whether they must accept it before continuing.
A page on the candidate dashboard where candidates can request access, correction, portability, restriction, deletion, or revoke consent.
Profiles whose consent expired or who asked to be deleted move to a Restrict Processing folder, then get purged manually or on a schedule.
Everything else in this guide is about connecting those three pieces so a candidate’s request, or the passing of time, flows cleanly from the front door to the holding room without a recruiter having to remember anything.
Which four decisions should you make with legal first?
ICIMS documentation frames the setup around four questions, and we have found they are exactly the right four. Bring them to your legal or privacy resource before opening System Configuration. Every answer maps directly to a setting.
Write the four answers down. They become the first page of your privacy configuration document, which matters more than you might think. When your admin moves on, the next person needs to know why the settings are the way they are, not just what they are. Our ICIMS admin transition playbook covers that documentation habit in detail.
What are the three ICIMS privacy configuration scenarios?
Your answers to questions one through three land you in one of three supported scenarios. Each is a combination of the same three settings under Admin > System Configuration > Applicant Tracking > General.
Our opinion, for what it’s worth: if you hire in more than one region, Scenario Two is usually the simplest to run. One notice, one checkbox, one consent audit log. Scenario Three works, but it hinges on candidates self-identifying accurately, and it forces a choice if you want to show the notice to everyone but only capture consent from some (ICIMS suggests separate career sites for that). If you run several portals already, our ICIMS career portals setup guide explains how per-portal configuration works.
Mini-recap: pick the scenario, then everything below is filling in text boxes in the right order.
How do you configure ICIMS data privacy step by step?
Here is the sequence we follow on every ICIMS data privacy setup. The order matters because the privacy notice should never go live before its messaging is ready.
What is the difference between time-based and job-based consent in ICIMS?
The base feature captures a yes or no. Time-based and job-based consent adds a second question: how long, and for what? It is an optional layer that ICIMS Technical Support enables on request, and it is where retention becomes automatic.
Candidate agrees you may use their data for a set duration.
Duration calculated from last login (6 months, or 1, 2, 3, or 4 years) or by manual extension.
Optional warning email 30 days before expiry, inviting the candidate to log in and extend.
Best for talent pools and CRM-style nurturing.
Candidate agrees you may use their data only for the job they applied to, while it is active.
Recruiters cannot submit them to other jobs themselves.
“Active” is defined by the job folders you name when the feature is enabled.
Optional warning email when the job moves to an inactive folder.
Candidates pick one of the two from a dropdown, field rcf3335 (Which consent type are you agreeing to?), which appears under your consent message on the Ask Email page for new candidates and at first login for existing ones. They see the question once and can change their answer later on the Data Subject Requests page.
A few details that trip teams up:
Evergreen jobs. If you keep a long-running evergreen requisition and transfer candidates into real openings, job-based consent can be configured so the Transfer Candidate Activity option still works. You must say so in the job-based consent acknowledgment text so candidates know their application may be considered elsewhere.
Candidates who never came through the front door. Manually added or integration-sourced candidates can be prompted by email to provide time-based consent. If they don’t respond within 30 days, their data is purged. Their email address and country of residence must be on the profile for the prompt to fire.
Legacy CRM. Job-based consent is not compatible with ICIMS Connect (Legacy CRM). Most teams ask Support to enable Default to Time Based Consent on Connect Portal so every CRM entrant is treated as time-based.
One-way door. Once candidates have started selecting consent types, the feature only works as designed if it stays enabled. Decide carefully, then commit.
To turn it on, submit a case to ICIMS Technical Support with your per-portal choices: automatic or manual time-based duration, whether to send expiry warning emails and their text, the list of active job folders, and (if you want automated purge) a retention period in days per country. After enablement, you add your own brief wording to each option in rcf3335 under Admin > System Configuration > System > Person > Platform > Contact, then unhide the field.
Not sure which scenario fits your hiring footprint?
We configure ICIMS privacy settings alongside ICIMS Professional Services, translating what legal decided into settings, messaging, and a retention schedule your team can run.
Book a Free ICIMS Strategy Call →How do Restrict Processing, retention, and purge work in ICIMS?
This is the part most guides skip, and the part that makes ICIMS data privacy setup actually deliver retention rather than just display a notice.
When time-based and job-based consent is enabled, ICIMS automatically moves a profile to a designated Restrict Processing folder in three situations: time-based consent expires, a job-based candidate’s job has been inactive for 30 days, or the candidate submits a Request Deletion on the Data Subject Requests page.
Landing in that folder does not delete anything. It marks the profile. Deletion is a purge, and purge is deliberate.
Manual purge. A user admin with purge permissions goes to Admin > Tools > Purge Archives. Three feature-specific options appear: Person Restrict Processing Time Based, Person Restrict Processing Job Based, and Person Restrict Processing Portal (for deletion requests). Purges run during low-usage hours and cannot be scheduled for a specific window. Purging is irreversible.
Automated purge. Give ICIMS Technical Support a retention period in days per country. Profiles in the Restrict Processing folder are then scheduled to purge once they match their country’s retention period. The country comes from the Regulatory Country field, falling back to Address Country if blank. Countries with no retention period configured are never auto-purged, so those profiles need manual attention.
Search locks. By default, users can still see candidates sitting in Restrict Processing. Ask Support to add search locks so login groups that shouldn’t touch restricted profiles can’t find them. That protects the “restrict” in Restrict Processing.
Excluding employees. You can name Person folders whose current or former members are excluded from automatic placement in Restrict Processing. Most teams use this to keep hired employees out of the purge pipeline. The trade-off: those profiles must then be managed manually.
Privacy notice enabled, nothing configured behind it
Deletion requests sit unnoticed in a report nobody owns
Retention policy lives in a PDF, not in the system
Restricted profiles still show up in recruiter searches
Consent type captured once, changeable by the candidate
Expired and withdrawn profiles auto-route to Restrict Processing
Per-country retention periods drive scheduled purges
Search locks keep restricted profiles out of daily sourcing
One more retention-related thought: if you are moving onto ICIMS from another ATS, decide what legacy candidate data you bring across before the migration, not after. Our Greenhouse to ICIMS migration guide walks through that data decision phase.
How do you run Data Subject Requests day to day?
Here is the important thing to understand about the Data Subject Requests page: with the base feature, submitting a request registers it in the Personal Data Request reporting tool and that is all. No automated action happens for access, correction, or portability requests. A person has to pick them up.
So the configuration is only half the setup. The other half is a lightweight operating rhythm:
Name an owner. Usually the ICIMS system admin or a TA Ops lead. Their job is to check the Personal Data Request report on a fixed cadence (weekly is common) and respond within whatever window legal set.
Document the playbook per request type. Access means export the profile. Correction means edit and confirm. Portability means export in a usable format. Restrict processing means move to the folder. Deletion means move to Restrict Processing and confirm the purge schedule. Write it once, in plain steps.
Use the audit log. The Data Privacy Consent Audit Log Message setting adds a note to the consent audit log whenever a candidate revokes and then re-provides consent. It is invisible to candidates and very handy during an audit.
Review the configuration each hiring cycle. Messaging drifts, portals get added, folders get renamed. A short privacy check belongs inside any ICIMS system audit, and it is one of the items we always include.
What are the most common ICIMS data privacy setup mistakes?
1. Enabling the notice before the messaging is written. Candidates then see default or blank text. Configure first, enable last.
2. Mismatched capture types for new and existing candidates. ICIMS supports it and warns against it. The candidate experience gets confusing fast.
3. Assuming the notice covers onboarding. It doesn’t. If new hires enter through a non-ICIMS path, build a separate process.
4. Treating Restrict Processing as deletion. It is a waiting room. Without a purge schedule or a manual purge, nothing leaves.
5. Forgetting search locks. Restricted profiles remain visible to everyone until locks are added. Ask for them in the same Support case.
None of these are hard to fix. They are simply easy to miss when privacy gets configured in a hurry between requisitions. If you’d like a second set of eyes, our ICIMS consulting team reviews privacy configuration as part of every engagement.
ICIMS data privacy setup FAQ
Your next step
Tomorrow morning, open Admin > System Configuration > Applicant Tracking > General and look at the three settings. Then open the Personal Data Request report. If the settings are on and the report has requests nobody has touched, you have found your first project. If the settings are off and you hire outside the US, you have found your second.
Either way, ICIMS already has the tooling you need. Getting more from your ICIMS investment here means matching that tooling to the decisions legal already made, and giving one person the job of keeping it that way.
Want your ICIMS privacy configuration reviewed?
Book a free strategy call. We’ll walk through your scenario, your retention schedule, and the Support case you may still need to file.
Book a Free ICIMS Strategy Call →
