A digital workplace manager reviewing a data retention schedule table that maps analytics datasets to purposes, retention periods, owners and deletion rules, on a screen beside Microsoft 365 channel icons.

IC analytics data retention: what to set and why

By Nicolas Saliba · Published October 2026 · 14 min read

In short

Retention for IC analytics is not one blanket number. Separate identifiable event records from aggregated trends, justify every period by a documented purpose, and test deletion before you rely on it. We walk through the schedule, the Microsoft controls and the questions to ask your analytics vendor.

Key takeaways

UK GDPR sets no universal retention period: you must justify each duration by the purpose of the dataset and keep a policy with standard retention periods.

Pseudonymised analytics data remains personal data under EDPB guidance; only irreversible anonymisation removes it from GDPR scope.

Microsoft's unified audit log keeps most activity for 180 days by default, and Exchange, SharePoint, OneDrive and Entra ID records of E5-licensed users for one year.

Purview retention settings govern Microsoft content, not the telemetry and exports your analytics SaaS copies: those need their own schedule.

Test deletion for leavers, backups, exports and holds before you rely on the schedule, and assign a data owner to review it when purposes change.

Which analytics records actually identify employees?

Before you can set a retention period, you need an honest inventory of what your internal communication analytics stack actually holds. In a Microsoft 365 environment that is rarely one dataset. It is a collection of records at different levels of identifiability, spread across native platform reporting, your analytics layer, and the exports and dashboards your comms team builds on top. Map them first, because each category carries a different privacy weight and therefore justifies a different retention rule.

Direct identifiers: user IDs, email addresses and Entra ID object IDs that name an individual in the record itself.
Indirect identifiers: device or session markers that do not name a person but can single one out when combined with other data.
Organisational attributes: department, country, role, site or tenure, which turn an anonymous event into a profile when joined to HR data.
Event-level logs: individual reads, reactions, comments and email opens tied to a person and a timestamp.
Exports and dashboards: spreadsheet extracts, Power BI datasets and cached reports that copy identifiable data out of the source system and are routinely forgotten in retention planning.
Aggregate metrics: reach, engagement rate and readership percentages that describe groups rather than individuals.

Microsoft's own documentation is a useful reality check here. In its account of the EU Data Boundary, Microsoft states that when events in its cloud services are initiated by user interaction, some system-generated logs contain fields that either identify or can identify specific persons, and that these logs therefore contain personal data. Microsoft requires all personal data in system-generated logs to be pseudonymised, using techniques such as encryption, masking, tokenization and data blurring.^[1] If Microsoft treats its own operational logs this way, your IC analytics event store deserves the same classification: treat event-level records as personal data even when the display name is hidden.

The category most often missed is copies. Every export a comms manager downloads, every CSV attached to a steering-deck email, and every Power BI dataset refreshed from the analytics platform is a new retention problem with no owner and no expiry date. Include exports in your inventory from day one, or your retention schedule will govern the system of record while the identifiable data quietly lives on in shared drives.

What purpose justifies each retention period?

The UK GDPR sets no universal retention period for analytics data. The ICO is explicit: you must not keep personal data for longer than you need it, you need to think about and be able to justify how long you keep it based on your purposes, and you need a policy setting standard retention periods wherever possible.^[2] For an IC analytics dataset, that means the question is never 'how long can we keep it?' but 'what are we still doing with it?'

Dataset	Purpose	Proposed period	Approval needed
Event-level logs with user IDs	Campaign evaluation: which audiences read, reacted or commented, per send and per post	Short, aligned to your campaign planning cycle	DPO and works council or employee representatives
Aggregated readership trends	Long-term channel and topic reporting: quarter-on-quarter and year-on-year comparisons	Multi-year, because irreversibly anonymised aggregates carry low re-identification risk when built with minimum group sizes of at least ten people per cut	DPO sign-off on the aggregation rules
Segmented exports for steering decks	Point-in-time analysis for a specific campaign or leadership review	Delete after the review cycle, e.g. 90 days	Data owner
Incident or complaint records	Investigating a specific misuse or misrouting of internal messages	Duration of the investigation plus any legal limitation period	Legal and DPO

Treat every duration in that schedule as a proposal, not a decision. Each one needs a named approver, typically your data protection officer, and where you operate in France, Germany or another EU jurisdiction with formal employee representation, works council consultation before the schedule goes live. A duration nobody has approved is a duration nobody will defend when a regulator or an employee representative asks why you still hold two years of identifiable reads.

Design for erasure requests from the start. If your event store lets you delete an individual's records on request, an erasure request is routine. If it does not, you have a design gap that no retention policy can paper over.

How do aggregates differ from raw event history?

