A Digital Workplace manager reviewing a DPIA template on a screen, with a simple diagram of data flowing from email, intranet and social channels into an analytics dashboard, annotated with access controls and a sign-off checkbox.

DPIA for internal comms analytics: template and scope

By Nicolas Saliba · Published October 2026 · 14 min read

In short

Before you deploy internal comms analytics, screen it, map the real data flow, and record mitigations and residual risk in a DPIA your DPO signs off. We walk through the screening criteria, the template fields, the segmentation risks and the evidence to request from your vendor.

Key takeaways

A DPIA is required when comms analytics is likely to result in high risk; the WP29 nine criteria include systematic monitoring, evaluation or scoring, and combining datasets, and a combination of two usually triggers a DPIA.

Map the access model explicitly: delegated access is limited to what the signed-in user can reach, while app-only access lets an app reach any data the permission covers, per Microsoft Graph documentation.

Segmentation is the core reidentification risk: small cohorts, sensitive inferences and cross-channel data matching can turn aggregate dashboards into individual-level monitoring.

A filled template does not itself authorise processing: residual risk must be recorded, DPO advice documented, and if high risk remains the ICO must be consulted, with written advice within eight weeks or 14 weeks in complex cases.

The organisation owns the DPIA as controller; the vendor's role is to supply the data flow, permissions and hosting evidence you need to complete it.

When does communication measurement require a DPIA?

Screen the project before you write a single field of the assessment. Both the CNIL and the ICO start from the same legal trigger: where a processing operation is likely to result in a high risk to the rights and freedoms of natural persons, the controller must carry out an impact assessment. You screen for factors that point to that potential before you have measured the actual risk, and for a cross-channel internal communication analytics deployment, several of those factors usually light up at the same time.

Systematic monitoring: measurement runs continuously across email, intranet and enterprise social channels, observing employee behaviour over time.
Evaluation or scoring: engagement rates and content performance involve evaluating aspects of employees' behaviour at work, which the European guidelines name as a criterion.
Data processed on a large scale: the WP29 guidelines point to the number of data subjects, the volume and range of data items, the duration of the activity and its geographical extent.
Matching or combining datasets: cross-channel analytics joins email, intranet and social network data by design, which the ICO lists as a standalone trigger.
Data concerning vulnerable data subjects: the WP29 guidelines name employees explicitly, because of the power imbalance with the controller.

The EU and UK guidance differ in structure but point to the same triggers. The CNIL's methodology, built on the WP29 guidelines, sets out nine criteria and advises that a processing operation meeting two of them generally requires an assessment, although a single criterion can be enough in some cases^[1]. The ICO uses a screening checklist that draws on those same European criteria and adds its own list of triggers, including combining, comparing or matching data from multiple sources^[2].

Aspect	CNIL / WP29 (EU)	ICO (UK)
Trigger	Processing likely to result in high risk (Article 35(1))	Same trigger, plus an additional UK-specific list
Screening tool	Nine criteria; two or more usually indicate a DPIA is needed	Screening checklist built on the same European criteria
Methodology	Four-phase PIA: context, fundamental principles, security risks, validation	Step-by-step process with a sample DPIA template

In practice, a comms analytics rollout rarely meets just one criterion, so treat the screening as a documented decision either way. The ICO is clear that if you decide not to carry out a DPIA, you record your reasons, and that a DPIA is good practice for any major project involving personal data even when no specific trigger applies^[2].

How do you map data and access paths?

The most common weakness in an analytics DPIA is a data-flow description copied from the vendor's marketing pages. Your assessment must describe the flow you are actually deploying: which identifiers and attributes are collected on each channel, where they travel, who can reach them and under what access model. Map it from the source system to the dashboard your communicators open.

Email newsletters: delivery, open and click events tied to mailbox identifiers.
SharePoint intranet: page views and read events per site, page and audience.
Viva Engage: views, reactions and comments on posts and communities.
Directory attributes used for segmentation: department, country, language and role, which cross-channel platforms typically use to break reach and engagement down by audience.

For each flow, record the sources, the recipients and any processors involved, together with where the data is hosted and whether it leaves your region. This is also where you identify who is the controller and who is the processor, because the answer determines who owns the assessment and who supplies evidence for it.

The access model belongs in the assessment because it determines the worst-case exposure. Microsoft documents two distinct scenarios for Microsoft Graph: in delegated access, the app calls the API on behalf of a signed-in user and cannot access anything that user could not access, while in app-only access the app calls with its own identity and can access any data the granted permission covers^[3].

	Delegated access	App-only access
How it works	App acts on behalf of a signed-in user	App calls Microsoft Graph with its own identity
Reach	Limited to what the signed-in user can already access	Any data the granted permission covers
Consent	User or admin consents at sign-in	Administrator consents in the tenant; only Privileged Role Administrator or Global Administrator can consent to application permissions

