Personal Data Processing Policy
This document sets out, in operational detail, how personal data is processed within Pulse Call: the law we apply, the lawful bases we rely on, the retention schedule, the requirements we place on processors, and the procedures behind every right described in our Privacy Policy.
The Privacy Policy tells you, as a visitor or candidate, what happens to your data. This document is the internal processing standard behind it. Both are published so that our commitments can be checked against what we actually do.
1. Purpose, scope and applicable law
This policy applies to all processing of personal data carried out by SEAWAY DRAGON LP (registration number LP020855, registered in the United Kingdom on 17 February 2020, registered office Suite 6032, 128 Aldersgate Street, Barbican, London, England, EC1A 4AE) in connection with recruitment through the Pulse Call website and the channels linked from it.
It binds everyone who handles candidate data on our behalf — partners, managers, recruiters, contractors — in every country in which we recruit. Processors act under contract on the terms in section 10.
Two regimes apply to us in parallel, and where they differ we apply the stricter requirement to everyone:
| Regime | Why it applies | What we apply |
|---|---|---|
| UK GDPR and the Data Protection Act 2018, as amended by the Data (Use and Access) Act 2025 | We are established in the United Kingdom | The full UK regime, including the changes that took effect on 5 February 2026 and the complaints duty that took effect on 19 June 2026 |
| Regulation (EU) 2016/679 (EU GDPR), by virtue of Article 3(2)(a) | We offer roles to people located in the European Union and target them by country and language | The EU regime for candidates and visitors in the EU, including Chapter V on transfers and the EU rules on consent for cookies |
| PECR 1998/2003 (UK) and the ePrivacy Directive 2002/58/EC as implemented in each Member State | The Site stores and reads information on user devices | Section 19 of this policy |
2. Definitions
| Personal data | Any information relating to an identified or identifiable living individual |
| Processing | Any operation performed on personal data, from collection to erasure |
| Controller | The party that determines the purposes and means of processing — here, the company named in section 1 |
| Processor | A party that processes data on our behalf and on our instructions, such as a CRM or hosting provider |
| Data subject | The individual the data relates to — for us, candidates, referred people, referring participants and site visitors |
| Special category data | The categories listed in Article 9: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic and biometric data, health, sex life and sexual orientation |
| Significant decision | A decision producing a legal effect for a person or similarly significantly affecting them — the term used in Articles 22A to 22D of the UK GDPR |
3. Data protection principles
All processing follows the principles in Article 5, and we must be able to demonstrate that it does — the accountability principle.
| Principle | What it means in our work |
|---|---|
| Lawfulness, fairness, transparency | Every purpose has a lawful basis recorded in section 5, and the Privacy Policy states it plainly before data is collected |
| Purpose limitation | Candidate data is used to assess candidates. It is not reused for unrelated purposes without a compatibility assessment or a new basis |
| Data minimisation | The application block asks for three fields only — name, telephone number and language level. Everything else is optional. We do not ask for a photograph, date of birth, marital status, nationality or pay history |
| Accuracy | Candidates may correct their data at any time; recruiters record interview notes as observations, not as conclusions about the person |
| Storage limitation | The schedule in section 8 sets a defined end point for every category |
| Integrity and confidentiality | The measures in section 12 apply to every system holding candidate data |
4. Data subjects and categories of data
| Data subject | Data processed | Collected from |
|---|---|---|
| Candidate who applies directly | Name, telephone number, language level, optional free-text comment, the messenger account used to write to us, correspondence, interview notes, outcome | The candidate, through WhatsApp, email or a telephone call |
| Referred person | Telephone number, then the same data as above once contact is made and they choose to continue | The referring participant, then the person themselves |
| Referring participant | Name, telephone number, records relating to the bonus and its payment | The participant |
| Site visitor | IP address, user agent, time of access and requested page, in the logs kept by the hosting provider; the language preference stored on the device | Automatically, on visiting |
The Site has no server-side form, no account system and no analytics or advertising trackers. The tests run entirely in the browser and their answers are never transmitted to us. Application data reaches us only when the user sends the prepared message from their own messenger, or writes to us by email or telephone.
5. Lawful bases in detail
Each purpose is matched to one basis, chosen before the processing starts and recorded in the record of processing.
| Purpose | Basis | Notes |
|---|---|---|
| Receiving and assessing an application; contacting the candidate; interviewing; recording the outcome | Legitimate interests — Article 6(1)(f) | Our interest is filling roles with suitable people, and the candidate's interest is being considered. A legitimate interests assessment is documented and reviewed annually. We rely on this rather than on contract, because before an offer is accepted there is no contract to perform and the ICO expects legitimate interests at this stage |
| Steps taken at the candidate's request once an offer is made — preparing the contract, onboarding formalities | Contract — Article 6(1)(b) | These are steps prior to entering into a contract at the data subject's request |
| Keeping an unsuccessful application on file for future roles | Consent — Article 6(1)(a) | Requested separately, in plain language, as a distinct and unticked option. Refusing has no effect on the current application, and it may be withdrawn at any time |
| Referral programme: contacting a referred person once | Legitimate interests — Article 6(1)(f) | Limited to a single contact attempt, with the Article 14 information given at that first contact and immediate deletion if the person objects |
| Site security, spam filtering, investigating misuse | Legitimate interests — Article 6(1)(f) | Assessed and documented in the same way |
| Paying bonuses and salaries; accounting and tax records | Legal obligation — Article 6(1)(c) | UK accounting and tax law, and the equivalent law of the country of employment |
| Establishing, exercising or defending legal claims | Legitimate interests — Article 6(1)(f) | Supports the six-month retention in section 8 |
5.1. Legitimate interests assessments. Before relying on Article 6(1)(f) we carry out a three-part test — is the interest legitimate, is the processing necessary to achieve it, and is it overridden by the interests, rights and freedoms of the individual — and we keep the assessment in writing. The right to object under Article 21 is honoured, and it is set out in the Privacy Policy next to each purpose that relies on this basis.
5.2. Recognised legitimate interests (UK only). The Data (Use and Access) Act 2025 added Article 6(1)(ea) and Annex 1 to the UK GDPR, where certain narrow purposes — crime prevention and detection, safeguarding vulnerable individuals, responding to requests from public bodies and similar — need no balancing test. We do not use this basis in routine recruitment. It is available if, for example, we must respond to a law enforcement request, and any such use is logged with the Annex 1 condition relied upon. This basis has no EU equivalent, so for people in the EU we conduct the balancing test in the usual way.
5.3. No consent as a workaround. We do not use consent to legitimise processing a candidate cannot realistically refuse. Consent is reserved for the talent-pool retention in the table above and for anything genuinely optional.
6. Special category and criminal offence data
We do not seek data falling under Article 9 or Article 10, we do not ask about health, disability, beliefs, origin, union membership, sexual orientation or criminal records, and we rely on no condition in Schedule 1 of the Data Protection Act 2018.
Where a candidate volunteers special category data — most often in the free-text comment or in a WhatsApp message — the recruiter deletes it from the record without copying it elsewhere and without taking it into account in the assessment. The deletion is logged with the date and the person who carried it out. No copy is kept in exports, message archives or notes. Where the message itself cannot be edited, the whole message is deleted after the relevant non-sensitive details have been transcribed.
Requirements of the role that touch on health or disability, such as adjustments for an interview, are handled separately, recorded only to the extent needed to make the adjustment, and are never used in the selection decision.
7. Consent management
- Consent is requested separately from the application itself, in plain language, with no pre-ticked boxes and no bundling.
- We record what the person was told, what they agreed to, when, and by what means, so that consent can be demonstrated.
- Withdrawal is as easy as giving consent: one message to hr@pulse-call.com, with no explanation required and no detriment.
- On withdrawal we stop the relevant processing and delete the data, unless another basis genuinely applies, in which case we say which one and why.
- Consent to talent-pool retention expires after one year and is renewed or the record is deleted.
8. Retention schedule
| Record | Period | Trigger | Why that period |
|---|---|---|---|
| Unsuccessful application, including notes and correspondence | 6 months | From the last contact with the candidate | The window in which a hiring decision could be challenged |
| Application kept for future roles | 1 year | From the date consent was given | Consent; renewed or deleted at expiry |
| Interview notes | Same as the application they belong to | — | They form part of the assessment record |
| Referred person who declines contact | Deleted immediately, keeping only a suppression note if they ask not to be contacted again | At first contact | Minimisation; the suppression note exists only to honour the objection |
| Hired candidate | Transferred to employment records | On the start date | Employment and tax law of the relevant country |
| Referral bonus and payment records | 6 years | From the end of the accounting period | UK accounting and tax record-keeping |
| Messenger threads containing application data | 6 months, or until the application record is deleted if that is sooner | From the last message | The thread duplicates the record and must not outlive it |
| Server and access logs held by the hosting provider | Up to 12 months | From creation | Security monitoring and incident investigation |
| Records of consent | As long as the consent is relied on, plus 1 year | — | Demonstrating accountability |
| Data subject requests and complaints, with correspondence | 1 year after closure | — | Evidence that the request or complaint was handled |
9. Deletion and anonymisation
At the end of a retention period the record is deleted from the CRM and from every working copy — exports, spreadsheets, message threads and backups as they cycle. Where statistics are needed, data is anonymised so that re-identification is not reasonably possible, and the aggregated figures may then be kept indefinitely.
Retention is reviewed on a rolling basis at least quarterly. Deletions are logged so that they can be evidenced, and the log itself holds no more than the record reference and the date.
10. Recipients, processors and messaging platforms
10.1. Processors. Anyone processing candidate data on our behalf does so under a written contract meeting Article 28, which obliges them to:
- process only on our documented instructions;
- impose confidentiality on their personnel;
- apply appropriate technical and organisational security measures;
- engage sub-processors only with our authorisation and on equivalent terms;
- assist us with data subject requests, breach notification and impact assessments;
- delete or return the data at the end of the engagement;
- submit to audits and provide the information needed to demonstrate compliance.
| Recipient | Role | Data | Status |
|---|---|---|---|
| CRM provider used for the candidate pipeline | Processor | Contact and professional data, interview notes | Named provider, Article 28 contract and transfer mechanism recorded in the register of processors |
| Hosting and content delivery provider for the Site | Processor | Technical data in server logs | Named provider, Article 28 contract and transfer mechanism recorded in the register of processors |
| Accountant or payroll provider | Processor | Payment records for bonuses and salaries | Named provider, Article 28 contract recorded in the register of processors |
| Public authorities, courts, our legal or tax advisers | Separate controllers | Only what the law or the matter requires | Case by case, logged |
Applications normally reach us through WhatsApp, and some candidates use Telegram. Those providers — Meta Platforms Ireland Limited for WhatsApp, Telegram Messenger Inc. for Telegram — are not acting on our instructions when they carry a message. They are independent controllers for their own service, and they process at least the fact of the exchange, the phone numbers involved and their own account and metadata under their own terms and privacy policies. We cannot control that, we do not have an Article 28 contract covering it, and it is not something we can promise away. What we can do, and do, is: state it plainly in the Privacy Policy; offer email and telephone as alternatives; keep the prepared message limited to the fields the person entered; and copy the details we need into our own record and delete the thread on the schedule in section 8.
10.2. The register of processors names each current provider, the date of its Article 28 contract and the transfer mechanism relied on. It is kept with the record of processing under section 16, is available to a supervisory authority on request, and the identity of the providers is given to any candidate who asks. New processors are assessed for security and transfer arrangements before any data is shared, and the register is updated at the same time. We do not sell personal data and do not disclose it for third-party advertising.
11. International transfers
11.1. Candidate data is held in the United Kingdom and in the EEA. Transfers out of the UK or the EEA take place only where a Chapter V mechanism is in place: an applicable adequacy decision or adequacy regulations; the EU Standard Contractual Clauses; the UK International Data Transfer Agreement or the UK Addendum to the EU SCCs; or another appropriate safeguard.
11.2. Data flowing from the EEA to us in the United Kingdom is covered by the European Commission's adequacy decisions for the UK, renewed on 19 December 2025 and running to 27 December 2031. Data flowing from the UK to the EEA is covered by the UK's adequacy regulations. No additional safeguard is needed for those two routes while those decisions stand; we monitor them, because both carry a sunset date.
11.3. Where SCCs or the IDTA are used, we carry out and document a transfer risk assessment covering the law and practice of the destination country, and we apply supplementary measures where the assessment calls for them.
11.4. A message sent to us through a messaging platform may be routed through infrastructure outside the UK and EEA by that platform, under its own arrangements. That is a consequence of the person's choice of channel rather than a transfer we make, and it is one reason we offer alternatives.
12. Security measures
| Area | Measure |
|---|---|
| Transmission | HTTPS across the whole Site; messenger traffic is end-to-end encrypted by the platform |
| Access control | Individual named accounts, access on a need-to-know basis, removed the day a role changes or ends |
| Authentication | Unique credentials and multi-factor authentication on every system that supports it, including the messenger account used for recruitment |
| Device hygiene | Screen lock and disk encryption on devices with access to candidate data; the recruitment messenger account is not used on shared or personal devices without those protections |
| Confidentiality | Written confidentiality obligations for everyone with access, surviving the end of the engagement |
| Minimisation in practice | Candidate data is not copied into personal spreadsheets, private messengers or personal cloud accounts |
| Supplier assurance | Article 28 contracts and a security review before onboarding |
| Review | Access rights reviewed at least quarterly; every incident reviewed after closure and the lessons applied |
13. Personal data breaches
A personal data breach is any security incident leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. A lost phone with the recruitment messenger on it, a message sent to the wrong number and a mis-addressed export are all breaches.
- Report internally without delay. Anyone who becomes aware of a suspected breach reports it to hr@pulse-call.com immediately and does not try to resolve it alone.
- Contain and assess. We stop the ongoing exposure, establish what data and how many people are affected, and assess the risk to their rights and freedoms.
- Notify the supervisory authority within 72 hours of becoming aware, unless the breach is unlikely to result in a risk. Where both regimes are engaged we notify the ICO and the relevant EU authority. If full details are not available in time, we notify in phases.
- Notify affected individuals without undue delay where the risk to their rights is high, in clear language, describing the likely consequences and the steps taken.
- Record. Every breach is logged with its facts, effects and remedial action, whether or not it was notifiable, and the log is available to a supervisory authority on request.
Where a processor suffers a breach, its Article 28 contract requires it to inform us without undue delay so that these deadlines can be met.
14. Handling data subject requests
Requests may arrive in any form and through any channel — email, a WhatsApp message, a phone call — and there is no obligation on the individual to use a template or to say "GDPR".
- Any person receiving a request forwards it to hr@pulse-call.com on the same working day, because the deadline runs from receipt by the organisation, not by the right person.
- We respond within one month, extendable by two further months for complex or numerous requests, with the reasons given inside the first month.
- Identity is verified only where there is genuine doubt, using the least intrusive method available.
- Responses are free of charge. A reasonable fee or a refusal is possible only for manifestly unfounded or excessive requests, and we explain the reasoning and the right to complain.
- Where data about the requester also concerns another person — a referral, for instance — we release it only where that is reasonable, redacting what is not.
- We keep a log of requests, the dates and the outcome.
14.1. UK specifics from 5 February 2026. For requests under the UK GDPR, the Data (Use and Access) Act 2025 confirms that the search we must carry out is one that is reasonable and proportionate, and that where we genuinely need clarification to respond, the time limit pauses until the requester provides it. We use both carefully: clarification is requested only where the request is genuinely unclear and we can show why, we tell the requester that the clock has stopped, and a proportionate search is never an excuse for an incomplete answer. These provisions have no EU equivalent, so for requests under the EU GDPR we do not apply them.
14.2. Rights covered. Access, rectification, erasure, restriction, portability, objection, withdrawal of consent, and the rights connected with automated decisions in section 18. Erasure and objection are the ones we receive most often, and a candidate asking to be removed is actioned in full: record, thread and exports.
15. Complaints made to us
15.1. Section 103 of the Data (Use and Access) Act 2025 gives people in the United Kingdom a statutory right to complain directly to a controller about processing that infringes the UK GDPR or the Data Protection Act 2018, and imposes duties on how we handle it. Those duties apply from 19 June 2026. We apply the same procedure to everyone, including candidates in the EU, who have an equivalent route through Article 77.
| Step | What we do | Deadline |
|---|---|---|
| Making a complaint | By email to hr@pulse-call.com with "Data protection complaint" in the subject, or in writing to the registered office. No form is required, and any message that reads as a complaint is treated as one | — |
| Acknowledgement | Written acknowledgement confirming receipt and who is handling it | Within 30 days of receipt |
| Investigation and response | Appropriate steps to investigate, then the outcome, the reasons and any corrective action | Without undue delay; we aim for 30 days and tell the complainant if it will take longer |
| Record | Every complaint is logged with its date, substance, outcome and any change made as a result | Kept per section 8 |
15.2. Complaining to us is not a precondition for going to a supervisory authority, and we say so in every acknowledgement. The Information Commissioner's Office is the UK authority; in the EU it is the authority of the Member State where the person lives, works, or where the alleged infringement occurred.
16. Records of processing
We maintain a record of processing activities in line with Article 30, covering purposes, categories of data subjects and data, recipients, transfers, retention periods and a general description of security measures. The record is updated whenever a new tool, purpose, recipient or country is introduced, and is made available to a supervisory authority on request. The exemption for small organisations is not relied upon, because our processing is regular rather than occasional.
17. Impact assessments
A Data Protection Impact Assessment is carried out before any processing likely to result in a high risk to individuals — large-scale profiling, automated decision-making with significant effects, systematic monitoring, or the use of a new technology in the selection process.
Current recruitment processing does not meet that threshold: the data set is small, no special category data is sought, and no automated evaluation takes place. This conclusion is recorded, and is revisited whenever the processing changes — in particular before introducing any screening tool, call recording, monitoring of operators or AI assistance in selection.
18. Automated decisions and AI
18.1. We take no significant decision about a candidate based solely on automated processing. Every rejection and every offer is made by a person who has considered the file. The tests on the Site produce results in the visitor's own browser, are never transmitted to us, and play no part in selection.
18.2. If that changes. Article 22 of the EU GDPR prohibits solely automated significant decisions except in narrow cases with safeguards. In the UK, Articles 22A to 22D of the UK GDPR, in force since 5 February 2026, permit them more broadly but require safeguards: information about the decision, an opportunity to make representations, human intervention and a right to contest. Special category data may not be used for such a decision unless explicit consent or an Article 9(2)(g) condition applies. Any introduction of automated screening would require a DPIA, an update to this policy and to the Privacy Policy, and those safeguards in place beforehand — designed to the EU standard, which is the stricter of the two.
18.3. AI Act. AI systems intended for use in recruitment — screening applications, filtering candidates, evaluating them — are high-risk under Annex III of Regulation (EU) 2024/1689. The obligations attaching to Annex III systems now apply from 2 December 2027, following the amendment adopted in July 2026, while the Article 50 transparency duties and the Article 4 AI literacy duty apply already. We use no AI system in recruitment today. Should we adopt one, we would be a deployer of a high-risk system and would meet the deployer obligations — human oversight by a competent person, informing candidates, monitoring, and keeping logs — regardless of the deferred deadline.
19. Cookies and access to your device
19.1. The Site sets one cookie, pc_lang, and stores the same value in local storage, to remember the language chosen from the language switcher. It is written only when a visitor chooses a language, holds nothing but that choice, and expires after one year. There are no analytics, advertising, social or fingerprinting technologies on the Site.
19.2. Because this storage is used solely to provide a function the visitor explicitly requested, it is exempt from the consent requirement under regulation 6(4) of PECR and under Article 5(3) of the ePrivacy Directive. That is why the Site shows no cookie banner: there is nothing on it that consent could properly be sought for. Clearing browser storage removes the preference.
19.3. If we ever add analytics or any other non-essential technology, the two regimes now diverge and we will apply the stricter one:
| Regime | Position |
|---|---|
| United Kingdom | Since 5 February 2026 the Data (Use and Access) Act 2025 exempts certain purposes from consent — statistical measurement to improve the service, functionality and appearance preferences, security, and software updates — provided the visitor is given clear information and a straightforward way to object, and the data is used only for that purpose |
| European Union | No equivalent exemption is in force. The Commission's Digital Omnibus proposals of 19 November 2025 would change this, but they remain under negotiation, so analytics and similar storage still require prior consent, freely given through a banner that makes refusing as easy as accepting |
| What we would do | Ask for consent from everyone before setting anything non-essential, since the EU position is the stricter one and the Site serves both audiences |
19.4. Server logs kept by the hosting provider are not covered by these rules — they are a by-product of delivering the page — and are handled under section 5 (legitimate interests) and section 8 (retention).
20. Responsibilities and training
| Management | Owns compliance, approves this policy, allocates resources, signs off DPIAs and processor contracts |
| HR and recruiters | Apply the principles daily, collect only the required fields, remove special category data on sight, forward requests, complaints and suspected breaches the same working day |
| Anyone with data access | Follows this policy; unauthorised copying or disclosure is a disciplinary matter and may be a criminal offence under section 170 of the Data Protection Act 2018 |
| Data protection contact | hr@pulse-call.com — first point of contact for questions, requests, complaints and incidents |
| Data Protection Officer | Not appointed. Our processing is not large-scale systematic monitoring and does not involve large-scale special category data, so the Article 37 criteria are not met. The assessment is recorded and reviewed with this policy |
Everyone with access to candidate data is briefed on this policy when they start and whenever it changes materially, and the briefing is recorded.
21. Review and version history
This policy is reviewed at least annually, and sooner if the law changes, a new processor or channel is introduced, or an incident shows that a procedure needs improving.
| Version | Date | What changed |
|---|---|---|
| 2.0 | 19 August 2026 | Updated for the Data (Use and Access) Act 2025 (recognised legitimate interests, Articles 22A–22D, reasonable and proportionate searches and stop-the-clock, the section 103 complaints duty in force since 19 June 2026, and the PECR cookie exemptions in force since 5 February 2026) and for the divergence from the EU position; lawful basis for assessing applications moved from Article 6(1)(b) to Article 6(1)(f) in line with ICO guidance; messaging platforms described accurately as independent controllers rather than processors; processors described by category, with the named providers, their Article 28 contracts and transfer mechanisms held in the register of processors and given on request; cookies section rewritten to match what the Site actually stores; UK adequacy renewal to 27 December 2031 and the AI Act deferral to 2 December 2027 recorded. |
| 1.0 | 19 August 2026 | First published version. |