A UK HR director receives a Dataverse alert during a busy afternoon. A personnel record from Dynamics 365 has been shared externally because a Power Automate flow used the wrong connection or security setting. The record might contain contact details, employment information, absence data or documents from a personnel file.
The immediate questions aren't theoretical. Who accessed the record? Was it downloaded? Which audit trail proves what happened? Did the flow send the information to a mailbox, SharePoint site or external recipient? Can HR, IT and the Data Protection Officer explain the incident to the ICO within the applicable reporting window?
That moment shows why data protection policies must describe real Microsoft 365 operations. A policy that only repeats general principles won't tell anyone how DynamicsHub tables, Dataverse security roles, Power Automate connections or audit logs behave. The policy has to guide decisions while people are working, not sit unread in a shared folder.
When an HR Data File Goes Astray in Dynamics 365
The HR director first asks IT to stop the flow without deleting evidence. IT checks the Power Automate run history, Dataverse audit records and Microsoft Entra ID sign-in information. HR identifies the affected employee record, while the DPO starts building an incident timeline and assessing whether the exposure creates a risk to the individual.
The next questions are harder. Was the external recipient authorised to receive workforce data? Did the flow include the entire row when it only needed a status field? Were documents included from a related table? Did a service account run the export, and can the organisation identify the person who configured it?
Operational rule: A policy should tell named people what to check, what to preserve and who must make the next decision.
A well-designed policy links the legal requirement to the technical path. It explains which team owns the Dataverse environment, who can change a security role, how privileged access is reviewed, where incident evidence is stored and how the organisation records a decision about notification. It also distinguishes an actual disclosure from a blocked attempt, because the response and evidence may differ.
The organisation's broader security approach should sit alongside its policy work, including practical controls described in cloud data security guidance. Security isn't a substitute for data protection governance, but it gives the policy something concrete to enforce.
The UK enforcement environment makes this operational discipline important. The ICO received 41,661 data protection complaints in 2018/19, 42,315 in 2024/25, and 76,743 in 2025/26, as recorded in its annual report for 2025/27. In 2024/25, the ICO concluded 43 GDPR investigation cases and 204 incidents, issued 31 reprimand outcomes across 9 cases, and imposed two UK GDPR penalty notices totalling £3,826,320.
Those figures don't mean every alert becomes a fine. They do show that complaints, incidents and enforcement activity are part of the operating environment. A policy becomes useful when it helps the organisation answer the first questions quickly, preserve reliable evidence and reduce the chance that a configuration mistake becomes a wider disclosure.
What a Data Protection Policy Actually Means in the UK
A data protection policy is the organisation's working description of how it collects, stores, uses, shares, retains and deletes personal data. It should connect accountability under UK GDPR Article 24 with data protection by design and default under Article 25, processor arrangements under Article 28, records under Article 30, and security under Article 32.
Think of a shared office. A sensible workplace doesn't rely on everyone remembering, from goodwill, which files belong in a locked cabinet, which papers can go into recycling and which visitors can enter a restricted room. It sets procedures, assigns responsibility and checks that the procedures work. Personal data needs the same discipline, only with clearer evidence and stronger consequences.
The policy should translate principles into Microsoft 365 decisions:
- Collect: A Dataverse employee table should contain information needed for a defined HR purpose, rather than every field someone might find useful later.
- Store: Sensitive fields and documents should sit behind appropriate Dataverse security roles, Microsoft Entra ID controls and protected SharePoint locations.
- Share: Power Automate flows, Teams channels and Outlook messages should send only the information the recipient needs, using a documented lawful basis.
- Delete: Retention rules, review workflows and deletion or anonymisation processes should remove information when the purpose ends.
The policy isn't the same as a privacy notice. A privacy notice tells employees, applicants or other individuals what the organisation does with their information. A record of processing activities describes processing activities, purposes, categories and recipients. A retention schedule states how long categories are kept. The policy governs the management system that connects these documents to daily work.
HR teams looking for a broader plain-English reference can also review data protection at NotFair, particularly when comparing internal policy wording with the information given to individuals. The important test is consistency. If a privacy notice says a record is deleted when no longer needed, the retention schedule and Dataverse configuration must support that statement.
Core Components Every UK GDPR-Aligned Policy Needs
A policy is easier to test when it has distinct components. The following table maps the essential areas to legal references and Microsoft 365 controls.
| Policy Component | UK GDPR Reference | Dataverse / Microsoft 365 Control |
|---|---|---|
| Scope and definitions | Articles 4, 5 and 24 | Identify employees, applicants, contractors, special category data, environments and connected services |
| Lawful basis | Article 6, with Article 9 where special category data applies | Maintain a lawful basis register linked to HR processes and relevant Dataverse tables |
| Data inventory | Article 30 and accountability expectations | Map Dataverse tables, columns, SharePoint sites, Teams locations, Outlook mailboxes and Power Automate flows |
| Access controls | Articles 5(1)(f), 25 and 32 | Use environment security roles, least privilege, Entra ID groups, MFA and restricted access to sensitive fields |
| Retention and deletion | Article 5(1)(e), storage limitation | Apply documented retention periods, review queues, bulk deletion jobs and anonymisation processes |
| Subject rights workflow | Articles 12 to 22 | Route requests to a controlled case record, search Dataverse and Microsoft 365 sources, and record responses |
| Breach response | Articles 33 and 34 | Preserve audit logs, flow history and access evidence, then escalate through the incident process |
| Third-party processing | Article 28 | Assess processors, maintain agreements, review security evidence and use the Microsoft Service Trust Portal for due diligence |
The scope clause should name more than “HR systems”. It should include the production and test Dataverse environments, SharePoint document libraries, Teams conversations, Outlook messages, integrations and exports. Otherwise, a record can disappear from the inventory because it moved through a connector.
Lawful basis needs a practical owner. HR should explain why it processes absence data or right-to-work evidence, while IT should map where the data travels. A consent field alone won't prove that processing is lawful, especially where the employment relationship affects whether consent is voluntary.
Controls must match the data
Access is not a general permission to browse. An HR manager may need personnel records for their reporting line, while a payroll specialist needs payroll information and a recruitment colleague needs applicant records. Column-level or field-level protections should be considered for sensitive HR attributes, with security roles designed around duties rather than convenience.
The subject rights workflow should identify the person who acknowledges a request, searches each source, checks exemptions and approves the response. The breach section should do the same for alerts, including who preserves logs and who contacts the DPO.
These elements interlock. An inventory without access controls doesn't reduce exposure. A retention schedule without deletion mechanisms doesn't deliver storage limitation. A processor register without due diligence leaves the organisation unable to explain how suppliers protect personal data.
Roles and Responsibilities Across HR, IT and the DPO
Accountability fails when a policy assigns responsibility to “the business”. A mid-market organisation should name the role that owns each decision and the evidence that proves it was completed.
The data controller sits with the organisation, supported by board-level accountability. HR usually owns the employment purpose and record accuracy. IT owns the configuration that enforces access and security. The DPO, where one is required or appointed, provides independent oversight, advises on risk and acts as a key point of contact for escalation and ICO engagement.
| Role | Accountability Area | Daily Duties | Dataverse Touchpoints |
|---|---|---|---|
| Data controller | Purpose, lawful basis and accountability | Approves processing purposes, policy and risk decisions | Owns the configuration outcome, even where IT implements it |
| Data processor | Processing on the controller's documented instructions | Protects data, follows the agreement and reports incidents | May support hosting, integration or managed services |
| Joint controller | Shared determination of purposes and means | Documents the allocation of responsibilities with the other controller | Coordinates access, notices and rights handling across systems |
| HR | Workforce data ownership | Maintains accuracy, defines HR purposes and manages employee processes | Owns table content, business rules and retention requirements |
| IT | Technical enforcement | Assigns roles, manages identity, monitors logs and tests controls | Maintains security roles, Entra ID assignments, audit settings and integrations |
| DPO | Independent monitoring and advice | Reviews DPIAs, escalates risk, advises on rights and liaises with the ICO | Reviews evidence from logs, access reviews and incident records |
| Line manager | Limited operational use | Accesses only information needed for management duties | Uses approved views and role-based permissions |
IT shouldn't decide the lawful basis because it controls the system. HR knows the employment purpose and must document it. At the same time, HR shouldn't approve broad access on the assumption that IT will sort out security later.
The policy should require evidence from both sides. IT might retain records of environment security roles, Entra ID group membership, MFA enforcement, privileged changes and audit logs. HR might retain the lawful basis register, retention decisions, rights-request records and accuracy review evidence. The DPO should be able to inspect both without becoming the person who performs every operational task.
Accountability check: If HR can't explain why a field is collected, and IT can't show who can access it, the policy has an ownership gap.
Retention Schedules and Data Minimisation on Dataverse
Storage limitation means the organisation can justify how long it keeps each category of personal data. ICO guidance expects a formal retention policy with standard periods where possible, regular review, and erasure or anonymisation when information is no longer needed. Personal data shouldn't be held indefinitely “just in case”, as explained in the ICO's guidance on how long personal information should be kept.
For Dataverse, start with purpose, category and trigger. A schedule might record the employee's leaving date, the relevant table, the retention rationale, the review owner and the deletion or anonymisation action. The technical process then needs to reach related records, attachments, audit data and connected Microsoft 365 locations.
Examples require careful approval rather than automatic adoption:
- Personnel files: A business may choose 6 years post-employment where its documented legal and operational assessment supports that period.
- Payroll: A schedule may specify 6 years for HMRC records where the organisation has confirmed the requirement for the relevant record category.
- Right-to-work evidence: A policy may set 2 years after leaving, subject to the organisation's legal assessment and the evidence type.
- Disciplinary notes: Warnings may be retained for 6 to 12 months, while gross misconduct records may require a longer, documented period.
Each figure needs a clear basis, not a copied template. The ICO's storage-limitation approach requires the controller to justify the duration and support erasure or anonymisation when the purpose ends.
Build deletion into the architecture
Dataverse table-level rules can identify records for review, while bulk deletion jobs can remove expired data under controlled conditions. Environment lifecycle pipelines can support movement between development, test and production, but archiving isn't automatically compliant. An archive remains personal data unless the organisation has a lawful reason to keep it and continues to protect it.
Minimisation starts before retention. Don't place national insurance numbers on a general contact table if a restricted payroll or employee table is sufficient. Store right-to-work evidence in a secured document table, and limit disciplinary notes to managers with explicit security roles.
Related data needs a cascade plan. Deleting an employee row may not delete an Outlook message, Teams conversation, SharePoint document or exported spreadsheet. Document retention policy guidance can help HR and IT examine those connected locations rather than treating Dataverse as the whole information estate.
Implementing Your Policy in a Microsoft 365 Environment
A practical rollout for an organisation between 50 and 4,000 employees should combine policy decisions with technical changes. A ninety-day plan gives HR, IT and the DPO a shared sequence without pretending every tenant has the same architecture.
Weeks one to two
Appoint the DPO or responsible person, confirm the controller, and define the scope. HR should list processes such as recruitment, onboarding, absence, performance, payroll and right-to-work checks. IT should map the relevant Dataverse tables, SharePoint HR sites, Teams locations, Outlook mailboxes, connectors and service accounts.
Record the current state before changing permissions. Identify where the same employee information appears more than once, which flows export records, and whether test environments contain live personal data.
Weeks three to six
HR drafts the policy, lawful basis register and retention schedule in plain English. IT redesigns the access model using Entra ID security groups, Dataverse security roles, conditional access and MFA. The DPO reviews the proposed controls and identifies processing that needs a DPIA.
The least-privilege model should be tested with real roles. A payroll user, HR adviser, line manager and system administrator shouldn't automatically see the same views or documents. Encryption at rest, recoverable backups and timely restoration also belong in the security design, not just the incident plan.
Weeks seven to ten
Configure Dataverse bulk deletion jobs and controlled review queues. Apply Microsoft Purview retention labels where they fit SharePoint, Outlook and other Microsoft 365 content, and document mailbox holds so legitimate investigations or disputes aren't disrupted by routine deletion.
IT should also define how Customer Lockbox requests are handled where the organisation's licensing and service configuration support that control. Integration accounts deserve specific attention because they may bypass ordinary interactive access patterns and can undermine conditional access assumptions.
Weeks eleven to twelve
Train HR, managers, administrators and service desk staff. Run a tabletop breach exercise, test a subject access request search and obtain DPO sign-off on the DPIA and policy evidence. The final launch should include a named owner for future reviews, not just a publication date.
This policy documentation resource is useful when turning decisions into controlled records, version history and review evidence.
A short technical demonstration can also help non-technical stakeholders understand how policy controls operate in Microsoft 365.
Common Misconceptions Around AI Processing and New UK Rules
A UK GDPR template written before the Data (Use and Access) Act 2025 may not answer the questions HR and IT now face. The DUAA received Royal Assent on 19 June 2025, and changes key areas including complaints handling, subject access, cookies, automated decisions, some legitimate-interest processing and transfer rules, as described by the ICO's DUAA overview.
The first misconception is that a vendor hosting an AI model makes the organisation's responsibility disappear. It doesn't. If a Dataverse process sends CVs to an AI service for parsing or scoring, the organisation still needs to identify the purpose, lawful basis, processor arrangement, security measures, retention behaviour and rights implications.
The second misconception is that every AI feature is merely administrative. CV parsing can influence shortlisting. Sentiment analysis of interview recordings can affect an assessment. Facial-recognition clocking can create biometric and employment risks. The policy should state when human review is required, how a decision is challenged, what data the model receives and how outputs are recorded.
The DUAA changes automated decision-making treatment, while ICO guidance remains under development, with a broader guidance refresh due in summer 2026, according to the ICO's guidance plans. That makes documented assessments particularly important. A policy should include an AI register, a review of Article 22 implications, safeguards for affected workers, a DPIA where appropriate and a route for human intervention.
The Data (Use and Access) Act 2025 should be treated as a policy update, not a footnote. Review automated decision wording, legitimate-interest assessments, subject access procedures and supplier contracts together. Don't assume a generic consent paragraph will cover an AI-enabled HR workflow.
The financial exposure also matters. The UK enforcement ceiling for serious breaches is up to £17.5 million or 4% of global turnover, whichever is greater, under the UK GDPR and Data Protection Act framework, as referenced in ICO annual reporting. The ceiling isn't a prediction of an outcome, but it reinforces why high-risk automation needs governance before deployment.
Templates, Checklists and Audit Mechanisms to Keep You Honest
A policy earns credibility when the organisation can show how it operates in practice. Start with a Dataverse retention schedule mapped to tables, columns, purposes, triggers, owners and disposal actions. For example, an HR record should show why it exists, who owns its retention decision and what happens when that period ends. Add a Microsoft Purview sensitivity-label matrix for personnel files, payroll information, recruitment records and restricted documents.
IT should maintain an Entra ID role-review template covering group membership, privileged access, approval, reviewer and completion evidence. HR and the DPO can use a quarterly audit script aligned with ICO expectations, checking lawful-basis records, consent records where relevant, subject access responses, retention exceptions and breach-log entries.
A RACI chart assigns each evidence point to a named role. HR may own policy wording and record accuracy, IT may provide configuration and access evidence, and the DPO may conduct independent review and escalate concerns. Power Automate can issue reminders, conditional-access alerts can route to the DPO mailbox, and controlled Dataverse business rules can trigger review or deletion jobs. These controls turn policy requirements into repeatable tasks inside Microsoft 365.
Staff access should end with an attestation. Ask each person to confirm that they have read the HR data policy, retain the completion record and follow up on exceptions. During an internal review or ICO inquiry, that record connects the written policy with evidence of staff awareness.
DynamicsHub.co.uk supports HR transformation built around an organisation's business. Hubdrive's HR Management for Microsoft Dynamics 365 is a hire-to-retire solution built natively on Dataverse, with UK-focused retention, Right to Work and security processes that can align with a data protection policy. Organisations working through these steps can request a consultation with DynamicsHub to align their Dataverse HR environment with the framework described above, or use the contact page to make an enquiry.
