If your organisation is introducing mi.team or any kind of system that potentially captures personal data, a Data Protection Impact Assessment (DPIA) is often a legal requirement, not just good practice — the ICO specifically names keystroke monitoring and workplace monitoring more broadly as activities likely to require one.

We’ve completed most of this for you. For a standard mi.team rollout using our recommended settings, the answers below are already correct — you just need to fill in the handful of fields specific to your business, marked in [bold brackets]. If your rollout is unusual in some way (a covert investigation, a non-standard settings configuration), review the relevant section carefully rather than relying on the default wording.

This is a genuine, properly structured starting point — not a substitute for your own legal advice. If your assessment identifies a high risk you can’t reduce, you’re required to consult the ICO before proceeding, and for anything borderline, a solicitor’s sign-off is worth the cost.

Want the full legal background first? Read our guide on what UK law actually requires for staff monitoring.

Data Protection Impact Assessment

Subject: Introduction of mi.team productivity and device monitoring software

Step 1: Identify the Need for a DPIA

[Organisation name] is introducing mi.team, productivity and device monitoring software, on company-owned devices used by [all staff / department name]. This involves systematic monitoring of employee activity, which the ICO identifies as processing likely to require a DPIA.

Step 2: Describe the Processing

Nature: mi.team records which applications and websites are used and for how long on company devices, categorised automatically into productive, unproductive, and neutral time. It does not take screenshots, log keystrokes, or record audio or video at any point. Activity identified as personal or private is automatically redacted by mi.team’s Privacy AI before it is visible to anyone, including managers.

Scope: Applies only to company-owned devices, during all hours the device is in use — this includes time outside standard working hours, so that effort outside the normal 9-to-5 is also visible where relevant. Does not apply to personal devices under any circumstances.

Context: Staff were informed in advance of monitoring being introduced, via a company-wide communication sent on [date], explaining plainly what is and isn’t collected. This was sent before mi.team was installed on any device.

Purpose: [Select the reasons that genuinely apply, e.g.] to understand team workload distribution, identify where processes or tools are creating inefficiency, support fair and evidence-based flexible or hybrid working arrangements, and maintain basic device security oversight (patch status, firewall, encryption).

Step 3: Consultation

Staff were informed via a company-wide announcement on [date], with the opportunity to raise questions with [named contact/role]. [If applicable: staff representatives or a union were consulted on [date].]

Step 4: Assess Necessity and Proportionality

Lawful basis: Legitimate interests (UK GDPR Article 6(1)(f)), assessed against the three-part test:

• Purpose — the business reasons documented in Step 2 above are genuine and specific, not generic.
• Necessity — less intrusive alternatives (manual timesheets, ad-hoc check-ins) were considered and found less accurate and more time-consuming. Screenshot- or keystroke-based tools were ruled out as disproportionate given the same insight is achievable without them.
• Balancing — the business need is judged to outweigh the impact on staff privacy, given the safeguards in Step 6 below (no screenshots/keystrokes, automatic redaction of private activity, restricted default visibility).

Step 5: Identify and Assess Risks

For a standard mi.team rollout using our recommended settings, the baseline risk profile is low across the board — the table below reflects that starting point. Adjust any row where your organisation’s circumstances genuinely differ.

Step 6: Measures Already in Place to Reduce Risk

• Personal/private data capture: mi.team’s Privacy AI automatically identifies and redacts personal or private activity before it’s visible to anyone, including managers. No screenshots or keystroke logging are collected at any point, removing the primary source of this risk by design rather than by configuration.
• Staff distrust: Monitoring was communicated transparently before rollout, with plain-language explanation of what is and isn’t collected, rather than introduced silently.
• Retention: Data retention is set to [X months/years], aligned with [organisation]’s data retention policy.
• Access control: By default, staff who aren’t grouped into a shared team can see only minimal presence information about colleagues (devices, last active, member since, top categories) — not productivity data. Full overview visibility (productivity trends, time breakdown) is limited to people sharing a team; full individual activity logs are limited to that team’s managers, and even then, privacy-redacted content stays hidden regardless of role.

Step 7: Sign-Off and Record Outcomes

If your risk assessment in Step 5 comes out higher than the standard baseline above and can’t be reduced further, you must consult the ICO before proceeding — don’t skip this check because it feels unlikely to apply.

Important Note

This template gives you a properly structured, largely pre-completed starting point, following the ICO’s own DPIA process. It isn’t a substitute for legal advice specific to your organisation, and we can’t guarantee it covers every circumstance — particularly if your rollout involves anything outside the standard settings described here. For anything genuinely high-risk or borderline, get it reviewed by a solicitor before you rely on it.