Our last two guides followed the money. The incentives guide traced what happens after a participant is promised a payment, and our guide to costing a fieldwork job showed how incidence and strike rate decide the margin before the first call is made.
Both lead back to the same place. The incidence you actually achieve, the strike rate your recruiters see, the professional respondents who slip through and the people you can reach for a hard cell at short notice are all decided by one asset: your participant database.
It is the most valuable thing most fieldwork agencies own, and often the least managed. In a typical agency it lives across a CRM or an ageing Access database, a shared drive of recruitment spreadsheets, freelance recruiters’ own contact lists and several inboxes. It holds health conditions, ethnicity, household income and children’s ages. And since the Data (Use and Access) Act 2025 began coming into force, the rules around it have moved.
This guide is for operations directors, field managers and data protection leads at UK research and fieldwork agencies. It covers the legal basis for holding participant data, recontact consent, retention, repeat participation, fraud, what has changed in 2025 and 2026, and what a well-run database looks like in practice. It is a practical operations guide, not legal advice: for decisions about your own lawful basis or contracts, speak to a data protection specialist.
"Your participant database is the only part of your agency that every single job depends on. It deserves to be run like infrastructure, not like a contact list."
Why the database decides your margin
When a field director estimates incidence for a quote, they are really estimating how well the people they can reach match the specification. A database with fresh, well-structured profile data lets recruiters screen the right people first. A stale one sends them through hundreds of calls to people who moved house, changed jobs or stopped answering three years ago.
The same is true of strike rate. Members who were recently active, who were paid promptly last time and who are not being contacted every week convert better than members who have been ignored or overused. Database quality shows up directly in the recruiter hours on every job, which is the cost driver that our incidence and strike rate worked example showed can double when incidence halves.
There are four ways a database typically degrades:
- Profile decay. Profiling answers are captured once at sign-up and never refreshed, so screening by profile becomes guesswork.
- Fragmentation. The same person exists in the CRM, in two recruiters’ spreadsheets and on the voucher platform, under slightly different details.
- Overuse. Easy, responsive members are contacted for everything, which drives repeat participation problems and burns out your best people.
- Accumulation. Nobody is ever removed, so the database grows in size while shrinking in usefulness, and every record carries a compliance cost.
Each of these is also a data protection problem. That is the useful insight: in a participant database, good compliance and good operations are the same work.
Lawful basis and special category data
Holding someone on a recruitment database so that you can invite them to future research is processing personal data, and it needs a lawful basis under Article 6 of the UK GDPR. Most agencies rely on consent, given when the person joins the database, or on legitimate interests supported by a documented assessment. Which is right depends on how people join, what they are told and what you do with their data, and it is worth getting advice on.
Recognised legitimate interests will not cover recruitment
The Data (Use and Access) Act 2025 introduced a new lawful basis, recognised legitimate interests, which removes the need for a balancing test for a short list of purposes. That list covers disclosures for public tasks, national security and defence, emergencies, crime, and safeguarding vulnerable people. Research recruitment is not on it, so nothing about your existing basis changes. If anyone in your business has heard that the new Act “relaxed legitimate interests”, that is the reason it does not help here.
Screening criteria are often special category data
This is where many databases carry more risk than their owners realise. A great deal of recruitment depends on exactly the information the UK GDPR treats as special category data: health conditions for healthcare and pharmaceutical work, ethnicity for boost samples, religion, sexual orientation and trade union membership for specific studies.
Processing special category data needs an additional condition under Article 9. For a commercial recruitment database, that is usually explicit consent. The ICO says explicit consent must meet the normal standard for consent (freely given, specific, opt-in, unambiguous and easy to withdraw), must be confirmed in a clear statement, must specify the type of special category data, and must be separate from any other consent.
Operationally, that means a single “I agree to the privacy policy” tick box at sign-up is not enough for the health and ethnicity fields your healthcare recruiters screen on. You need separate, specific consents, a record of exactly what each person agreed to and when, and a way to honour a withdrawal for one category without deleting the whole record.
A useful test: pick a member at random who has a health condition recorded. Can you show, within five minutes, the wording they agreed to, the date, how they gave it, and whether they have since withdrawn? If not, your consent records are a risk, not an asset.
Recontact: permission, wording and evidence
The MRS rules on recontact are short and precise. The MRS Guidelines for Qualitative Research state that recontact may be carried out only if the participant’s permission was obtained during the initial data collection (Rule 43), with an exception for recontact for quality control. Rule 44 adds that recontact must match the assurances given when permission was obtained, including when recontact would happen, for what purpose and by whom.
The same guidelines advise that recruitment permission should be collected in a verifiable form, written or recorded, so that it can be referred to if there is any doubt later. And the IQCS standard allows the required privacy information to be built into the invitation for qualitative recruitment where it has not already been given.
Put together, that gives a clear specification for what every participant record should hold:
- Source. How and where the person was recruited, and by whom.
- Permission scope. Recontact for further research generally, for a follow-up on this project, or for quality control only.
- Wording version. Which privacy notice and consent text they saw, stored as a version rather than a copy pasted into a notes field.
- Evidence. A timestamp and the method: web form, signed paper form, recorded call.
- Withdrawals. When and how any permission was withdrawn, and confirmation it was actioned.
A recruiter about to call someone should be able to see, on one screen, whether that call is permitted. If the answer is buried in an email from 2022, the rule will not be applied consistently.
Retention: how long to keep participant data
There is no statutory number. The ICO’s storage limitation guidance is clear that the UK GDPR does not set specific time limits, that you must decide and be able to justify your own periods, that you should not keep data indefinitely “just in case”, and that you should review data periodically and erase or anonymise what you no longer need. It also notes that moving data offline is not the same as deleting it.
The practical mistake most agencies make is applying one retention period to the whole record. A participant database is really several kinds of data with different purposes, and each needs its own rule. The schedule below is an illustration of how to think about it, not a recommendation for your business:
| Data | Why you hold it | Illustrative retention approach |
|---|---|---|
| Core contact and profile data | Inviting the member to future research | While the member is active; review after a defined period of inactivity, then refresh consent or remove |
| Special category profile fields | Screening for specific studies | Shortest practical period, tied to explicit consent; removed independently of the rest of the record on withdrawal |
| Screener responses for people who did not qualify | Feasibility and incidence evidence | Aggregate counts kept for quoting; individual answers removed once the job closes |
| Participation history | Enforcing exclusion periods and frequency limits | Minimal record (date, method, subject category) kept for the longest exclusion window you enforce |
| Validation records | Quality control and audit | IQCS requires a minimum of 12 months |
| Payment details | Issuing incentives | Removed once the job’s incentives are reconciled, keeping only what audit needs |
Two things make this work. First, the schedule has to be enforced by the system, with review queues and automatic anonymisation, because nobody will run a manual purge every month. Second, notice the separation: aggregate incidence data can be kept indefinitely because it is no longer personal data, and it is exactly the evidence your quoting needs. Deleting individual screener answers does not mean losing what you learned from them.
Repeat participation and exclusion periods
Clients set past participation rules for a reason: people who take part too often stop behaving like ordinary consumers. The MRS’s guidance for recruiters gives typical examples, such as excluding anyone who attended a qualitative event in the preceding six months or year, or who has ever taken part in research on the same subject. It also recommends being open with clients about how the rules are applied and asking whether they will relax them for hard-to-reach audiences.
The IQCS standard turns this into something auditable. Recruiters must be briefed on the acceptable time gap for previous attendees, group validation must establish the time elapsed since the participant attended a previous group, and the standard recommends checking participants against previous recruitment lists up to twelve months old.
Here is the problem. If your previous recruitment lists are spreadsheets on a shared drive, and some recruits came from freelancers’ own contacts, nobody can reliably check a new recruit against twelve months of history. The check becomes the participant’s own answer to “have you taken part in research recently?”, which is exactly the question professional respondents learn to answer.
Designing the participation record
Enforcing exclusions needs surprisingly little data, which is good news for data minimisation:
- Date of participation, so exclusion windows can be calculated.
- Method (group, depth, online community, ethnography), because some clients only exclude by method.
- Subject category from a controlled list, such as “financial services” or “alcohol”, rather than free text.
- Client sector, not the client’s name, where the client’s identity is confidential.
- Outcome: attended, no-show, sent home, removed for quality reasons.
With that structure, exclusion rules become configuration on the job (“no groups in the last six months, no financial services ever”) and the system checks every candidate automatically at screening, at confirmation, and again before payment, as we suggested in the incentives guide. Recruiters stop being the last line of defence and become the people who handle the exceptions.
Frequency caps protect your panel
Exclusion periods protect the client. Frequency caps protect you. Setting a maximum number of invitations and participations per member per period spreads work across the database, reduces burnout among your most responsive members and stops a small group of regulars quietly becoming your sample. The cap should be enforced in the same place as exclusions, and overridden only by a named person with a recorded reason.
Fraud and identity in remote qualitative research
Remote fieldwork widened the pool of people agencies can reach. It also widened the pool of people who can pretend to be someone else. A 2025 Quirk’s case study, Participant fraud in qualitative research: a wake-up call, describes participants who joined with audio only, paused for several seconds before every answer, sat in poorly lit rooms with their faces partly hidden, appeared to be querying an AI tool when asked an off-script technical question, and did not match the LinkedIn profile given to the recruiter. When the recruiter was pressed to verify identities, every suspicious participant turned out to be fraudulent.
The standards already expect identity to be checked. Under the IQCS standard, a depth participant’s identity should be confirmed at the interview, and all participants’ identities should be confirmed at a group. The challenge is doing that consistently, online, at volume, without making the experience hostile for genuine participants.
Controls that belong in the database
- Cross-identity matching. The same phone number, email pattern, postal address or payment details appearing on several “different” members is the strongest signal you have. It can only be detected if all recruitment sources feed one database.
- Camera-on and verification steps recorded against the session, so you can show the IQCS identity check took place.
- Consistency checks between the profile, the screener and what the participant says on the day. Adaptive follow-up questions that refer back to earlier answers are hard for a fabricated identity to sustain.
- Moderator feedback captured in a structured form after every session, which IQCS already requires to be documented, and linked to the participant record.
- Payment as the final gate. Incentives released only after attendance and quality checks are confirmed, with flagged participants held for review.
Handle fraud flags carefully
A note on a record saying a person is suspected of fraud is itself personal data. It can be requested in a subject access request, it must be accurate, and it can affect whether someone is invited again. Record the evidence (duplicate payment details on these records, identity mismatch at this session) rather than conclusions, restrict who can see it, and have a review route. A database that flags fairly is easier to defend than one that quietly blacklists.
What the Data (Use and Access) Act 2025 changed
The Act received Royal Assent on 19 June 2025 and has been brought into force in stages. According to Mayer Brown’s commencement summary, most of the main data protection reforms took effect on 5 February 2026, and the new complaints requirement on 19 June 2026. Four changes matter most for a participant database.
1. You must now run a data protection complaints process
Since 19 June 2026, controllers must make it easy for people to complain about how their personal data is handled, including by an electronic form, and must acknowledge complaints within 30 days, investigate without undue delay and keep the complainant informed. For an agency holding tens of thousands of members of the public, that means a visible route on your website and privacy notice, and a log with deadlines that someone owns. A shared inbox is not a process.
2. Subject access requests: reasonable and proportionate searches
The Act confirms that you need only carry out a reasonable and proportionate search in response to a subject access request, and that the one-month clock pauses while you wait for clarification you genuinely need. That helps, but it does not rescue an agency whose data on one person is spread across a CRM, five recruiters’ spreadsheets, a voucher platform and email. When a member asks for everything you hold, the honest answer depends on whether you can find it.
3. Higher PECR penalties
The maximum fines under the Privacy and Electronic Communications Regulations were raised to UK GDPR levels, up to £17.5 million or 4% of global turnover. Genuine research invitations are not direct marketing, but messages that promote your agency’s services or a client’s products alongside an invitation can cross that line. Keep recruitment communications strictly about research, and keep any marketing consent separate.
4. Recognised legitimate interests
As covered above, this new lawful basis does not extend to recruitment, so there is nothing to change in your lawful basis because of it.
"Most data protection obligations are easy to meet if you know where every piece of a person’s data lives. Almost all of them are hard if you do not."
Freelance recruiters and the data you do not control
Many agencies rely on freelance recruiters, and many of those recruiters bring their own contacts. That is often where a database’s most valuable members come from, and where its biggest blind spot sits.
The MRS qualitative guidelines note that most recruiters who hold participant details need to register with the ICO as data controllers in their own right. That has consequences. If a recruiter supplies participants from their own list, the agency may not hold the consent records for those people, cannot apply its retention schedule to them and cannot easily include them in exclusion checks. If the agency supplies its own members to the recruiter in a spreadsheet, that spreadsheet has left the agency’s control.
The MRS guidelines also require the rights and responsibilities of members, clients and subcontractors to be governed by a written contract. Good practice is to:
- Agree roles in writing. Who is the controller for which participants, and what each party may do with the data.
- Give recruiters access, not exports. A recruiter portal with role-based permissions keeps your members in your database, logs who looked at what and removes access cleanly when the relationship ends.
- Capture every recruit in the central record. Including those sourced from a recruiter’s own contacts, with the source recorded, so participation history and fraud checks cover everyone who actually attended.
- Brief once, centrally. Exclusion rules, consent requirements and identity checks delivered through the job, not reinvented in each recruiter’s briefing email.
We cover recruiter employment status, pay models, IQCS validation and quality scoring in more depth in our guide to managing freelance qualitative recruiters.
What a well-run participant database looks like
Whether you extend a panel platform, configure a CRM or build around your operation, these are the capabilities that separate a database that earns its keep from one that quietly costs money and carries risk:
- One record per person. Deduplication at sign-up and at every import, with recruiter-sourced participants captured in the same place.
- A consent ledger. Versioned wording, timestamps, method and scope for each permission, including separate explicit consents for special category fields.
- Protected special category data. Held in separate fields with tighter access, visible to recruiters only when the job needs it.
- Structured participation history. Date, method, subject category, client sector and outcome, feeding automatic exclusion and frequency checks.
- Fraud and identity signals. Cross-identity matching, verification records and moderator feedback linked to the person, with an evidence-based review process.
- Retention that runs itself. Rules per data type, inactivity review queues and automatic anonymisation, with aggregate incidence data preserved.
- Rights handling built in. Subject access exports and erasure from one place, and a complaints log with the 30-day acknowledgement tracked.
- Recruiter access, not spreadsheets. Role-based portals with an audit trail of every search, view and export.
- Connected to the rest of the job. Screening outcomes feed actual incidence and strike rates back to quoting, and attendance feeds incentive payments.
That last point is where the commercial value compounds. When the database, the field system and quoting share the same records, you can answer “what incidence did we actually achieve for this audience last time?” from evidence rather than memory, which is the approach we set out in quoting from your own job history. Generic professional services tools rarely touch any of this, which is one reason we argued in our Accelo vs Scoro comparison for fieldwork agencies that the fieldwork-specific layer is usually where custom software earns its place.
How healthy is your participant database?
We will run a short database health check with you: where participant data actually lives, how consent and participation history are recorded, how many duplicates you are carrying and how long a subject access request would really take. You will get a plain-English summary of what to fix first, whether or not the answer is software.
Book a free discovery call →Seven measures of database health
You cannot manage a database by its size. These measures tell you whether it is getting more useful or just bigger:
| Measure | How to calculate it | What it tells you |
|---|---|---|
| Active member rate | Members who responded to any contact in the last 12 months divided by all members | How much of your database is real capacity |
| Profile freshness | Median months since each member’s profile was last confirmed | Whether screening by profile can be trusted |
| Consent coverage | Members with a recorded, versioned consent for each purpose you use | Your exposure if a regulator or client asks |
| Duplicate rate | Records merged or flagged as duplicates divided by records created | Data quality at the point of entry, and fraud pressure |
| Exclusion catches | Candidates blocked by exclusion or frequency rules before confirmation | Whether your rules are working, or being discovered by the client |
| Strike rate by source | Attended divided by qualified, split by recruitment source | Which sources, recruiters and campaigns produce reliable participants |
| Rights response time | Days to fulfil subject access, erasure and complaint acknowledgements | The clearest test of whether you know where your data is |
Where to start
None of this needs to happen at once. In order of effort:
- Map where participant data lives. List every system, spreadsheet, inbox and recruiter list that holds it. This is the single most useful hour you will spend.
- Publish a complaints route. If you do not yet have one that meets the June 2026 requirement, add a form and a log with a 30-day acknowledgement target.
- Separate your special category consents. Review the sign-up wording for health, ethnicity and other sensitive fields, with advice where needed.
- Write a retention schedule by data type. Then remove what falls outside it, keeping aggregate incidence counts.
- Bring participation history into one place. Even a structured central log of who attended what, when and on which subject makes exclusion checks possible.
- Replace exports with access. When volume justifies it, give recruiters a portal onto one database, with exclusions, consent checks and fraud signals applied automatically.
If the participant database is one of several systems still held together by spreadsheets, our practical workflow for replacing spreadsheets in a research agency explains how to sequence the change without disrupting live jobs.
We build these systems in Laravel for research, fieldwork and professional services firms, and we are currently building an operations platform with a UK fieldwork agency covering quoting, recruiters, quotas, incentives and job profitability. Arc Digital is based in Leeds and works with agencies across the UK.
Frequently asked questions
Do we need consent to keep people on a research recruitment database?
You need a lawful basis, which for most recruitment databases is either consent or legitimate interests supported by a documented assessment. Separately, the MRS rules require permission for recontact to have been obtained when the data was first collected, and that recontact must match what the participant was told. If you hold special category data such as health conditions, you will usually also need explicit consent for those fields.
Can we store participants’ health conditions for screening?
Yes, if you have a lawful basis and an Article 9 condition, which for commercial recruitment is usually explicit consent. The ICO says explicit consent must be specific to the type of data, confirmed in a clear statement and kept separate from other consents. Hold the data only as long as you need it and restrict access to the people screening for studies that require it.
How long can we keep participant data?
The UK GDPR sets no fixed period. You must set and justify your own retention periods, review data regularly and erase or anonymise what you no longer need. In practice, set separate periods for contact data, sensitive profile fields, participation history, validation records and payment details, because each serves a different purpose.
How do we stop people taking part in research too often?
Record a minimal participation history for every participant (date, method, subject category, client sector and outcome) in one central database, including people sourced by freelance recruiters. Configure each job’s exclusion rules and check every candidate automatically at screening, at confirmation and before payment. The IQCS standard recommends checking against previous recruitment lists up to twelve months old.
Do freelance recruiters need to register with the ICO?
The MRS qualitative guidelines note that most recruiters who hold participant details need to register with the ICO as data controllers. Agree roles and responsibilities in a written contract, and where possible give recruiters access to your database rather than exporting member lists to them.
What does the Data (Use and Access) Act 2025 mean for fieldwork agencies?
The most practical changes are the requirement to run a data protection complaints process from 19 June 2026, clarification that subject access searches need to be reasonable and proportionate, and much higher maximum fines for breaches of the electronic marketing rules. The new recognised legitimate interests basis does not cover research recruitment.
If you run a research or fieldwork agency and your participant data lives in more places than you would like, we would be glad to take a look. We will map where your members’ data actually sits and tell you plainly what to fix first, whether or not the answer is software.