The practical answer to retention pressure is a two-tier model: keep identifiable event history short, and keep aggregated trends long. But the boundary between the two tiers has to be drawn correctly, because the most common mistake in IC analytics is assuming that removing names makes data anonymous. It does not.

Pseudonymisation is a safeguard, not an exit from GDPR. The European Data Protection Board distinguishes the two concepts clearly: pseudonymisation reduces the linkability of data to a specific individual without aiming to completely cut that link, while anonymisation makes data unlinkable to any individual, and truly anonymised data falls outside the scope of EU data protection law.^[3] A dataset of reads where each user ID has been replaced with a token is still personal data, because the token can be re-linked.

	Raw event history	Aggregated trends
What it holds	Individual reads, reactions and opens tied to a user ID and timestamp	Reach, engagement rate and readership percentages for groups
Legal status	Personal data, even when pseudonymised	Personal data only if individuals remain identifiable from the cut
Retention	Short, justified by campaign evaluation	Longer, justified by trend reporting, within approved aggregation rules
Risk control	Access restriction, deletion on schedule, erasure on request	Minimum group sizes, no re-identifiable cuts

Irreversible anonymisation is the threshold that lets aggregates live for years. A compliant aggregate has a minimum group size, commonly at least ten people per reported cut, so that a small team cannot be reverse-engineered from a percentage, and it avoids cuts that combine attributes narrowly enough to single someone out, such as the engagement rate for a five-person team in one country. If your dashboards can drill down that far, the drill-down is event-level data wearing an aggregate's clothes, and it belongs in the short-retention tier.

What do Microsoft retention controls cover?

You already govern content in Microsoft 365 with Purview, so it is tempting to assume those policies cover your IC analytics too. They do not, and the gap matters. Purview retention settings operate on content in place: they can retain content only, delete content only, or retain and then delete, and when content under retention is edited or deleted, a copy is kept in hidden locations such as the Preservation Hold library for SharePoint and OneDrive and the SubstrateHolds folder for Teams and Viva Engage messages.^[4] Those controls govern Microsoft's copy of the content. They say nothing about the telemetry a third-party analytics SaaS has already copied into its own database, or about the exports sitting in your comms team's shared library.

The unified audit log has its own licence-dependent defaults, which are worth knowing because they shape what evidence you can produce about who did what:

180 days: the default retention for audit records under Audit (Standard), and for all activities outside Exchange, SharePoint, OneDrive and Entra ID.
One year: the default retention for Exchange Online, SharePoint, OneDrive and Microsoft Entra audit records under Audit (Premium), for users with an E5 or equivalent licence.
10 years: available only where the user generating the records also holds the 10-year audit log retention add-on licence in addition to E5.

One nuance in those defaults catches teams out: the audit item lifetime is fixed when the record enters the pipeline, so a later licence change does not extend previously committed items.^[5] The practical conclusion for your retention schedule follows from the gap described above: Purview governs Microsoft's content and your audit policies govern Microsoft's logs, while the copies your analytics tool holds fall under the separate schedule, owner and deletion mechanism you define for them.

How should deletion and exceptions be tested?

A retention schedule that has never been tested is a document, not a control. The ICO expects you to regularly review the data you hold and erase or anonymise personal data when you no longer need it, and to have processes in place for erasure requests.^[2] The way to honour that expectation is to define test cases before you rely on the schedule, and to run them on a fixed cycle.

Leaver deletion: an employee leaves, their Entra ID account is removed, and their event-level records in the analytics platform are deleted or anonymised within the scheduled period. Verify the result in the data, not in the vendor's documentation.
Backup expiry: a backup taken before a deletion still contains identifiable records. Confirm that backups expire on schedule and that restored environments do not resurrect deleted data.
Export recall: a CSV exported for a steering deck should be deleted after its review cycle. Test whether you can actually find and delete the copies, or whether they are untracked.
Legal hold: a dispute or investigation suspends deletion for specific records. Confirm the hold is documented, scoped to named records, and carries an expiry date rather than remaining open indefinitely.
Contractual deletion: at the end of a SaaS agreement, the vendor must return or delete your data within a defined window. Test the offboarding path before you sign, not after.

Holds deserve particular discipline. An exception to deletion is legitimate, but an exception without an expiry date is just indefinite retention with better PR. Record who placed the hold, which records it covers, and when it will be reviewed, and make the review a calendar entry rather than an intention.

For vendor deletion, put the mechanics in the contract: what is deleted, within how many days of termination, whether backups are included, and what evidence of deletion you receive. Then treat the first offboarding test as a real test, with the same rigour as a disaster-recovery drill.

Who reviews the schedule when purposes change?

