Before we talk about cost, we need to talk about whether a candidate portal on your website is even legal.

What the law states

If a candidate's data is collected through a website portal, but the recruiter actually works from their ATS/CRM, that portal data has no legitimate processing purpose at the point of collection. It is duplicate data sitting in a second system that the recruiter does not operationally use, which violates Articles 5(1)(b) and 5(1)(c) of the GDPR.

Most recruitment website providers promote candidate portals as a feature. Candidates register, upload their CV, build a profile, save jobs, and track applications, all through your website. It sounds useful.

The problem is that it is almost certainly not GDPR compliant.

Why website candidate portals break GDPR

Every recruiter works from their ATS or CRM. That is where candidate records live, where notes are kept, where compliance is managed, and where placements are tracked. Bullhorn, Vincere, JobAdder, Firefish, whatever system you use, that is your operational database.

If your website also has a candidate portal, you are collecting personal data, including CVs, contact details, work history and salary expectations, into a second system that you do not actually use to manage that candidate relationship. The data sits on your website while your team works from the ATS.

That breaks the first principle of GDPR. Article 5(1)(b) requires that personal data be collected for a specified, explicit, and legitimate purpose. Article 5(1)(c) requires that data collection is limited to what is necessary for that purpose. If you collect candidate data into a portal you do not use operationally, you have no legitimate purpose for retaining it there. You are storing personal data for no reason, in a system that is not your system of record.

It gets worse. You now have duplicate candidate data in two separate systems, your ATS and your website, with two separate retention policies, two separate consent records, and two separate breach notification obligations. When a candidate submits a data subject access request, you need to search both systems. When a candidate requests deletion, you need to delete from both. Most agencies do not even know the data is in two places.

Consent is more complicated than it looks

Even if you believe your portal consent is watertight, there are two problems that most agencies overlook.

The first is a mismatch between the consent version and the version used. A candidate may consent to one thing on the portal and something subtly different when their data enters the ATS. If your privacy policy is updated, which system records the new consent, and does the other reflect it? If the two records ever diverge, you cannot demonstrate compliance in either.

The second is granularity. The consent collected on the portal needs to be specific enough to cover every processing activity you carry out in the ATS. A generic "we will use your data to match you with roles" statement is unlikely to cover profiling, third-party sharing, or long-term retention. If your ATS processes data in ways your portal consent does not explicitly cover, you have a lawful-basis problem from the moment the data is transferred.

The third-party tracking problem nobody mentions

Most recruitment websites run advertising and analytics scripts, including Google Analytics, Meta Pixel, LinkedIn Insight Tag and Hotjar. These scripts are typically active across the entire website, including portal pages where candidates are submitting CVs and personal data.

If those scripts fire while a candidate is entering personal information, that data may be passed to Google, Meta, or other third parties without a lawful basis for doing so. This is not a theoretical risk. It is something regulators have already acted on in other sectors, and recruitment websites are not exempt.

Your website provider almost certainly has not audited which scripts are active on portal pages or what data they are capturing. Most have not even considered it.

The cybersecurity problem

A candidate portal adds login pages, password storage, session management, and file upload functionality to your website. CV upload fields are a known vector for malware injection. Your website is not built to the same security standards as a dedicated ATS platform. Bullhorn, Vincere, and JobAdder undergo regular penetration testing, hold SOC 2 or ISO 27001 certification, and have dedicated security teams. Your website does not, and even if the website vendor holds a certification, it will not be to the standard that your ATS can offer.

Every candidate portal on a recruitment website is an attack surface that your ATS vendor is far better equipped to defend.

There is also the question of breach notification. Most agencies have incident response procedures built around their ATS. If the portal is breached, do you have a process to identify it, contain it, and notify the ICO within 72 hours? In most cases, the honest answer is no.

The processor chain that most agencies have never mapped

When candidate data sits in a portal, it may pass through your website host, your CMS provider, your form plugin vendor, and your portal software vendor before it ever reaches you. Each of those is a data processor. Each one requires a signed Data Processing Agreement and documented due diligence.

If you use WordPress, this problem compounds further. Plugins routinely store data that the developer who installed them never knew about. Every plugin active on your site is a potential data store and a potential liability.

Most agencies have carefully mapped their ATS processor chain. Almost none have done the same for their website.