Whichever model your analytics tool uses, write it into the DPIA with the specific permissions requested, not just the product name. The difference between the two models is the difference between an app that inherits human-level access and one that does not, and your mitigations in the later sections depend on knowing which one you have.

Which fields belong in the assessment template?

Structure your template around what the regulators actually expect to read. The ICO requires a DPIA to describe the nature, scope, context and purposes of the processing, assess necessity, proportionality and compliance measures, identify and assess the risks to individuals, and identify additional measures to mitigate those risks^[2]. The CNIL's PIA methodology follows the same logic in four phases: study the context, verify the fundamental principles of proportionality and rights protection, assess security risks, and formally document the validation^[4].

Template field	What to record
Purpose and scope	Nature, scope, context and purposes of the processing; which channels are in and out of scope
Lawful basis and necessity	The basis you rely on and why measurement is necessary for that purpose
Alternatives considered	Less intrusive options you evaluated and why they were not chosen; the ICO expects you to evidence this
Data minimisation	The fields and attributes you collect, and, just as importantly, the ones you excluded
Retention	Storage periods per dataset, aligned to the CNIL's requirement for limited storage durations
Rights handling	How transparency notices, access requests and objection rights are served for employee data
Risks and mitigations	Each risk with its likelihood and severity, and the measures that reduce it
DPO advice and sign-off	The advice sought and recorded, the decision taken and the accountable owner

Two fields deserve more attention than they usually get. First, alternatives: the ICO's guidance on what makes a good DPIA asks you to evidence your consideration of less risky alternatives to achieving the same purpose, so record what you compared and why the chosen approach is proportionate. Second, function creep: analytics scopes tend to grow, and the ICO requires a new DPIA when there is a change to the nature, scope, context or purposes of the processing^[2]. Write the scope narrowly enough that a future expansion is visible and triggers a review rather than sliding through.

How can segmentation create reidentification risks?

The segmentation that makes communication analytics useful is the same feature that creates privacy risk. A dashboard that tells you a campaign missed frontline staff in one plant is doing its job; the same dashboard, filtered too finely, tells you which individuals did not read it. Assess this deliberately rather than assuming that aggregated data is safe by default.

Small cohorts: a view filtered to a five-person team effectively names individuals even when no name is displayed, because everyone reading it knows who is in the group.
Sensitive inferences: combinations of attributes such as site, shift pattern and language can point to union membership, health context or performance signals, none of which you set out to collect.
Combining datasets: the ICO lists matching or combining data from multiple sources as a screening trigger, and cross-channel analytics performs exactly this join when it connects email, intranet and social network activity.

The WP29 guidelines make the same point from the EU side: matching or combining datasets becomes a risk criterion when it exceeds the reasonable expectations of the data subject, and employees are named as vulnerable data subjects because of the power imbalance with the controller^[1]. Cross-channel measurement is legitimate and valuable, but it concentrates inference power, so your DPIA should name the combinations your platform actually performs.

Keep the distinction between measurement and surveillance explicit in the document. Analytics that answer whether a message reached its intended audience are different in kind from tools that profile individual behaviour, and drawing that line clearly, in the DPIA and in the transparency notice, protects employee trust as much as it protects compliance. For a fuller treatment of where that line sits, see our guide to measurement versus surveillance.

Which mitigations should be tested before rollout?

Treat every mitigation as a decision your organisation makes and verifies, not as a claim you accept from a vendor. The ICO expects your DPIA to identify the measures that eliminate or reduce identified risks, and to explain how each proposed mitigation reduces the risk in question^[2]. That explanation is only credible if you have tested the control against the access paths you mapped earlier.

Access limits: decide which roles see which dashboards, which segments and at what aggregation threshold, and check each decision against the delegated or app-only access you documented.
Cohort rules: set minimum group sizes for every report view and suppress segments below the threshold, so no dashboard can effectively name individuals in a small team.
Scope and retention reductions: the ICO's guidance on pseudonymisation notes that such techniques can reduce the risks your processing poses to people's rights, and reducing scope or retention shortens the exposure window^[5].

Then test the controls on a pilot population before full deployment. Run the dashboards against one department or region, check whether any view produces cohorts below your minimum group size, and confirm that the access restrictions hold for every role that will use the platform. A control that exists in configuration but not in observed behaviour is not a mitigation; it is an assumption.

Record each mitigation in the DPIA with an owner and a verification step. This turns the mitigation table from a list of intentions into an action plan, which is what the CNIL's PIA methodology asks for in its validation phase: for each additional control, the person responsible for implementing it and the timeframe^[4].

Who records residual risk and authorises deployment?

Close the governance loop with a sign-off record that states what risk remains after your mitigations and who accepts it. A DPIA does not have to show that all risks were eradicated; it has to document them and record whether the remaining risks are justified^[2]. For each identified risk, record whether it was eliminated, reduced or accepted, and name the accountable owner who made that call.