Retention schedules decay quietly. Channels get added, a comms director asks for a new cut of the data, an attribute from the HR system gets joined in for segmentation, and one day the schedule describes a dataset you no longer have. The fix is a named data owner and explicit review triggers.

The data owner for your IC analytics dataset should be a named person, typically the digital workplace or IT manager who operates the platform, working with the DPO as approver. Their responsibilities: keep the inventory current, ensure each dataset's purpose statement still matches how it is actually used, and bring the schedule back for approval when reality drifts from it.

A new channel is connected, such as adding Viva Engage communities or a newsletter platform to the analytics scope.
A new purpose emerges, most critically any move toward individual-level performance tracking, which changes the legal analysis and usually requires fresh consultation.
A new attribute is joined in, such as HR demographic data that deepens segmentation and therefore identifiability.
A licence change shifts Microsoft-side defaults, for example E5 coverage that changes audit record retention.
A vendor or tooling change alters where copies of the data live.

Document each review: what triggered it, what changed, who approved it. That record is your accountability evidence, and it turns the retention schedule from a one-off compliance exercise into a living control that survives staff changes and platform growth.

What should you verify with Communication Insights?

When you connect a cross-channel analytics platform to your Microsoft 365 tenant, you are creating a new copy of employee-level data with its own retention clock. Treat that as a procurement question, not an assumption. Ask for the platform's actual retention and deletion settings in writing: how long event-level records are kept, how leavers are handled, whether aggregates are built to minimum group sizes, and what happens to your data at the end of the contract. A vendor who cannot answer those questions in a document has not built the controls.

What is the retention period for event-level records, and what purpose justifies it?
How are leavers' records deleted or anonymised, and can you trigger that on demand for erasure requests?
How are aggregates constructed: minimum group sizes, no re-identifiable cuts?
What deletion evidence do you provide at contract end, including backups and exports?

Then align the platform's settings with your approved schedule. Long-term trend analysis is one of the main reasons to run a dedicated analytics layer, because it lets your comms team compare readership across quarters and years in one place instead of rebuilding numbers from native reports. But unlimited historical analysis is not permission to keep identifiable employee data indefinitely: the long view should come from aggregates built within your approved policy, not from event-level records kept past their period.

This is exactly the conversation we suggest having with us. Communication Insights is our all-in-one cross-channel analytics platform that connects email newsletters, your SharePoint intranet, Viva Connections and Viva Engage into one central dashboard, and we are used to walking IT and digital workplace teams through retention, deletion and security controls before a rollout. Review the retention controls with Tryane: book a call or demo with Jérémy via his Calendly and bring your retention schedule, so we can map the platform's settings to the periods and approvals you have already defined.

Frequently asked questions

How long can I keep employee analytics data under GDPR?

There is no fixed period. The storage limitation principle requires you to keep personal data no longer than necessary for your purposes, so each dataset needs a justified, documented retention period in a policy, plus periodic review and erasure or anonymisation when the data is no longer needed.

Is pseudonymised analytics data still personal data?

Yes. Under EDPB Guidelines 01/2025, pseudonymised data that could be attributed to a person using additional information remains personal data, even when that additional information is held by someone else. Only full anonymisation, which is irreversible, takes the data outside GDPR.

How long does Microsoft retain the audit logs behind analytics?

Most unified audit log records are retained for 180 days by default. Exchange, SharePoint, OneDrive and Microsoft Entra ID records generated by E5-licensed users are retained for one year, and organisations can extend retention up to 10 years with custom policies and the 10-year audit log retention add-on licence.

Do Microsoft Purview retention policies cover my analytics platform's data?

No. Purview retention settings govern Microsoft content in place, with retained copies held in locations like the Preservation Hold library and SubstrateHolds. Telemetry your analytics SaaS has copied, and any exports you have made, sit outside those controls and need their own documented retention schedule.

Can I keep aggregated trends longer than raw event data?

Yes, if the aggregates are genuinely anonymous. Raw, identifiable event records should follow a short purpose-driven schedule, while irreversibly anonymised aggregates, built with safeguards like minimum group sizes, can support long-term trend analysis because they no longer identify anyone.

Who should own the retention schedule for IC analytics?

Assign a named data owner, typically in IT or the Digital Workplace function, who approves durations, handles exceptions such as legal holds, and triggers a review whenever a new channel, purpose or identifying attribute is added to the analytics stack.

What should I ask an analytics vendor about retention?

Ask for the actual retention and deletion settings in writing: default retention for event data, how leaver data is deleted, how backups and exports expire, what the contract says about deletion at the end of the agreement, and whether long-term trends are produced from anonymised aggregates.

Sources

• learn.microsoft.com

• ico.org.uk

• edpb.europa.eu