Your SharePoint sites are probably carrying more risk than anyone wants to admit.
HR folders hold CVs for candidates who were never hired. Line managers keep copies of disciplinary notes in Teams chats and personal drives. Finance stores old contract packs because nobody is sure whether they're still needed. IT backs up everything because deleting the wrong thing feels more dangerous than keeping too much. That pattern is common, and it creates a quiet governance problem.
A document retention policy fixes that by replacing habit with rules. It tells the business what to keep, why it must be kept, where it should live, when the retention clock starts, and what must happen when the period ends. For HR Directors, that matters because employee data sits at the centre of several competing pressures. You need records for operational continuity, for legal defence, for payroll and audit support, and for investigations. At the same time, UK GDPR requires personal data not to be kept for longer than necessary.
The challenge isn't understanding the principle. It's turning that principle into something your teams can follow in Microsoft 365, Dataverse, and SharePoint without creating a manual admin burden.
The Hidden Risks in Your Digital Filing Cabinets
Most organisations don't have one filing system. They have five or six.
There's SharePoint for team documents, Outlook for approvals and attachments, OneDrive for working files, Teams for conversations, line-of-business systems for structured records, and local exports sitting in downloads folders because someone needed “a quick copy”. HR data spreads even faster because hiring, onboarding, employee relations, payroll support, and offboarding all involve documents moving between people and systems.
What goes wrong when everything is kept
The biggest mistake is assuming that indefinite retention is the safe option. It feels cautious, but it usually creates more exposure.
When a subject access request arrives, the business has to search more locations. When a grievance turns into a dispute, nobody is confident which file is the authoritative one. When auditors ask how long records are kept, policy owners often point to a document that exists on paper but isn't reflected in the systems people use.
That gap matters because poor retention control creates several operational headaches:
- Search becomes unreliable. Staff spend time hunting through duplicate folders, old email chains, and inconsistent naming conventions.
- Sensitive data lingers. Ex-employee files, recruitment notes, and outdated personal information remain accessible long after the original purpose has ended.
- Disposal becomes risky. Teams delete ad hoc because there's no trusted rulebook, or they delete nothing because they fear getting it wrong.
- Audit defence weakens. It's hard to prove a disposal decision was routine and policy-led if the process depends on manual judgement.
Over-retention rarely looks dramatic day to day. It shows up when HR needs one clean record set and finds four conflicting versions instead.
Why HR and IT both need to care
This isn't an IT housekeeping issue dressed up as compliance. It sits right across HR, legal, compliance, and technology.
HR owns many of the most sensitive records in the business. IT owns the platforms where those records accumulate. Legal and compliance teams need confidence that the business can preserve what matters and dispose of what doesn't. If one part of that chain is weak, the whole retention model falls apart.
A good document retention policy gives everyone the same operating model. It reduces clutter, sharpens accountability, and makes disposal defensible rather than improvised.
What Is a Document Retention Policy
A document retention policy is the formal rulebook for how your organisation manages information from creation through to deletion or anonymisation. It isn't just a spreadsheet of retention periods. It's the operating design behind your data lifecycle.
Think of it as a blueprint. A blueprint doesn't just say how many rooms a building has. It defines structure, responsibilities, access points, and what supports what. A retention policy does the same for information. It sets the framework so the business can keep the right records for the right reasons, in the right place, for the right amount of time.
The four parts that matter in practice
A policy that works usually contains four connected elements.
| Element | What it does | Why it matters |
|---|---|---|
| Scope | Defines which records, systems, and teams are covered | Stops people assuming the policy only applies to formal documents |
| Retention schedule | Assigns a rule to each record class | Turns broad principles into usable decisions |
| Roles and ownership | States who approves, applies, reviews, and pauses disposal | Prevents HR, IT, and legal from passing accountability around |
| Disposal process | Defines deletion, anonymisation, evidence, and exceptions | Makes destruction controlled and auditable |
Why disposal belongs in the policy, not as an afterthought
Many organisations write the “keep” part and stay vague on the “delete” part. That's where policies become weak.
A compliant policy needs to support data minimisation and secure disposal. The ICO's guidance under UK GDPR requires personal data to be kept no longer than necessary and then erased or anonymised. Non-compliance can lead to administrative fines up to £17.5 million or 4% of global annual turnover, whichever is higher, as noted in this guidance on building a comprehensive document retention policy.
That's why “keep everything just in case” is not a neutral choice. It increases the amount of personal data the organisation has to protect, search, review, and justify.
Practical rule: If your policy can't answer “what happens at the end of the retention period?”, it isn't finished.
What a strong policy looks like day to day
In practice, a good policy should answer questions staff ask in plain language:
- What counts as a record? Final contracts, signed letters, employee case files, payroll support, and board approvals may all need different handling.
- What starts the clock? Contract expiry, termination of employment, end of an accounting period, or case closure.
- What overrides normal deletion? Litigation, investigation, grievance, or regulatory inquiry.
- How is disposal evidenced? Logs, approvals, and automated audit trails.
That's the difference between a policy that satisfies an internal template and one that governs the way people work.
Understanding UK Legal and Compliance Requirements
An HR director usually feels the problem first when a subject access request, tribunal threat, or HMRC query lands and nobody can say, with confidence, what should still exist, what should have been deleted, and who approved either decision. In UK organisations, retention policy failures rarely start as legal theory. They show up as messy SharePoint folders, duplicate employee files, old mailbox content, and Dataverse records with no clear review date.
UK GDPR and the Data Protection Act 2018
UK GDPR and the Data Protection Act 2018 set the basic rule for HR data. Keep personal data only for as long as the organisation can justify the purpose. After that, delete it, anonymise it, or retain it under a clearly documented legal basis. The ICO frames this through the storage limitation principle, and that principle matters most in HR because employee data accumulates quickly across recruitment, onboarding, case management, payroll support, and offboarding.
The legal point is straightforward. The operational point is harder. A retention rule has to answer three practical questions. Why is this data still being kept? What event starts the retention period? What action happens at the end?
That is where many Microsoft estates need tightening. SharePoint libraries often hold final signed documents alongside drafts. Exchange mailboxes contain HR decisions that were never filed properly. Dataverse tables may support a live HR process, but nobody has defined when a closed case should move into a retention period or when it should be purged. If the legal basis is not mapped to the system that holds the record, staff default to keeping everything.
For a broader operational checklist, this GDPR compliance checklist for UK organisations is a useful companion when you're aligning retention with wider data governance.
The video below gives a helpful overview of the compliance context.
Why six years appears so often
Six years appears repeatedly in UK retention schedules because several legal and tax obligations cluster around that timeframe. The Limitation Act 1980 is a major reason. Many simple contract claims are subject to a six-year limitation period, while deeds commonly run longer. HMRC record-keeping expectations also push many finance and employment-related records into multi-year retention.
That does not mean every HR document should default to six years.
It means six years is often a legal anchor point that needs context. A signed employment contract, payroll support, right-to-work evidence, and a grievance outcome may all involve different trigger dates, different risk profiles, and different storage locations. In practice, the retention period is only half the answer. The trigger event matters just as much. Termination of employment, end of the tax year, closure of a case, or expiry of a contract can each start the clock.
A simple reference point looks like this:
| Record type | Common legal driver |
|---|---|
| Simple contracts | 6 years |
| Deeds | 12 years |
| Tax-related business records | At least 6 years |
These are starting points, not universal rules.
Where organisations usually slip
The biggest weakness I see is not ignorance of the law. It is treating legal retention periods as if they can be pasted directly into technology without any design work. They cannot.
An effective policy has to reflect the fact that UK retention decisions sit between competing duties. UK GDPR pushes against indefinite storage. Employment, tax, and contractual risk can require records to be kept for years. Litigation, grievance escalation, whistleblowing concerns, or regulatory investigation can pause normal disposal altogether. The policy needs clear preservation triggers, review points, and named decision-makers.
That is why generic policy language causes trouble. “Keep for six years” is incomplete if nobody knows six years from what. “Delete when no longer needed” is equally weak if no one owns that judgment. In Microsoft 365, those gaps become configuration problems. Retention labels cannot be applied consistently if HR has not defined the record category. SharePoint cannot dispose of content defensibly if sites mix transient working files with formal records. Dataverse cannot support lifecycle automation if the business process does not capture closure dates or legal hold status.
A better approach is to map legal theory to the actual content lifecycle. The discipline of planning content from creation to retirement is useful here because it forces HR, IT, and compliance teams to decide where a record is created, when it becomes authoritative, how long it must stay accessible, and what should happen if disposal needs to be suspended.
If the policy lists retention periods but does not define the trigger event, system owner, and end-of-life action, staff will apply it differently and Microsoft 365 will enforce it inconsistently.
How to Design a Practical Retention Schedule
A retention schedule earns its keep on a difficult day. An employee raises a grievance about events from three years ago. A manager has kept copies of documents in SharePoint, Outlook, and a local folder. HR needs to know which version is the record, how long it stays, and whether disposal must stop. If the schedule cannot answer those questions quickly, it will not hold up in practice.
Start with systems and record owners
Useful schedules are built from the way records are created and managed. For a UK HR team working in Microsoft technology, that usually means identifying records across SharePoint libraries, Teams-connected sites, Exchange mailboxes, HR application exports, and Dataverse tables. It also means finding the awkward places that are easy to miss, such as recruiter spreadsheets, manager-held notes, downloaded right-to-work files, and copies of signed documents stored outside the main HR repository.
This is also the point to decide which system holds the authoritative record. If the signed contract is stored in SharePoint but key employment dates sit in Dataverse, the schedule needs to reflect both. The legal rule may be simple. The technical implementation rarely is.
A useful way to frame the exercise is planning content from creation to retirement. That approach works well because it connects retention to the full lifecycle, not just the final disposal decision.
Define record classes that map to business reality
Record classes should be broad enough for staff to recognise and precise enough for Microsoft 365 to apply consistently. In HR, I usually see better results from starting with a manageable set of categories that match operational processes, then refining only where the legal position or risk profile differs.
Examples include:
- Employee records such as contracts, variation letters, disciplinary records, and leaver documents
- Recruitment records such as applications, interview notes, checks, and offer paperwork
- Payroll and benefits records tied to pay cycles and statutory reporting
- Health and safety or occupational health records where retention may depend on the nature of the incident or assessment
- Commercial and supplier records where HR works with external providers
- Governance and policy records such as approvals, signed policies, and board papers
If you run HR processes on the Microsoft stack, this often aligns with how tables, document libraries, and case records are already structured across the Microsoft Power Platform ecosystem. That alignment matters later when IT turns the schedule into labels, rules, and automated retention actions.
Set trigger events with precision
The trigger event is what makes a retention period usable. "Keep for six years" is not a schedule. "Keep for six years after employment ends" is.
For HR and legal teams, trigger design is usually the point where policy quality rises or falls. The start date needs to match the actual event that closes the record. In Microsoft terms, it should also match a date your systems can capture reliably.
| Record class | Better trigger example |
|---|---|
| Employee file | End of employment |
| Recruitment file | End of recruitment process |
| Contract record | Expiry or termination of contract |
| Tax records | End of relevant accounting period |
| Matter file under dispute | Matter closure, unless legal hold applies |
Where possible, define triggers that can be recorded automatically. A termination date in Dataverse, a contract end date in a structured field, or a case closure status in an HR app is far easier to govern than asking managers to make ad hoc judgments from folder contents.
Design for legal holds and edge cases at the outset
UK retention rules overlap. GDPR pushes against keeping personal data for longer than necessary. The Limitation Act, employment claims, tax requirements, and sector-specific duties may require longer retention. A practical schedule deals with that tension directly instead of hiding it behind vague wording.
The cleanest approach is to add decision points into the schedule itself. Three columns make a big difference:
- Review owner
- Hold or preservation override
- Disposal action
That gives HR and IT a controlled way to pause deletion when tribunal proceedings, whistleblowing concerns, investigations, or regulatory scrutiny are in play. It also gives Microsoft administrators something they can translate into policy logic rather than relying on emails and memory.
A good retention schedule does two jobs at once. It tells staff the normal rule, and it tells administrators what must change when disposal is no longer safe.
Keep it readable enough to enforce
Schedules often fail because they are drafted for lawyers and handed to operational teams. Staff need plain labels and clear categories. System owners need fields, dates, and outcomes they can configure. Both audiences matter.
If a category name is too subtle for a line manager to understand, it will be misapplied. If two categories have different retention periods but no one can explain the legal reason for the difference, simplify them. If one category mixes working drafts, case correspondence, and signed outcomes, split it before automation starts.
The best schedules are short enough to use, specific enough to defend, and structured enough for Microsoft 365, SharePoint, and Dataverse to enforce consistently.
Automating Retention with Microsoft 365
A document retention policy written in Word or PDF is only a statement of intent. Compliance becomes real when the rules are enforced in the systems people use every day.
For most Microsoft-based organisations, that means using Microsoft Purview, SharePoint, Exchange Online, Teams, and where appropriate, Dataverse to apply retention consistently across documents, email, collaboration content, and business data.
Where policy meets platform
Microsoft 365 gives you two broad control models.
The first is broad application at location level, such as a SharePoint site, Teams location, or mailbox. That can work for simple content estates. The second is document-level control using retention labels, which is often the better fit when HR records, payroll material, legal holds, and operational documents coexist in the same environment.
The key technical rule is this. When content is subject to multiple retention settings, the longest retention period wins. Microsoft also notes that item-level retention labels are required when you need per-document control rather than broad location-level settings, as set out in the Microsoft guidance on retention in Microsoft Purview.
That matters more than many teams realise. If you apply overlapping labels badly, you can create a system that retains content far longer than intended, or one that preserves broad containers when only a subset should remain.
A practical Microsoft design pattern
For HR and IT leaders, a sensible pattern usually looks like this:
- Use record classes from the retention schedule as the basis for labels or policy rules.
- Apply triggers at source where possible, such as employee status changes in the HR system.
- Separate working documents from formal records so draft material doesn't inherit the same lifecycle as final records.
- Log disposal actions so deletion is evidential, not invisible.
- Build hold capability so disputes and investigations can pause routine disposal.
Dataverse demonstrates its value. If the employee master record sits in Dataverse, business events such as hiring, role change, or termination can drive downstream retention logic more reliably than asking users to remember manual steps.
For organisations extending governance across apps and workflows, this overview of what Microsoft Power Platform is and how it fits together helps frame where Dataverse, Power Automate, and Microsoft 365 controls intersect.
What works and what doesn't
What works is designing retention from the record outward. Start with the record class, trigger, owner, and exception path, then configure Purview and related tools to match.
What doesn't work is trying to solve everything with one blanket policy. HR data rarely lives neatly in one place, and broad retention settings alone can't handle the nuance of leavers, ongoing cases, or mixed-content sites.
The strongest Microsoft retention deployments are boring by design. Users don't have to remember the policy because the platform does the repetitive work for them.
Assigning Roles Auditing and Managing Risk
Retention fails when everyone assumes someone else owns it.
HR often assumes IT controls deletion. IT assumes legal defines the rules. Legal assumes records are already classified. In reality, a working document retention policy needs shared ownership with very clear boundaries.
Who should own what
A practical operating model usually looks like this:
- HR owns record meaning. HR decides what belongs in an employee file, what counts as recruitment data, and when a case is closed.
- Legal or compliance owns interpretation. They validate retention periods, preservation rules, and legal hold criteria.
- IT owns technical enforcement. IT configures Microsoft Purview, SharePoint permissions, audit trails, and disposal controls.
- Department managers own behaviour. They make sure staff use the right locations and don't bypass the system with private copies.
That division matters because retention is both a governance issue and a platform issue. If you separate those too sharply, the policy becomes either legally sound but operationally useless, or technically elegant but legally weak.
What to audit regularly
A retention policy isn't finished when it's approved. It needs periodic testing.
Use audits to answer practical questions:
| Audit question | What you’re checking |
|---|---|
| Are records stored in approved locations? | Whether staff are using SharePoint, Teams, and HR systems as intended |
| Do retention triggers work? | Whether events like termination or contract end actually start the clock |
| Are holds being applied and released correctly? | Whether preservation is controlled during disputes |
| Is disposal evidenced? | Whether the organisation can prove what was deleted, when, and under which rule |
A formal review should also sit alongside wider privacy governance. If you're processing sensitive employee data or redesigning how records move across systems, a data protection impact assessment process often helps expose retention risks before they become live issues.
Keep the governance lightweight but real
The strongest programmes don't rely on giant committees. They rely on named owners, review cycles, and evidence.
A simple quarterly review of exceptions, disposal logs, and new record types usually delivers more value than an annual policy meeting where nobody looks at the systems. If the business has changed, the retention model must change with it.
Your Path to Compliant HR Transformation
A good document retention policy does two jobs at once. It protects the organisation legally, and it removes everyday friction from HR and IT operations.
The legal side is clear enough. You need defined retention periods, documented triggers, secure disposal, and a way to pause deletion when matters are under dispute. The operational side is where many organisations gain the biggest benefit. Teams find records faster, duplicate storage drops, and nobody has to guess whether an old employee file should still exist.
The shift happens when policy moves into the Microsoft tools your business already uses. SharePoint, Microsoft Purview, Teams, Outlook, and Dataverse can support a retention model that is consistent, auditable, and far less dependent on manual effort.
At DynamicsHub.co.uk, we believe in 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. When compliance controls sit inside the same Microsoft ecosystem your teams already use, retention becomes part of normal operations rather than a separate admin exercise.
DynamicsHub helps UK organisations design and implement HR and compliance solutions in Microsoft 365, Dataverse, and Dynamics 365. If you want a practical retention strategy that is effective in practice, visit DynamicsHub, phone 01522 508096 today, or send us a message.