Residual risk: what remains after the mitigations, assessed for likelihood and severity.
DPO advice: the ICO requires you to seek your DPO's advice and record it, including any difference of opinion and your reasons if you do not follow it.
Review triggers: a change to the nature, scope, context or purposes of the processing requires a fresh DPIA, so define what counts as a change before someone discovers it in production.
Escalation: if a high risk cannot be mitigated, you must consult the supervisory authority before processing starts; the ICO gives written advice within eight weeks, or 14 weeks in complex cases.

Be clear about what the signature means. A filled template does not itself authorise processing; deployment is authorised when the accountable owner has reviewed the residual risk, accepted it and recorded the decision. The CNIL's PIA methodology treats this validation as a distinct phase in which the controller formally documents the decision in view of the study's findings^[4].

In European organisations, this loop usually runs alongside employee representation: if a works council or CSE must be consulted, sequence that consultation with the DPIA so the mitigations you commit to match the ones you record in the assessment.

What evidence can Communication Insights contribute?

As the Digital Workplace or IT manager deploying the tool, you should request a specific evidence pack from the vendor and attach it to your DPIA: the documented data flow from your Microsoft 365 tenant to the analytics platform, the exact Microsoft Graph permissions used and whether access is delegated or app-only, the hosting location, and current security and compliance certifications. Tryane hosts Communication Insights in the EU and designs it to be GDPR compliant, with sign-in through Entra ID, but the evidence you need is the documentation of those properties, not the statement itself.

Keep the division of labour straight. The ICO is explicit that processors may need to assist you in understanding and documenting their processing activities, but the organisation remains the controller: the screening, the assessment, the residual-risk record and the sign-off are yours, and a vendor compliance statement is an input to your DPIA, never a substitute for it^[2].

Communication Insights is an all-in-one cross-channel analytics platform that connects your email newsletters, SharePoint intranet, Viva Connections and Viva Engage into one central dashboard, which is why the data-flow mapping and the segmentation risks in this article apply to it directly. Request the processing evidence for your DPIA, review it against the access paths and cohort rules you have defined, and book a call with Jérémy to walk through the documentation before you sign off the deployment.

Frequently asked questions

When does internal communication analytics require a DPIA?

When the processing is likely to result in a high risk to employees' rights and freedoms. Under CNIL and ICO guidance, screening criteria such as systematic monitoring, evaluation or scoring, large-scale processing and combining datasets apply directly to cross-channel comms analytics; the ICO notes that a combination of two WP29 criteria usually indicates a DPIA is needed.

Is a vendor's GDPR compliance statement enough to skip the DPIA?

No. The organisation deploying the analytics remains the controller and owns the DPIA. ICO guidance says processors may assist with information, but responsibility for the assessment, the residual-risk record and the sign-off stays with you. A vendor statement can inform the assessment, never replace it.

What is the difference between delegated and app-only access in Microsoft Graph?

In delegated access the app calls Microsoft Graph on behalf of a signed-in user and cannot access anything that user could not access. In app-only access the app calls with its own identity and can access any data the granted permission covers, which is why Microsoft describes application permissions as highly privileged and recommends delegated permissions from a least-privilege perspective.

What fields should a DPIA template for comms analytics contain?

At minimum: a description of the processing (nature, scope, context and purposes), the identifiers and attributes collected per channel, the lawful basis, necessity and proportionality including alternatives and data minimisation, retention periods, risks to individuals, mitigations, and how employee rights and transparency are handled. This mirrors the ICO's seven-step process and the CNIL four-step approach.

Why is audience segmentation a privacy risk?

Because segmentation is what makes analytics useful and what makes it personal. Dashboards filtered to small teams can effectively name individuals, combinations of attributes can support sensitive inferences, and joining email, intranet and social network data is data matching, which the ICO lists both as a screening criterion and as a risk, including reidentification of pseudonymised data.

Who signs off the DPIA and authorises deployment?

The accountable business owner records the residual risk after mitigations and whether each risk was eliminated, reduced or accepted, and the DPO's advice must be sought and documented, including on whether the processing can go ahead. If you decide not to follow the DPO's advice, record your reasons.

What happens if a high risk remains after mitigation?

You must consult your supervisory authority before starting the processing. The ICO gives written advice within eight weeks, or 14 weeks in complex cases, and may issue a formal warning or ban the processing. A completed template never authorises processing on its own.

What evidence should I request from an analytics vendor for my DPIA?

Ask for the data flow documentation, the exact Microsoft Graph permissions and access model used (delegated or app-only), hosting location and residency, security certifications, and sub-processors if any. That evidence feeds your assessment; the DPIA itself, and the decision to deploy, remain your organisation's.

Sources

• cnil.fr

• ico.org.uk

• learn.microsoft.com