This is our complete, repeatable process for rolling out mi.team properly — the seven steps we recommend every business or MSP follows, in order, so nothing gets missed and nothing has to be explained awkwardly after the fact.
We’re also building this into a guided, automated assistant inside the mi.team platform, so you’ll eventually be able to step through this in-app rather than following an article. That’s not live yet — this article is the authoritative process in the meantime.
Once you or your IT team have opened your mi.team account, you can follow this process to deploy mi.team at your organisation. Haven’t got one yet? Start your free trial to get set up first — MSPs signing up on behalf of clients should use the MSP sign-up instead.
Jump to any step using the contents list on the right — you don’t need to read this top to bottom if you already know which step you’re on.
Your Rollout Details
Fill these in once — they’re reused automatically in the generators for Steps 2, 3, 4, and 7 below, so you only need to type them here.
Step 1: Confirm Your Lawful Basis
For almost every business, this is a quick confirmation rather than a real decision: legitimate interests is the lawful basis that applies to standard productivity monitoring. Consent is rarely valid in an employment relationship, and the other UK GDPR bases don’t apply to this kind of processing.
If your situation is anything other than a standard rollout, read the full explainer first: Is it Legal to Track Staff Productivity in the UK?
Step 2: Decide Your Settings Model
mi.team defaults to login access being available to everyone, including anyone not yet placed in a team — you can switch this off for a specific team where there’s a genuine, exceptional reason to (an active investigation, for example), but for a standard rollout, leave it on.
What’s actually worth deciding upfront is your team structure — group staff by department for manager oversight, and consider whether a company-wide team makes sense for org-wide overview visibility (teams stack, so this doesn’t cost anyone their existing team-level oversight).
Not sure how to actually set this up? See How to Create Teams, Add Members, and Add Managers in mi.team for the full walkthrough.
Your disclaimer wording, generated from the details above:
Paste the generated text into mi.team’s Startup Agreement settings under Window Text.
Step 3: Send the Pre-Deployment Email
Tell the team before anything’s installed, not after. Choose the reasons that are genuinely true for your rollout — don’t select all of them just because they’re there.
Login access for this rollout:
Reasons to include (pick 1–2 genuine ones):
Copy the email text, check it, then send it to your team. For the full explanation of this step, including why it works better sent from IT directly, see How Do I Tell My Team About mi.team Without It Sounding Like Surveillance?
It also helps to include a screenshot of the disclaimer pop-up in this email, so staff know exactly what to expect when they first see it:
Step 4: Complete the DPIA
Your DPIA should reference the communication you just sent in Step 3, so it belongs here, not earlier. Download the full pre-completed template, then use the summary below to quickly fill in the handful of genuine blanks it still has.
Get the template (web version and downloadable Word doc): DPIA Template for Employee Monitoring
View the full pre-completed DPIA (click to expand)
This is the same content as the downloadable version above, shown here for quick reference. If you’re completing it, we’d still recommend downloading the Word version so you can save and file it properly.
Data Protection Impact Assessment
Subject: Introduction of mi.team productivity and device monitoring software
| Organisation | [Organisation name] |
| Completed by | [Name / role] |
| Date completed | [Date] |
| Reference | [e.g. DPIA-2026-01] |
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.
| Risk | Likelihood | Severity | Overall risk |
|---|---|---|---|
| Personal/private data inadvertently captured | Low | Medium | Low |
| Staff distrust or morale impact if poorly communicated | Low | Medium | Low |
| Data retained longer than necessary | Low | Low | Low |
| Unauthorised internal access to monitoring data | Low | Medium | Low |
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
| Item | Name | Date | Notes |
|---|---|---|---|
| Measures approved by | |||
| Residual risk approved by | |||
| DPO advice provided (if applicable) | |||
| Consultation responses reviewed |
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.
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. For anything genuinely high-risk or borderline, get it reviewed by a solicitor before you rely on it.
Step 5: Deploy
Pick whichever of the seven supported deployment methods fits your existing environment, pilot on a small group first, then roll out to everyone. If you’re not sure which method fits your setup, it’s worth speaking to your IT professional or provider to work out which one is right for your organisation.
Full technical guide: How to Deploy mi.team Silently: The Master Guide
Step 6: Confirm Enrolment
Check the dashboard shows every device reporting in as expected before considering the rollout complete. If a device is missing, it’s much easier to catch and fix this right away than to discover a gap weeks later.
Step 7: Send the Follow-Up Email
Confirm it’s live, and remind people exactly how to find and access mi.team on their own machine.
Login access for this rollout:
Attach or embed this image so staff can see exactly where to click:
That’s the Process
Followed in this order, every step either references or builds on the one before it — the DPIA references the communication, the communication uses the settings decided in Step 2, and nothing gets deployed before staff have been told. Skipping the order, not just the steps, is usually where rollouts go wrong.
