A UK HR director opens Microsoft 365, looks at a folder full of passports, right to work scans, offer letters and payroll exports, and asks the same question every month, is this safe? The honest answer is never a vendor brochure and never a vague promise that Microsoft “handles security”. In a cloud setup, cloud data security is the mix of identity control, encryption, retention, logging and access governance that keeps personal data usable for the business and defensible under UK law.
For UK teams, that legal angle matters as much as the technical one. The introduction of the UK GDPR on 31 December 2020 embedded enforceable data-protection duties into UK law after Brexit, and the ICO can issue fines of up to £17.5 million or 4% of annual global turnover, whichever is higher under that framework (Orca Security report). That is why cloud security is not just an IT preference, it's part of how HR, compliance and operations prove accountability.
A useful starting point is to separate what Microsoft secures from what you still control. Microsoft secures the underlying service, but the organisation still owns the data, the access model and the retention rules. That's why a practical cloud data protection guide is only useful if it helps you answer who can read, export and delete the records in your tenant.
For HR teams, that means employee files, candidate records, payroll exports, and right-to-work evidence need controls that survive day-to-day work, not just audit season. If you want a deeper governance lens, the information governance resources are a good place to compare policy with what happens in the tenant.
What Cloud Data Security Actually Means for UK Teams
Cloud data security means protecting data while it lives in someone else's infrastructure, while people still need to use it every day. In Microsoft 365 terms, that's the difference between a file being stored in SharePoint or a record sitting in Dataverse and whether the right people can reach it, edit it, share it or delete it at the right time.
Shared responsibility, not shared assumptions
The provider secures the platform. Your organisation still has to secure identities, permissions, labels, retention and audit trails. That matters because the ICO treats personal data in cloud platforms as remaining under the controller's responsibility, so a cloud tenant doesn't reduce accountability, it changes where the controls live (Wiz cloud data security guidance).
For a UK HR team, the practical test is simple. Can a payroll manager open only payroll data, can a recruiter see only candidate records, and can an admin prove why a file was retained or deleted? If the answer is unclear, the problem isn't the cloud, it's governance.
Practical rule: if a control depends on someone remembering to do the right thing manually, it will fail at the exact moment you need it most.
Cloud data security also covers confidentiality, integrity and availability. Confidentiality is about stopping the wrong person reading the data. Integrity is about stopping unauthorised changes. Availability is about making sure the business can still recover records, especially when ransomware or accidental deletion hits.
Why the HR use case is the best test
HR data is a strong stress test because it mixes sensitive personal information, legal retention needs and wide collaboration. A right to work scan, for example, may need controlled access for onboarding, but not indefinite retention in multiple shared sites. A candidate CV may need to be accessible to hiring managers, but not casually forwarded across Teams chats.
That's why cloud data security is really a discipline of minimum exposure. The aim isn't to make data unreachable. It's to make the useful path the safe path, and to ensure every exception has a reason, a reviewer and a deletion date.
The Threats Hiding Inside a Cloud Tenant
Most cloud breaches don't begin with a Hollywood-style exploit. They begin with a user, a setting or a token that shouldn't have had the access it did. In Microsoft 365 and Dataverse environments, the weak point is usually identity or configuration, then the incident spreads through legitimate functionality.
Identity compromise is still the front door
Phishing, password reuse and session theft remain the simplest way into a tenant. If an attacker gets a working identity, they often don't need to “hack” anything else, they just use the permissions that are already there. In practice, that means mail forwarding rules appear, unfamiliar sign-ins show up, or a user suddenly starts exporting more data than their role should allow.
Permission sprawl makes a small problem larger
The next failure mode is over-access. Shared service accounts, guest users, inherited admin roles and old project groups create a maze where nobody can clearly say who can see what. That's especially dangerous in HR systems because one privileged account can expose records across payroll, onboarding, sickness absence and disciplinary workflows in one go.
Configuration drift and apps create quiet exposure
SharePoint and Dataverse both suffer when defaults are left alone. A site gets made public for “temporary” collaboration, a table inherits wider access than intended, or a third-party app connector is granted broad permissions because the business needed speed. In Microsoft 365, those small shortcuts often look harmless until they're combined with an already-compromised identity.
If you see mailbox forwarding you didn't expect, a new guest with broad site access, or a service principal nobody can explain, treat it as a control failure first and an investigation second.
Ransomware also matters in cloud environments, but not always in the way people expect. The threat isn't just encryption of files, it's attackers using legitimate admin pathways to delete, lock or export cloud content faster than teams can react. That's why cloud tenant defence has to focus on who can act, what they can change and how quickly you can reverse it.
The Seven Control Families You Need in Place
A decent cloud security posture doesn't come from one product. It comes from seven control families that reinforce each other, because each one covers a different failure mode in the tenant.
Identity, encryption and governance
Identity and access management decides who can get in and what they can touch. Encryption and key management reduces the value of stolen data, but only if key access is also tightly controlled. Governance and compliance keeps the tenant aligned with retention, audit and legal obligations instead of letting policy live in a document no one opens.
Monitoring, recovery and application control
Security operations and monitoring is where you notice the abnormal forwarding rule, the impossible travel sign-in or the sudden spike in data exports. Backup and recovery gives you a way back after deletion, ransomware or tenant misadventure. Application security matters because a Power Platform app, a connector or a custom integration can create its own exposed path to data if it's not reviewed.
Network and data loss controls still matter
Network and perimeter security helps reduce exposure in transit and constrains how services talk to each other. Data loss prevention controls what can be copied, shared or pushed outside approved boundaries. In Microsoft 365, these families don't replace each other, they create a chain where one weak link can undo the rest.
| Control family | Where to focus in a Microsoft tenant | What good looks like |
|---|---|---|
| Identity and access management | Entra ID, role assignments, guest access | Least privilege, strong authentication, reviewed roles |
| Encryption and key management | Microsoft 365 and app-level encryption settings | Sensitive data is protected in transit and at rest |
| Network and perimeter security | Conditional access and service access rules | Only approved devices, locations and sessions reach data |
| Data loss prevention | SharePoint, Teams, Outlook, Power Platform | Sensitive records don’t leave approved channels casually |
| Security operations and monitoring | Audit logs, sign-in logs, alerting | Abnormal behaviour is visible and investigated quickly |
| Governance and compliance | Retention, labels, legal holds | Data is kept only as long as needed and can be proved |
| Application security | Dataverse apps, connectors, third-party integrations | Access is reviewed before apps go live |
Microsoft's own guidance on cloud security aligns with this layered approach, especially where Zero Trust, continuous monitoring, automated policy enforcement and backup/disaster recovery are concerned (cloud security overview). The useful lesson is simple, monitoring without response is decoration, and encryption without identity control is theatre.
Microsoft 365, Dataverse and Entra ID Settings That Matter
The fastest security gains usually come from tenant settings, not new projects. In a mid-market HR environment, the right changes are mostly already available in Entra ID, Dataverse and SharePoint, which means the pertinent question is whether they're switched on and governed properly.
| Control family | Where to look in Microsoft 365 | What good looks like |
|---|---|---|
| Identity and access management | Entra ID Conditional Access, role assignments, Privileged Identity Management | Strong sign-in checks, no standing excess privilege, reviews for admins |
| Encryption and key management | Service encryption settings, sensitivity labels | Sensitive documents are protected and handled consistently |
| Data governance and retention | SharePoint retention, Microsoft Purview, Dataverse retention policies | Employee and candidate data has defined deletion or archive rules |
| Logging and monitoring | Entra sign-in logs, audit logs, alert policies | Unusual access is visible and investigated |
| Backup and recovery | Microsoft 365 backup strategy, restore testing | Data can be recovered under ransomware or accidental deletion |
| Application control | Dataverse security roles, column-level security, app permissions | Users only see the fields and records they need |
| Collaboration control | SharePoint external sharing, guest access settings, Customer Lockbox | External sharing is intentional, support access is governed |
Where to tighten first
Entra ID Conditional Access should do more than allow sign-in from any device that passes a password check. Phishing-resistant MFA and stricter session controls make more sense for HR data than broad trust in legacy authentication. If an admin account can still do everything from anywhere, the tenant is too open.
Privileged Identity Management helps reduce standing privilege, which is one of the cleanest ways to cut exposure without slowing operations. In practice, that means admin roles are activated only when needed and reviewed rather than left permanently live.
Dataverse and SharePoint need separate treatment
Dataverse security roles and column-level security are critical when HR data sits in a model-driven app. You can't assume the app layer is enough, because table permissions and field permissions decide what the user can really see.
SharePoint needs just as much discipline. External sharing defaults, guest access and document links should be set for the least open working pattern, not the easiest one. Sensitivity labelling is essential for files containing Right to Work evidence, because those documents are often copied into multiple workflows and need consistent handling across the tenant.
For organisations looking at HR platform design, tools such as Hubdrive's Dataverse-based HR setup become relevant, because the implementation choice affects how neatly security roles, retention and evidence handling can be aligned inside the customer tenant.
Support access shouldn't be casual
Customer Lockbox matters because support access is still access. If a support engineer needs to enter your tenant, that access should be visible, approved and time-bound. That's not paranoia, it's basic control of sensitive personnel records.
If you want a broader identity lens, the identity management guidance is useful for mapping admin responsibility to actual tenant controls.
GDPR, Right to Work and Breach Reporting in Practice
Technical controls only become meaningful when they support a legal duty. In UK HR work, that means GDPR accountability, retention discipline and breach response all have to line up with what the tenant can prove.
GDPR accountability lives in the logs
If employee data sits in Dataverse, the controller still needs to show why the data exists, who can access it and how long it will be kept. That makes audit logging more than an IT feature. It becomes evidence that the organisation used the data for a lawful purpose and controlled it throughout its lifecycle.
The same logic applies to deletion requests, retention reviews and access changes. A record of the decision matters because GDPR accountability is not just about having a policy, it's about being able to show that the policy was followed.
Right to Work evidence needs tighter handling than general HR files
Right to Work documents need a storage model that respects both access restriction and deletion timing. They shouldn't sit indefinitely in loose shared folders or in more than one uncontrolled repository. The Home Office and GDPR expectations push in the same direction, keep the evidence available for the right period, then remove it cleanly.
If you need a practical external reference on deletion workflows, how ContentRemoval.com handles GDPR take-downs is worth reading because it shows how removal requests translate into operational process, not just policy language.
Breach reporting starts before the incident
The ICO's breach reporting expectations are built around fast detection and assessment, not guesswork after the fact. That means your team needs to know who triages an alert, who decides whether personal data is involved and who owns the notification path.
Useful rule: if no one can explain which log, mailbox or admin console proves what happened, the breach process is already behind.
A good retention policy also helps reduce the blast radius of any incident. If less sensitive data is stored, less sensitive data can be exposed. That is why GDPR, right to work handling and breach reporting all depend on the same practical controls, especially retention schedules, access governance and logging.
For a policy template mindset, the GDPR compliance checklist is a helpful cross-check against what your tenant is already configured to do.
A Practical Checklist for HR and IT Teams
The fastest way to make cloud data security real is to split ownership clearly. HR owns the data lifecycle. IT owns the tenant controls. Both teams need evidence that the job was done.
HR ownership
- Inventory employee and candidate data in SharePoint, Dataverse and shared mailboxes, then confirm where Right to Work evidence is stored.
- Review retention rules for employee files, leavers, applicants and contractor records, then confirm deletion dates are still appropriate.
- Check access needs for sensitive HR folders every quarter, especially where payroll, absence and disciplinary records overlap.
- Confirm Right to Work handling for new starters and leavers, including where documents are saved and when they are removed.
- Keep a record of lawful basis and processing purpose for HR records so GDPR accountability isn't left to memory.
IT ownership
- Verify Conditional Access coverage for all HR and admin roles, and remove legacy sign-in paths where possible.
- Check MFA enforcement for privileged users, with special attention to any account that can export, delete or share HR data.
- Review Dataverse roles and column-level security monthly for HR apps and connected services.
- Test restore capability on Microsoft 365 and Dataverse content so backup claims are backed by an actual recovery exercise.
- Inspect audit and sign-in logs for unusual access, forwarding rules, guest activity and privileged role activations.
- Maintain a breach runbook that names who assesses, who escalates and who notifies, then rehearse it.
Shared cadence and evidence
Use a monthly control review for access, a quarterly review for retention and a twice-yearly recovery test. Keep screenshots, approval notes and log exports in one governance folder so the next audit isn't a scavenger hunt. That evidence folder should be boring, consistent and easy to read.
Common Cloud Security Failures in UK Setups
The biggest mistake is treating compliance as proof of security. A tenant can be well documented and still expose too much data because roles are broad, guest access is loose, or old sharing links are still active. A policy on paper does nothing when a compromised account can browse a SharePoint site.
Encryption gets overstated in the same way. It matters, but it does not fix over-access, misconfigured sharing, or weak admin control. That gap is visible in current cloud-security research, where 54% of cloud data is now classified as sensitive, up from 47% the year before, yet only 8% of organisations encrypt 80% or more of their cloud data (Thales cloud-security research). The point is not that encryption is pointless, it is that encryption coverage on its own rarely matches the actual shape of the risk.
MFA gets claimed too early as well. Teams often say it is in place, then find that privileged roles, service accounts, or legacy integrations still bypass the intended controls. The only reliable answer is a role-by-role and sign-in-path review, not a global yes or no.
Backups fail for the same reason. Many teams assume restore works because backups exist, then discover the recovery path has never been tested under pressure. If ransomware deletes cloud files or corrupts a tenant workflow, the measure is simple, can the business restore usable data fast enough to keep operating?
The cleaner next step is to inspect the tenant the way an attacker and an auditor would, by identity, sharing, retention, and recovery. DynamicsHub helps UK organisations implement and tune Microsoft 365, Dataverse and Entra ID for HR use cases, including secure evidence handling and tenant governance.
