GDPR for IT Support Companies and MSPs: How to Handle Client Data Compliantly
If you run an IT support company, a managed service provider (MSP), or work as an independent IT consultant, you process personal data every single day — often without realising just how much regulatory weight that carries.
When you remote into a client's server to troubleshoot an issue, you're accessing systems that contain employee records, customer data, financial information, and medical files. When your RMM tool collects device telemetry, that telemetry may include personal data. When you store a client's backup, that backup contains personal data belonging to hundreds or thousands of people who have never heard of your company.
Under GDPR, this makes you a data processor — and it comes with serious obligations.
This guide covers everything IT support companies and MSPs need to know to operate compliantly: the processor relationship, mandatory contracts, remote access tools, RMM sub-processors, breach notification obligations, and a practical compliance checklist.
Why IT Support Companies Are Almost Always Data Processors
The controller/processor distinction is the foundation of GDPR compliance for IT service providers.
A data controller decides why and how personal data is processed. Your clients — the organisations you support — are controllers. They determine what data their systems hold and what it's used for.
A data processor processes personal data on behalf of a controller. When you access a client's systems, configure their infrastructure, manage their backups, or run their helpdesk, you are processing their data on their behalf. That makes you a processor.
This distinction matters because:
- Processors have direct obligations under GDPR, not just contractual ones. Article 28 imposes specific requirements on processors independently of what a client contract says.
- Processors can be held directly liable by supervisory authorities for certain breaches — including breaches caused by acting outside client instructions, failing to notify a breach, or using unauthorised sub-processors.
- Processor status doesn't depend on whether you actively read the data. Having access to a system that contains personal data is enough.
The key question is not "do we see the data?" but "do we have access to systems where personal data is processed?" For IT support companies, the answer is almost always yes.
The Mandatory Data Processing Agreement (DPA)
Article 28 GDPR requires that every controller who uses a processor must have a written Data Processing Agreement in place before processing begins. This is a legal requirement — not a nice-to-have, not something to add later.
If you are providing IT support to any organisation that processes personal data about EU residents (which is essentially every business), you need a DPA with that client. Operating without one puts both you and your client in breach of GDPR.
What Your Standard DPA Must Include
Your DPA template should cover the following mandatory elements:
Subject matter and duration: What systems are in scope, and for how long the engagement runs.
Nature and purpose of processing: What types of IT support activities you will carry out (remote support, monitoring, backup, patch management, etc.) and why those activities require access to personal data.
Categories of personal data and data subjects: What types of data the client's systems contain — employee records, customer data, patient records, financial records — and who those data subjects are.
Processor obligations: That you will only process data on documented instructions from the client, ensure staff are bound by confidentiality, implement appropriate security measures, assist with data subject rights requests and breach notifications, delete or return data at the end of the contract, and provide audit assistance.
Sub-processor authorisation: Either a list of specific authorised sub-processors or a framework for approving new ones. Your RMM tools, remote access software, and backup platforms are all sub-processors (more on this below).
International transfers: If you use any tools that transfer data outside the UK/EEA, the DPA must address the transfer mechanism (Standard Contractual Clauses, adequacy decision, etc.).
Make the DPA part of your standard onboarding documentation. Never begin accessing a new client's systems without it signed.
Remote Access Tools: TeamViewer, AnyDesk, ConnectWise, and the Data They Process
Remote access is the bread and butter of IT support — and it creates a direct data processing relationship that many MSPs have never properly documented.
When you use TeamViewer, AnyDesk, ConnectWise Control, or a similar tool to access a client's system, you are:
- Transmitting screen content that may include personal data visible on the desktop
- Accessing files and applications that contain personal data
- Creating session logs that may record the personal data you encountered
- Storing session recordings if you record support sessions
From a GDPR perspective, each of these activities constitutes processing of personal data. The remote access software vendor is a sub-processor — they transmit and may temporarily store data relating to your support sessions.
What You Need to Do
Review your vendor's DPA: TeamViewer, AnyDesk, and ConnectWise all offer Data Processing Agreements. Ensure you have executed the relevant DPA with your remote access vendor before using their tools on client systems.
Include remote access tools in your client DPA: Your DPA with the client should identify your remote access tool by name as an authorised sub-processor.
Limit session recording retention: If you record support sessions, set a defined retention period and delete recordings when they are no longer needed for the stated purpose. Don't accumulate years of recordings by default.
Train technicians on data minimisation: Technicians should avoid accessing or dwelling on personal data that isn't relevant to the support task. If a file browser window shows personal data, don't read it if it's not relevant to the ticket.
RMM Tools as Sub-Processors: Datto, NinjaRMM, Atera, and Others
Remote Monitoring and Management (RMM) tools are at the core of every MSP's operations. They also represent your highest-volume, most continuous data processing activity — and they are sub-processors under GDPR.
When your RMM agent runs on a client's endpoint, it typically collects:
- Hardware inventory (device identifiers, serial numbers)
- Software inventory (installed applications)
- User account information (usernames, last login times)
- Network configuration details
- Event logs (which may contain personal data — logon events, application errors with user context)
- Alert data triggered by user activity
This telemetry stream processes personal data on a continuous basis. Your RMM vendor — whether that's Datto, NinjaRMM (now NinjaOne), Atera, ConnectWise Automate, or another platform — is processing that data on your behalf, making them a sub-processor of a sub-processor from your client's perspective.
Compliance Steps for RMM Tools
Execute the vendor DPA: Datto, NinjaOne, Atera, and ConnectWise all publish DPAs. Locate and sign the current version for each platform you use.
List RMM tools in your client DPA: Clients must know which sub-processors you use. Name your RMM platform specifically.
Review data residency: Understand where your RMM platform stores telemetry data. If it's stored outside the UK/EEA, ensure the appropriate international transfer mechanisms are in place.
Configure data retention: Most RMM platforms let you configure how long monitoring data is retained. Set retention periods that align with the principle of storage limitation — don't retain device telemetry indefinitely.
Conduct periodic sub-processor reviews: If you switch RMM platforms or add a new tool, notify clients before the change if your DPA requires it (many templates require 30 days' advance notice of sub-processor changes).
Handling Client Employee Personal Data During Support Tickets
Every support ticket has the potential to expose personal data. The employee submitting the ticket provides their name and contact details. The ticket description may contain sensitive personal information — "my GP results aren't uploading", "I can't access HR system", "my messages to John are missing". The troubleshooting process may require access to that employee's files, email account, or browser history.
Your Obligations During Ticket Handling
Process only what is necessary: Access only the data and systems needed to resolve the specific issue. Don't explore adjacent files or data that aren't relevant to the ticket.
Handle health and sensitive disclosures appropriately: If an employee's ticket reveals health information or other sensitive personal data, treat it with particular care. Don't include unnecessary sensitive detail in ticket notes.
Secure your ticketing platform: Your helpdesk software — whether Freshdesk, Zendesk, HaloPSA, Autotask, or another tool — holds personal data about your clients' employees. That platform is another sub-processor. Ensure it is listed in your client DPAs and that you have executed the vendor's DPA.
Define retention for closed tickets: Establish a retention period for closed support tickets and automate deletion where possible. Retaining tickets indefinitely because "we might need them" is not consistent with the storage limitation principle.
Restrict access by client: Technicians should only be able to see tickets from the clients they support. Don't allow one client's data to be visible to technicians working on other accounts.
Data Breach Obligations: The 72-Hour Notification Chain
This is where many IT support companies have their most significant compliance gap — and where the consequences can be most severe.
When you discover a data breach on a client's systems — ransomware, data exfiltration, accidental exposure, unauthorised access — a specific chain of obligations is triggered.
The Chain Works Like This
You (the processor) discover the breach. You have an obligation under Article 33(2) GDPR to notify your client (the controller) without undue delay after becoming aware. The ICO's guidance suggests this means as soon as practically possible — in most cases within hours, not days.
The client (the controller) assesses the breach. They determine whether it is likely to result in a risk to individuals' rights and freedoms.
If yes, the controller must notify the relevant supervisory authority (ICO in the UK, or the relevant EU DPA) within 72 hours of becoming aware of the breach.
If the breach is likely to result in a high risk to individuals, the controller must also notify the affected individuals directly.
The 72-hour clock starts when the controller becomes aware — which means your notification to the client is what starts that clock. Delay your notification, and you directly compromise your client's ability to meet their legal deadline.
What IT Support Companies Must Do
Have an incident response procedure: Before a breach happens, know what you will do. Who do you call? What do you document? When do you notify the client?
Your DPA should specify your notification obligations: The DPA should include your obligation to notify the client without undue delay and specify the information you will provide (nature of the breach, categories and approximate number of records affected, likely consequences, measures taken or proposed).
Document everything: If you discover a breach, log the time of discovery, what you found, what immediate steps you took, and when you notified the client. This documentation protects you.
Don't investigate in isolation: If you discover a breach, notify the client immediately. Don't spend hours investigating before telling them — you may be eating into their 72-hour window.
Note that as a processor, your breach obligations are to your client — not directly to the ICO. The controller notifies the ICO. You notify the controller.
Backup and Disaster Recovery as Data Processing
Every backup you take is a copy of personal data. Every disaster recovery test that restores a backup involves processing that personal data. This is often the highest-volume data processing activity an MSP conducts — and it is frequently treated as a purely technical function with no GDPR consideration.
What You Need to Address
Backup destinations are sub-processors: Datto BCDR, Veeam Cloud Connect, Azure Backup, Wasabi, Backblaze B2 — wherever client backups are stored is a sub-processor. Each of these needs to be in your client DPA.
Encryption is not optional: Client backup data must be encrypted in transit and at rest. This is both a GDPR Article 32 requirement and basic due diligence.
Retention must match client policy: Your backup retention schedules should align with the client's data retention requirements. Retaining seven years of daily backups when the client's retention policy requires two years creates compliance problems.
Restoration creates a new processing activity: When you restore a backup — even for a test — you are creating new access to personal data. Log restorations and ensure they are conducted only by authorised personnel.
Cross-border storage: If backups are replicated to data centres outside the UK/EEA, ensure the appropriate international transfer mechanisms are in place and disclosed to clients.
Password Managers and Credential Handling
MSPs accumulate credentials — admin passwords, service account details, API keys, portal logins — for every client they manage. This credential store represents a significant data processing activity that is frequently under-governed.
The GDPR and Security Angle
Shared credentials are a security and compliance problem: Generic admin accounts shared across the MSP team make audit trails impossible. If something goes wrong, you cannot demonstrate who accessed what system at what time. GDPR's accountability principle requires you to be able to demonstrate compliance — this requires individual accountability in access logs.
Your password manager is a sub-processor: Platforms like 1Password Teams, Bitwarden Business, or IT Glue hold credentials that provide access to systems containing personal data. They need to be covered in your security framework and disclosed where relevant.
Privileged access should be documented: For each client, document what level of access your technicians have and why. Privileged access that goes beyond what is needed for the service scope violates the data minimisation principle.
Offboarding requires immediate credential rotation: When a technician leaves your company, all credentials they had access to should be rotated immediately. GDPR's security requirements under Article 32 apply to who has access to client systems at all times.
End-of-Contract Data Return and Deletion Obligations
When a client relationship ends, your obligations don't end with it. Article 28 requires that processors, at the choice of the controller, either return all personal data to the controller and delete existing copies, or delete all personal data and confirm this in writing.
What This Means in Practice
Your DPA should specify the post-termination procedure: On contract termination, will you return data, delete it, or both? What is the timeframe? Who receives written confirmation?
Backups must be deleted: This is the most practically challenging element. If you hold three years of client backups, those backups must be deleted within the timeframe specified in your DPA. Retaining client backups indefinitely after contract termination is a GDPR breach.
RMM agents must be removed: Remove your RMM agent from all client devices promptly after contract termination. Continuing to collect telemetry from a former client's systems is processing without a legal basis.
Ticketing records must be handled: Closed tickets containing the former client's employee data must either be returned (unlikely to be practical) or deleted in accordance with your retention policy.
Get confirmation in writing: Issue a written data deletion certificate to the client after completing the deletion process. This protects both parties.
IT Support and MSP GDPR Compliance Checklist
Contracts and Legal Basis
- [ ] Data Processing Agreement in place with every active client
- [ ] Sub-processor list maintained and kept current (remote access tools, RMM, backup platforms, ticketing, password manager)
- [ ] DPA includes international transfer mechanisms where applicable
- [ ] Client DPAs updated when sub-processors change
Remote Access and RMM
- [ ] DPA executed with TeamViewer / AnyDesk / ConnectWise / [your tool]
- [ ] DPA executed with NinjaOne / Datto / Atera / ConnectWise Automate / [your RMM]
- [ ] Session recording retention policy defined and enforced
- [ ] Technician training on data minimisation during remote sessions
Helpdesk and Ticket Handling
- [ ] Ticketing platform DPA executed
- [ ] Client data segregated within ticketing system
- [ ] Ticket retention period defined and automated deletion configured
- [ ] Sensitive data in tickets handled and classified appropriately
Data Breach Response
- [ ] Incident response procedure documented
- [ ] DPA specifies processor breach notification obligations
- [ ] Breach notification log template ready
- [ ] Out-of-hours escalation path for breach discovery defined
Backups and DR
- [ ] All backup destinations identified as sub-processors and included in client DPAs
- [ ] Backup encryption verified (in transit and at rest)
- [ ] Backup retention schedules aligned with client retention requirements
- [ ] Cross-border storage transfers documented
Access and Credential Management
- [ ] Individual accounts used for client system access (no shared admin accounts)
- [ ] Password manager DPA executed
- [ ] Technician offboarding procedure includes immediate credential rotation
- [ ] Privileged access documented and limited to service scope
End of Contract
- [ ] Post-termination data deletion / return procedure defined in DPA
- [ ] RMM agent removal included in offboarding procedure
- [ ] Backup deletion confirmed and certified in writing
- [ ] Former client records deleted within defined timeframe
If you are not sure whether your website and client-facing systems are leaking personal data or sending it to undisclosed third parties, start with a scan. Run your website through Custodia's free privacy scanner to identify trackers, data flows, and compliance gaps in 60 seconds — no account required.
This guide provides general information about GDPR as it applies to IT support companies and MSPs in the UK and EU. It does not constitute legal advice. Your specific obligations depend on your service scope, client contracts, and the data you process. Consult a qualified data protection professional for advice specific to your situation.
Top comments (0)