The orphaned account problem

Candidates who register on your portal but never complete an application still have personal data sitting in your system. In most cases there is no automated retention enforcement, no deletion trigger, and no process to contact them when their consent period expires. These accounts accumulate silently over months and years.

Under GDPR, you are obliged to hold personal data only for as long as there is a legitimate purpose for doing so. A candidate who registered two years ago, never applied, and has had no contact with your agency since, almost certainly does not meet that test. But their data is still there.

What RecruiterWEB does instead

We do not build candidate portals into our websites. Candidates search and apply for jobs on your website, and their data flows directly into your ATS through our integration. One copy of the data, in the system you actually use, managed by the platform that is built to handle it securely and compliantly.

Your website does what it is best at: attracting candidates and converting them into applicants. Your ATS does what it is best at: managing that data securely.

What to ask your current provider

If your recruitment website has a candidate portal, ask your provider these questions:

• Where is the candidate data stored?
• If you use WordPress, have all plugins been audited for what data they store?
• Is candidate data duplicated across both the website and the ATS?
• Which system is the authoritative record if a candidate updates their details in the portal?
• Who is the data controller for the portal data, you or your website provider?
• Do you have a signed Data Processing Agreement with your website provider?
• What third-party scripts are active on portal pages, and what candidate data are they capturing?
• What security protocols protect the portal, and how many staff or vendors have access to it?
• When was the portal last penetration tested?
• What is the data retention period for portal data, and is it enforced automatically?
• Is the consent collected on the portal specific enough to cover every processing activity carried out in the ATS?
• How are data subject access requests handled across both systems?
• What happens to portal data if you leave the platform?

If you or they cannot answer all of these clearly, you have a GDPR liability sitting on your website right now.

FAQs

Q1: Are candidate portals on recruitment websites GDPR compliant?

In most cases, no. If your recruitment website has a candidate portal that collects personal data (CVs, contact details, work history, salary expectations) into a system your recruiters do not operationally use, you are storing personal data without a legitimate processing purpose. Article 5(1)(b) of the GDPR requires data to be collected for a specified, explicit, and legitimate purpose. Article 5(1)(c) requires the collection to be limited to what is necessary. If your recruiters work from their ATS and never use the portal data, both principles are breached.

Q2: Why is having candidate data in two systems a GDPR problem?

When candidate data exists in both your website portal and your ATS, you have two separate retention policies, two separate consent records, and two separate breach notification obligations. When a candidate submits a data subject access request, you must search both systems. When a candidate requests deletion, you must delete from both. Most recruitment agencies do not even know the data is in two places, which means they are non-compliant without realising it.

Q3: Is a candidate portal on a recruitment website a security risk?

Yes. A candidate portal adds login pages, password storage, session management, and file upload functionality to your website. CV upload fields are a known vector for malware injection. Your website is not built to the same security standards as a dedicated ATS platform. Bullhorn, Vincere, and JobAdder undergo regular penetration testing, hold SOC 2 or ISO 27001 certification, and have dedicated security teams. A candidate portal on your website is an attack surface that your ATS vendor is far better equipped to defend.

Q4: What should a recruitment website do instead of a candidate portal?

Candidates should search and apply for jobs on your website, and their data should flow directly into your ATS through a native integration. One copy of the data, in the system your recruiters actually use, managed by the platform built to handle it securely and compliantly. Your website does what it is best at: attracting candidates and converting them into applicants. Your ATS does what it does best: managing its data. RecruiterWEB works this way by default on every plan.

Q5: How do I know if my recruitment website has a GDPR problem with candidate data?

Ask your website provider six questions: Where is candidate data stored? Is it duplicated in both the website and the ATS? Who is the data controller for data held in the portal? When was the portal last penetration tested? How are data subject access requests handled across both systems? What happens to portal data if you leave the platform? If they cannot answer all six clearly, you have a GDPR liability on your website right now.

 

About the Author

Darren, our founder, will provide you with a no-obligation, no-pressure demo.

Darren has walked your walk. As a former recruiter and recruitment company owner, he has been dedicated to recruitment website design, SEO, and marketing since 2004. There is nothing he enjoys more than chatting about recruitment, so reach out and pick his brains.

Give us a call at 01223 655278, or email him at darren@recruiterweb.co.uk