An HR director is asked to evidence a Right to Work check carried out three years ago. The document exists, but the people involved have moved roles, the original email thread is difficult to locate, and nobody can confidently explain who approved the case or who accessed the evidence afterwards. The pressure comes from the request, but the problem is the missing chain of events.
A properly designed audit trail in Dynamics 365 and Dataverse gives the organisation a clearer answer. It can show who uploaded a document, who viewed or changed the related record, who approved the case, and when each action occurred. That turns a historic HR process into evidence that another person can review, rather than a reconstruction based on memory, emails, and shared-drive folders.
Audit logs only help when they're configured around real accountability questions. The important issue isn't whether your system stores logs. It's whether the right events are captured, protected from alteration, retained for a defensible period, reviewed by the right people, and presented in a form HR can understand.
When an Auditor Knocks and Your Logs Tell the Story
The request arrives at an inconvenient time. An auditor wants evidence of a Right to Work check from several years ago, or a former employee submits a Subject Access Request and asks what happened to their personal information. The HR team finds the employee record and the uploaded document, but the original HR Business Partner has left, the line manager has changed, and the approval conversation sits across old emails and a shared folder.
A working audit control starts with the business process, not the technology. For a Right to Work case, define the events that must be reconstructable:
- Evidence received: who uploaded the document and when.
- Evidence viewed: which authorised users accessed it.
- Decision recorded: who changed the case status or completed the check.
- Approval completed: who approved the outcome and when.
- Later activity: whether anyone exported, altered, reassigned, or deleted related information.
In Dynamics 365, the record and its audit history can be reviewed together when the organisation has enabled the relevant auditing and configured the HR process consistently. The result should identify the actor, action, affected record, timestamp, and relevant before-and-after values. For a compliance lead, that's the difference between saying, “The check was done,” and showing how the organisation knows.
Practical rule: A document proves that evidence existed. An audit trail helps prove how people handled that evidence.
Memory isn't a control. An email can show that someone sent an instruction, but it may not show who opened the document, whether the case status changed afterwards, or whether a service account updated the record through an integration. A shared drive can preserve a file while leaving the access history incomplete or disconnected from the employee's HR case.
Treat audit logs as part of the process design. Decide what a reviewer would need to know, enable the events that answer those questions, restrict administrative access, and test the result with a realistic historic case. The remaining sections apply that approach to Dynamics 365, Dataverse, Microsoft 365, retention, review, and incident response.
What Audit Logs Are in Dynamics 365 and Dataverse
An audit log in Dynamics 365 and Dataverse works like a signing-in register for a personnel filing cabinet. The employee record, employment history, position, and Right to Work case are the folders. The log records who accessed a record, what operation occurred, and when, creating a reviewable account of activity rather than relying on memory or disconnected emails.
The Information Commissioner's Office frames logging around “who, what and when” in automated processing systems. Its guidance says logs should identify the person who accessed or disclosed information, the date and time, and, for a disclosure, the recipient. It also covers collection, alteration, consultation, disclosure, combination, and erasure. The ICO's guidance on what logging means gives UK HR and IT teams a practical benchmark for testing whether their design supports accountability.
The anatomy of an audit record
A useful Dynamics 365 or Dataverse audit event contains enough context to reconstruct what happened:
- Actor: a named user, application user, or service principal.
- Operation: such as create, update, delete, read, assign, share, export, or download.
- Target: the table, entity, and specific record involved.
- Change detail: the affected field, including old and new values where the platform and configuration provide them.
- Time: a reliable timestamp with consistent time-zone handling.
- Context: the client, integration, flow, plug-in, or other mechanism that initiated the event.
For example, an update to a Right to Work case should be understandable as a business action, not merely as a database change. Dataverse provides the platform layer for auditing data and relationship changes. Dynamics 365 adds application tables and HR workflow context, helping a reviewer connect the event to the relevant employment record or case.
The log also needs protection. The ICO says users should not be able to alter logging information themselves, while access to full logs should be limited to selected personnel. That separation supports investigations and reduces the risk that someone can change the evidence they may later be asked to explain. For HR teams applying privacy-by-design principles, this DynamicsHub guide to data protection by design offers a relevant implementation perspective.
The Events HR and Compliance Teams Must Capture
Not every event has the same evidential value. A plug-in failure may help IT troubleshoot a process, while a change to a worker's Right to Work status may need to support an audit, investigation, or disclosure response. Grouping events by purpose makes retention and review decisions much more precise.
Four useful event categories
Record lifecycle events show how an HR record moved through its existence. Capture create, update, delete, deactivate, and bulk-delete activity for tables such as Worker, Position, Employment History, Right to Work case, and Right to Be Forgotten request. These events can establish whether a decision was made, amended, withdrawn, or removed.
Access events concern consultation of sensitive information. A view, read, export, print, or download of personal data may matter when the organisation investigates inappropriate access or responds to a data subject request. Access records should identify the user and the information involved without collecting unnecessary personal content into the log itself.
Permission events explain who was able to do what. Role assignment, field-level security changes, business-unit changes, and team membership can reveal how access was granted or widened. A record change without the related permission history may leave a reviewer unable to explain why an individual could access the data.
Integration events are essential in automated HR environments. API calls, Power Automate runs, and Dataverse plug-in executions can change records without a person clicking directly in the HR application. If the system records only the service account, the organisation should retain enough run and correlation context to identify the initiating process and, where available, the human request behind it.
| Event Category | Typical Dataverse Examples | HR or Compliance Use Case | Evidence Class |
|---|---|---|---|
| Record lifecycle | Create, update, delete, deactivate, bulk delete | Worker history, Right to Work decisions, erasure requests | Regulated evidence |
| Data access | Read, view, export, print, download | Sensitive-data access review and incident investigation | Regulated evidence |
| Permissions | Role assignment, security change, team membership | Explaining access entitlement and privilege changes | Regulated evidence |
| Integrations | API call, flow run, plug-in execution | Tracing automated updates and failed controls | Operational telemetry, or regulated evidence when process-critical |
Separate telemetry from evidence
Operational telemetry supports availability, troubleshooting, and performance monitoring. Regulated evidence must be understandable, protected, reviewable, and producible when an organisation needs to explain a decision. Treating every technical message as regulated evidence creates unnecessary retention and privacy exposure, while treating important access and decision events as disposable telemetry creates a much more serious gap.
The ICO says logs should be kept only as long as necessary for their original purpose, with the period based on business need and statutory obligations. It also recognises that a log may need to stay longer when it could support an internal investigation or criminal proceedings. Your retention schedule should therefore classify log types rather than apply one blanket rule.
How Dynamics 365, Dataverse, and Microsoft 365 Audit Differ
The three audit layers answer different questions. Confusing them is one of the quickest ways to create a reassuring dashboard with incomplete evidence.
Dataverse provides the platform history
Dataverse auditing operates at the data platform layer. Once enabled for the organisation and relevant tables, it can record entity-level activity such as create, update, delete, associate, and disassociate events, alongside the user, time, and changed attributes. This is the foundation for HR records stored in Dataverse.
The gap appears when a table, field, or relationship hasn't been included in the audit configuration. A custom Right to Work table may exist and contain the correct information, yet its important changes won't be visible if auditing wasn't enabled for that component.
Dynamics 365 adds business meaning
Dynamics 365 application auditing helps teams apply coverage to the tables and processes that matter to the application. A Case, Account, Worker, Employment History, or HR-specific table can be selected for more focused monitoring. This makes it easier to connect a technical update to a business action, such as approving an HR case or changing a salary band.
Application-level audit still depends on correct configuration. A process that updates records through a flow or plug-in may show an application identity rather than the person who initiated the request. That isn't automatically a failure, but it does mean the organisation needs correlation between the user action, automation run, and resulting data change.
Purview covers the surrounding Microsoft 365 activity
Microsoft Purview audit provides evidence from the wider Microsoft 365 environment, including Exchange, SharePoint, OneDrive, Teams, and Entra sign-ins. That matters when an employment investigation involves a deleted email, a document shared outside the expected team, or a sign-in that doesn't match the user's normal activity.
| Layer | What It Captures | HR-Relevant Examples | Typical Retention | Notable Gaps |
|---|---|---|---|---|
| Dataverse | Platform data and relationship changes | Worker updates, assignments, record deletion | Policy-dependent | Unenabled tables, fields, or relationships |
| Dynamics 365 | Application and process activity | HR cases, approvals, employment records | Policy-dependent | Automation may obscure the initiating user |
| Microsoft Purview | Microsoft 365 user and service activity | Mail, Teams, SharePoint, OneDrive, Entra sign-ins | Service and policy-dependent | Doesn't replace HR record auditing or business context |
A defensible timeline often needs all three. Without correlation, HR may see a Dynamics record change and IT may see a Teams event, but neither can establish whether the events belong to the same investigation.
How DynamicsHub Surfaces Audit Data for HR Teams
Raw audit data is useful to administrators, but it can be difficult for an HR Business Partner to interpret during a live investigation. A working review surface should present the employee, event, actor, timestamp, action, and changed values in a sequence that follows the business process.
A practical employee timeline might show a Right to Work status moving from pending to approved, the user who made the change, the previous value, the new value, and the time of the update. The same view can show access to a sensitive document, an approval action, or an export event, without asking the reviewer to search unrelated platform tables.
Turn investigation questions into filters
During a misconduct or access investigation, the reviewer usually starts with a narrow question:
- Which actions did a particular user perform?
- Which records did they access or change?
- Did a field change before or after an approval?
- Did an export or permission change occur in the same period?
- Did an automated process update the record after a human decision?
Filterable views should support those questions by user, table, record, action type, date range, and integration context. That's more useful than presenting a large audit table and expecting HR to understand platform identifiers.
A correlated view can also bring Dataverse and Purview evidence into one case timeline. For example, a dismissal investigation might show the employee record change alongside relevant Exchange, Teams, or SharePoint activity around the same period. The purpose isn't to assume that related events prove misconduct. It's to give authorised reviewers enough context to test what happened and document their reasoning.
DynamicsHub can be used as an HR-focused review layer alongside Microsoft platform controls. Its Dataverse module information is relevant where teams need HR processes and Dataverse data represented in a structured operational view.
The distinction matters in front of an ICO auditor or employment tribunal. Having audit data means the records exist somewhere. Being able to explain the sequence, preserve the relevant view, identify limitations, and connect system events to the business process makes the evidence defensible.
Retention Rules That Decide How Long Logs Stay
Retention is where many HR systems fail. A log can be correctly captured today and still be unavailable when a historic case needs review because its retention setting was never mapped to the organisation's purpose, risk, or statutory obligations.
The ICO applies storage limitation to logs containing personal data. Its guidance says organisations should keep logs only as long as necessary for the original purpose, set periods by business need and statutory obligations, and review whether continued storage remains justified. The organisation should also document why each log class exists, rather than keeping everything indefinitely.
The NCSC recommends identifying the logs needed to answer incident questions and storing the most important logs for at least six months, because an incident may not be detected until months later. The NCSC introduction to logging for security purposes supports a risk-based approach rather than a single retention setting for every event.
Build a policy by log class
Start by separating at least these purposes:
- Security monitoring: retain enough information to investigate delayed detection and suspicious access.
- HR accountability: retain changes and approvals connected to employment processes.
- Regulated evidence: preserve information needed for a statutory or regulatory obligation.
- Investigation hold: suspend disposal where an internal investigation or legal process requires it.
The ICO's own retention and disposal policy gives a concrete public-sector example. It keeps system audit logs for up to 12 months, then destroys them when business need no longer justifies retention. That isn't a universal HR rule, but it demonstrates why retention must be purpose-led. The ICO retention and disposal policy shows how a documented schedule can set an upper boundary rather than allowing indefinite accumulation.
Dataverse settings should be checked against the HR document retention schedule, the organisation's Right to Work evidence policy, security monitoring requirements, and any legal hold process. Don't assume the platform's default is suitable for every HR record or every investigation.
For a practical policy framework, this document retention policy guidance can help teams connect audit retention with wider HR information governance.
Building Review Workflows and Incident Investigations
Audit logs become a control system when someone acts on them. Configuration alone won't identify unusual access, prove that monitoring works, or show whether the HR team can respond consistently.
A tiered operating model gives each team a defined responsibility:
- Daily anomaly checks: automate alerts for unusual bulk exports, after-hours access, privilege changes, and unexpected activity by service accounts. The alert should create an owner and a review outcome, not appear in an inbox.
- Weekly sample review: ask a compliance owner to inspect selected activity across sensitive HR tables, checking whether access and changes match the user's role and the recorded business purpose.
- Leadership attestation: have HR leadership review the control results, outstanding exceptions, and material incidents on a recurring governance cycle. The attestation should record what was reviewed and which actions remain open.
The supplied workflow visual includes a 5% sample review and a quarterly full audit. Those are design examples, not universal UK requirements, so each organisation should set its own sampling and reporting method through risk assessment.
A repeatable investigation sequence
When an alert or complaint arrives, preserve the original question before searching. Record the timeframe, affected employee or process, suspected user, relevant tables, and the reason for access. Then filter the audit view by user, entity, action, and time, preserving the resulting evidence so another reviewer can reproduce the analysis.
Cross-reference Microsoft Purview sign-in, email, Teams, SharePoint, or OneDrive activity where the investigation involves surrounding collaboration data. Keep the raw records separate from the interpretation, and produce an evidence pack with the search criteria, exported events, access restrictions, timestamps, reviewer, findings, and any known limitations.
The NCSC expects organisations to test monitoring through red and blue team exercises, so a review process should be tested rather than assumed. The NCSC guidance on log and audit administration activities reinforces the need for controls that are actionable and verifiable in practice.
The NCSC also recommends protected logging and reviewable monitoring across user activity, network communications, authentication, and access events. The ICO's guidance adds that people who generate logs shouldn't be able to alter them freely. Together, those principles require separation between log administration and log review, controlled access to full records, append-only or equivalent protection, and periodic checks for unauthorised actions and patterns.
Practical Questions and Next Steps
How long does Dataverse retain audit data by default?
Don't rely on an assumed period. Check the current environment configuration, the audit settings for relevant tables and fields, and the applicable retention policy. The ICO's position is that logs should remain only as long as necessary for their purpose, with longer retention possible where an investigation or criminal proceeding requires it.
Does DynamicsHub replace Microsoft Purview?
No. Microsoft Purview provides audit information from the wider Microsoft 365 estate, while Dynamics 365 and Dataverse record activity in the HR and business-data layer. An HR review surface can sit alongside those controls and help correlate events, but it shouldn't be treated as a replacement for platform or tenant-wide auditing.
Can audit logs support a Right to Work defence?
They can support the evidence chain by showing who uploaded, accessed, changed, or approved information and when. They don't replace the underlying Right to Work evidence, the organisation's checking procedure, or the relevant Home Office requirements. Your HR policy should define which records and events must be preserved.
What configuration mistakes create gaps?
The common failures are leaving custom tables unaudited, omitting sensitive fields, ignoring exports and downloads, losing the initiating user behind automated flows, giving administrators unrestricted access to logs, and applying one retention period to every event type. Test the result with a historic case and ask an independent reviewer to reconstruct what happened.
DynamicsHub can walk your HR and IT teams through the current audit posture, identify missing event coverage, and show how Dataverse and Microsoft 365 evidence can support a practical investigation workflow. Book a focused review with DynamicsHub or contact the team on 01522 508096 to turn audit-log configuration into evidence your organisation can explain and defend.
