A procurement meeting is moving quickly. HR has agreed the workflow, IT has approved the Microsoft 365 fit, and legal is scanning the contract pack. Then someone says, “We still need to review the DPA.” Another person thinks that means data protection law. Someone else assumes it’s a contract. A third person has seen the same letters used in a completely different legal setting.
That confusion is common, especially in HR software buying. You’re often dealing with applicant data, payroll records, sickness information, identity documents, and time-and-attendance logs. Those aren’t abstract compliance issues. They’re highly practical questions about who can access data, how long it stays in the system, what happens if there’s a breach, and what your supplier must do when an employee makes a rights request.
If you’ve searched what is DPA, you’re probably trying to pin down which meaning matters to your organisation today. In most HR SaaS procurement work, the key term is the Data Processing Agreement. But the same letters can point to other UK legal concepts, and mixing them up can slow reviews or leave important clauses unchecked.
For HR and IT leaders in Microsoft 365 environments, the primary task isn’t memorising legal language. It’s understanding which DPA applies, what it must contain, and how to test whether an HR platform can support the obligations written into the paperwork.
Introduction
An HR director is finalising a new people system. The demo went well. Hiring managers liked the recruitment screens, finance approved the commercial case, and IT confirmed it sits comfortably alongside Teams, SharePoint, Outlook, and Dataverse. Then the contract pack lands, and one small acronym starts causing delays: DPA.
That moment matters more than it seems. In HR technology, the contract isn’t just admin. It defines how applicant records are processed, how employee files are protected, who reports incidents, and how the supplier helps when someone asks for a copy of their personal data. If those terms are vague, the risk doesn’t stay with legal. It lands on HR operations, IT governance, and audit readiness.
Readers usually get stuck in one of three places. First, they aren’t sure whether DPA means a contract, a law, or a regulator. Second, they don’t know what UK GDPR requires inside a vendor agreement. Third, they struggle to connect legal wording to system features such as CV parsing, clocking, document storage, and retention settings.
Practical rule: If a supplier processes workforce data on your behalf, the DPA should be reviewed with the same care as security architecture and implementation scope.
That’s where a clear, procurement-focused explanation helps. Once the terminology is separated and tied back to day-to-day HR SaaS decisions, the acronym stops being a legal obstacle and becomes a useful checklist.
Understanding the Different Meanings of DPAs
When people ask what is a DPA, they’re often using the plural loosely to refer to several things with similar initials. That’s where confusion starts. In UK HR and IT discussions, three meanings come up most often.
Data Processing Agreement
A Data Processing Agreement is a contract between a data controller and a data processor. In plain English, the controller decides why personal data is used, and the processor handles that data on the controller’s instructions.
For an HR example, your organisation decides to collect job applications and employee attendance records. Your software provider processes that data inside the platform. The DPA is the written agreement that sets the rules.
Consider a building-access policy for a contractor. You still own the premises and set the rules. The contractor can enter only for agreed tasks, in agreed areas, under agreed controls.
Data Protection Act 2018
The Data Protection Act 2018 is UK legislation. It isn’t the same thing as a supplier contract. It provides part of the legal framework around personal data in the UK, alongside UK GDPR.
A useful analogy is this. If the Data Processing Agreement is the tenancy agreement, the Data Protection Act is part of the law of the land. One governs your specific arrangement with a supplier. The other sets the wider legal rules everyone must follow.
Data Protection Authority
Some people also use DPA to mean a data protection authority, meaning the regulator or supervisory body. In the UK, organisations usually think in terms of the regulator rather than using the acronym in day-to-day conversation.
That matters because teams sometimes say, “Have we checked the DPA?” when they mean, “Are we compliant with the regulator’s expectations?” Those are related questions, but not identical ones.
- Contract meaning: Review the clauses, duties, retention, security, and breach handling.
- Law meaning: Check your processing is lawful under UK rules.
- Regulator meaning: Be ready to explain and evidence what you’ve done.
A lot of procurement friction comes from people using one acronym for three different jobs.
For HR software buying, the contract meaning is usually the one that needs immediate action.
Legal Context Under UK GDPR
In HR SaaS procurement, the DPA that matters most is the Data Processing Agreement required under Article 28 of the UK GDPR. This isn’t optional paperwork. It’s a defined legal requirement where one party acts as controller and the other acts as processor.
The legal position is especially relevant in Microsoft-based HR deployments because the software often handles sensitive operational processes, not just static employee records. Recruitment, onboarding, attendance, identity checking, and workflow approvals all involve repeated processing of personal data. The DPA has to match that reality.
According to the DPO Centre’s explanation of Data Processing Agreements, in the UK context relevant to HR and data compliance operations, “DPAs” isn’t a standard term, but the closely related and legally mandatory DPA under Article 28 requires a controller and processor to specify processing purposes, duration, nature, and security measures. The same source notes that non-compliance can trigger fines of up to £17.5 million or 4% of global annual turnover under the Data Protection Act 2018, and that breach notification support must align with the 72 hours requirement.
What the contract must pin down
A compliant DPA should remove ambiguity. If the system processes candidate CVs, employee clocking data, expenses, or disciplinary records, the contract should say so in a way that legal, HR, and IT can all understand.
That usually means setting out:
- Purpose: Why the processor is handling the data, such as delivering recruitment, onboarding, or workforce administration functions.
- Duration: How long data is processed during the agreement and what happens at the end.
- Nature of processing: Whether the platform stores, structures, analyses, transfers, or deletes information.
- Security measures: The practical controls that protect confidentiality, integrity, and availability.
Here is the video version of the legal backdrop many teams find useful before clause review:
Why HR systems need precise wording
Generic wording causes real problems in HR. If the agreement just says “employee data may be processed to provide services”, it doesn’t tell you enough. You need enough detail to assess risk.
For example, automated activities such as AI CV parsing and facial-recognition clocking need explicit attention in the DPA because they’re not passive storage functions. They involve active processing decisions, and they may also trigger internal scrutiny around fairness, transparency, and impact assessment.
Legal reality: If a platform feature changes how personal data is analysed or matched, the contract should reflect that change instead of hiding it inside broad wording.
Another point often missed is assistance. A processor doesn’t just run the system. Under the DPA, it may need to help the controller respond to data subject rights requests, support breach management, and assist with Data Protection Impact Assessments where higher-risk processing is involved.
Why this matters in procurement meetings
A strong Article 28 review changes the questions buyers ask. Instead of asking only, “Does the system have this feature?”, teams ask:
| Procurement question | Why it matters |
|---|---|
| What exactly is being processed? | It defines the contract scope. |
| Can the supplier support rights requests? | HR teams need operational help, not just legal wording. |
| How are incidents handled? | Breach response needs clear roles and timing. |
| Do high-risk features need extra controls? | Some workflows need DPIA support and tighter review. |
That's the point where legal drafting becomes operational governance.
Controller and Processor Responsibilities
The cleanest way to understand a DPA is to follow the data. In HR, your organisation usually acts as the controller because it decides why applicant and employee data is collected. The software provider usually acts as the processor because it handles that data on your instructions.
What the controller owns
The controller makes the core decisions. HR chooses to collect CVs, retain right to work evidence, store absence records, and run performance processes. IT may help configure the platform, but the organisation still owns the purpose behind the processing.
In practice, the controller should:
- Define the purpose: Know why each category of workforce data is being used.
- Choose the processor carefully: Check whether the supplier can meet legal and operational obligations.
- Set retention rules: Decide how long candidate, employee, and leaver records should stay.
- Handle rights decisions: Approve how access, erasure, or rectification requests are managed.
What the processor must do
The processor follows documented instructions and supports the controller's compliance duties. In an HR platform, that often includes hosting data, applying permissions, producing exports, logging activity, and helping investigate incidents.
A processor's role often becomes clearer with examples:
- Payroll data flows through the system. The processor provides the environment and controls. The controller decides what payroll data is collected and why.
- A candidate asks for a copy of their application data. The controller remains responsible for the response, but the processor may need to help retrieve the records.
- A security incident affects employee information. The processor must alert the controller promptly and provide the facts needed for assessment and reporting.
When a supplier says, “We are only a processor,” that doesn't reduce their responsibilities. It defines a different set of responsibilities.
Where teams usually get muddled
Confusion often appears around subject access requests and breaches. HR teams sometimes assume the supplier must answer employee requests directly. Usually, that isn't the case. The organisation remains the decision-maker, while the processor supplies the tools, records, and support needed to respond properly.
That division of labour should be visible in both the contract and the operating model. If it's only in one of them, the process usually breaks under pressure.
Practical Checklist and Sample Clauses for HR SaaS Procurement
A DPA review becomes much easier when you convert legal language into a buying checklist. HR, IT, procurement, and legal can then test the same points from different angles.
Procurement checklist
- Scope of processing: Identify what data the supplier handles, for which HR processes, and for how long.
- Security measures: Check access controls, authentication, auditability, and administrative safeguards.
- Breach handling: Confirm who notifies whom, how quickly, and what information will be provided.
- Sub-processor rules: Review whether other service providers are involved and how approvals or notifications work.
- Retention and deletion: Match system behaviour to your candidate and employee retention policy.
- Rights assistance: Ensure the supplier can help with access, correction, deletion, restriction, and portability tasks where relevant.
- DPIA support: Check whether the supplier will assist when higher-risk HR features need formal assessment.
- Exit arrangements: Confirm how data is returned, exported, or deleted at contract end.
Questions worth asking in the meeting
Some questions reveal more than generic assurances.
- “Show us how a leaver record is retained and then deleted.”
- “Show us how clocking logs are exported for a rights request.”
- “Show us what happens if a hiring manager gains access they shouldn't have.”
- “Show us how sub-processor changes are communicated.”
That “show us” approach is stronger than “tell us”. It forces contract language and product behaviour to line up.
Buyer's note: If the supplier can't demonstrate how the clause works in the product, treat the wording as incomplete rather than reassuring.
Sample DPA Clauses
| Clause Type | Example Text |
|---|---|
| Scope of Processing | “The Processor shall process personal data only to deliver the agreed HR software services and only on the documented instructions of the Controller.” |
| Purpose and Nature | “Processing includes hosting, storage, retrieval, structuring, transmission, and deletion required to support recruitment, employment administration, and related HR workflows.” |
| Security | “The Processor shall maintain appropriate technical and organisational measures to protect personal data against unauthorised access, loss, alteration, or disclosure.” |
| Breach Notification | “The Processor shall notify the Controller without undue delay after becoming aware of a personal data breach and shall provide available information needed for assessment and response.” |
| Data Subject Rights Assistance | “The Processor shall provide reasonable assistance to enable the Controller to respond to requests from data subjects exercising their statutory rights.” |
| Retention and Deletion | “Upon termination of the services, the Processor shall delete or return personal data in accordance with the Controller’s documented instructions and applicable law.” |
| Sub-processors | “The Processor shall not appoint a sub-processor without maintaining an appropriate approval or notification mechanism and shall remain responsible for sub-processor compliance.” |
| DPIA Support | “The Processor shall assist the Controller with information reasonably required for data protection impact assessments where the processing creates elevated privacy risk.” |
Integrating DynamicsHub into Your Data Processing Agreements
When buyers assess whether a platform can support a strong DPA, they should focus on architecture, controls, and operational fit. Marketing claims matter far less than where data sits, who can access it, and how the system behaves during routine HR tasks.
For Microsoft 365 organisations, one of the strongest procurement advantages is a model where HR data resides within the customer's own Microsoft environment rather than being pushed into a disconnected external stack. That changes the DPA conversation. It can simplify questions around control, access governance, and records management because the organisation keeps tighter operational alignment between system use and tenant-level oversight.
Why configuration matters as much as contract wording
A DPA works best when its clauses map directly to configurable platform behaviour. If your agreement says records must be retained for a defined period and then deleted, the system should support that policy in practice. If your agreement says access must be role-based, permissions should be manageable through familiar Microsoft identity controls.
In this context, product design becomes a compliance issue. Features such as automated job publishing, AI CV parsing, clocking, case management, and document handling need settings, logs, and permission structures that support the organisation's own rules.
Hubdrive product information describes a hire-to-retire model built on Microsoft Dynamics 365 and Dataverse, with modules for recruitment, onboarding, employee management, time, and compliance. In UK implementations, that matters because the DPA isn't reviewing one isolated database. It's reviewing a working HR environment with integrated processes.
What procurement teams should test
A practical review should examine whether the platform supports these points:
- Tenant-resident data: Does the organisation retain strong control over where workforce data is managed within its Microsoft estate?
- Retention controls: Can HR and IT align candidate, employee, and leaver retention to policy?
- Identity and access: Can permissions be managed through Microsoft Entra ID and role-based administration?
- Operational evidence: Are logs available for actions such as job posting, CV handling, approvals, and attendance events?
- Compliance support: Can the platform support Right to Work workflows and GDPR-aligned handling without awkward manual workarounds?
These aren't abstract concerns. They're the details legal teams eventually ask about when a clause must be justified.
A procurement-ready HR platform should make the DPA easier to evidence, not harder to interpret.
The message for UK organisations is straightforward. We are DynamicsHub.co.uk. Experience HR transformation built around your business. Hubdrive's HR Management for Microsoft Dynamics 365 is the premier hire-to-retire solution, more powerful, more flexible, and more future-ready than Microsoft Dynamics 365 HR. That positioning matters because the right platform doesn't just meet functional HR needs. It supports the legal and operational discipline a modern DPA demands.
Conclusion and Next Steps
If you started with the question what is DPAs, the key takeaway is simple. In HR SaaS procurement, the term that usually matters most is the Data Processing Agreement. It's the contract that defines how your supplier may process workforce data, what safeguards apply, and how each side handles rights, incidents, retention, and oversight.
The best next step is to review your current supplier paperwork with a mixed team. Bring in HR, IT, procurement, legal, and whoever owns Microsoft 365 governance. Check whether the contract language matches the system's actual behaviour. If it doesn't, update both.
Then look at your templates. Your DPA review process should cover data scope, security, breach handling, rights assistance, sub-processors, retention, and end-of-contract actions. For higher-risk HR features, make sure your process also checks whether DPIA support is needed.
A well-reviewed DPA doesn't slow transformation. It gives HR and IT the confidence to move forward without guessing.
DynamicsHub helps UK organisations implement and support HR transformation on Microsoft Dynamics 365 and the Power Platform, with Hubdrive expertise shaped around real compliance, security, and operational needs. If you want practical guidance on HR data processing, GDPR-aligned configuration, and a hire-to-retire platform built for Microsoft 365, contact DynamicsHub. Phone 01522 508096 today, or send us a message.
