GDPR for managed service providers: duties and costs

GDPR for managed service providers: who carries which duties

An MSP that runs systems for its customers acts as a processor, must meet the Article 28 and Article 32 duties, and must notify each affected customer of a breach. A customer or regulator now expects GDPR evidence from the provider that operates its systems, and that evidence comes from the MSP's own documented controls, not from a certificate. The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary, and only an independent auditor or accredited certification body can issue a report or certificate. An implementation partner can prepare systems, controls and evidence, but it cannot issue the assurance a customer asks for. The organization still owns its controls and remains responsible for them.

Cost, timing and scope depend on four things: how many customers' data the MSP holds, where that data is hosted, who can reach it remotely, and how many sub-processors sit in the chain. Each customer contract may set different instructions, retention periods and notice terms, so the MSP has to track them per customer. Remote administration from outside the EEA is a transfer under the EDPB's Guidelines 9/2022 context, even when an engineer only views data for support, so the MSP should map every administrative access path before any quote is agreed. Ask the implementation partner to state in writing which customers, hosting locations, access paths and sub-processors are in scope.

Which processor duties an MSP must meet before customers sign

Before an enterprise customer signs, a managed service provider or IT outsourcer must be able to show that it can be trusted with the data, that it will act only on instructions, and that it will speak up when an instruction looks unlawful. The cards below set out the duties customers test first, the evidence they will ask for, and the internal owner who should hold it.

Sufficient guarantees for the customer

Article 28(1) lets a controller use only processors that provide sufficient guarantees to apply appropriate technical and organisational measures. For an MSP, the customer will ask how it proves this across every service it runs, not only in general terms. Expect requests for a written description of the controls around the managed platform, named security roles, and evidence of staff screening and training. Owner: the CISO or head of service delivery, with the DPO reviewing the contract wording.

Processing only on documented instructions

An MSP may process customer data only on the customer's documented instructions, including when transferring data outside the EEA. In practice, every administrator action on customer data should trace back to a ticket, a runbook or a signed scope of work. Customers will ask for the instruction register, how changes to scope are recorded, and who may approve them. Owner: the service delivery manager, who keeps the instruction records current.

Flagging unlawful instructions immediately

Under Article 28(3), second subparagraph, the processor must immediately inform the controller if it believes an instruction infringes the GDPR or other data protection provisions. An MSP that runs a customer's systems is often best placed to spot a risky migration, a bulk export or an unlawful transfer request. Customers will ask for the escalation path, the named contact, and examples of past flags handled. Owner: the DPO or privacy lead, with the account manager as the first point of contact.

Security of processing under Article 32

Article 32 requires the processor, like the controller, to apply security measures suited to the risk. For managed services this covers the systems the MSP administers: hardening, access control, patching, logging and backups. Customers will ask for the security baseline for each managed platform, the most recent test results and how gaps are tracked to closure. The regulator's decision against Miljödata, which cited inadequate checks when installing new software and no real-time intrusion monitoring, shows what falls short. Owner: the head of security operations.

Liability for acting outside instructions

Article 82(2) makes a processor liable for damage where it breaches processor obligations or acts outside lawful instructions. An MSP should understand that a single administrator acting beyond scope can create liability for the provider, not only the customer. Customers will look for contract terms on liability and indemnity, insurance cover and the internal rules that limit privileged access. Owner: legal counsel, working with the CFO on insurance.

Becoming a controller when setting purposes

Under Article 28(10), a processor that determines the purposes and means of processing becomes a controller for that processing. An MSP that starts using customer data for its own analytics, product improvement or new services can cross this line without noticing. Customers will ask the MSP to confirm in writing that it uses their data only for the contracted service, and will check the logs and contract scope. Owner: the DPO, who reviews new data uses before launch.

What the Miljödata fine shows about security expectations

The Swedish supervisory authority, IMY, fined the IT service provider Miljödata SEK 1,800,000 (about EUR 160,000) under Article 32(1) of the GDPR. The decision of 22 September 2026 followed a 2025 cyberattack that affected 2.2 million people. The regulator cited two failings: inadequate checks when new software was installed, and no automated real-time monitoring for intrusions or suspicious activity. For an MSP, these map to two things it should be able to show on request. The first is a documented change and release process for systems it runs, with checks before new software goes live, recorded approvals and a way to roll back. The second is monitoring that detects intrusions and suspicious activity automatically and raises alerts to people who can act on them, with the alert history kept as evidence.

Read the decision with its limits in mind. It concerns one provider's measures, assessed against the facts of one incident, and it does not set a rule that every MSP or hosting company must meet in a particular way. Before relying on it in a customer conversation, read the EDPB national news item on the decision, which summarizes the regulator's wording, and confirm the full decision text with the authority if your contracts depend on it. Do not present the fine as a benchmark of what a compliant monitoring tool or change process looks like.

The practical question for a provider is whether its own records would survive the same questions. Ask which installation checks apply to each managed system, who signs off on them, and whether a failed check blocks deployment. Ask what monitoring covers each customer environment, where alerts are sent, who responds out of hours, and how long detection takes. An outsourcer that cannot answer these with logs and tickets is in the position Miljödata was in, whatever its contract says. Your Article 28 terms and security schedule should match what you actually run, and the evidence should exist before a customer or regulator asks for it.

Who does what when an MSP runs customer systems

When an MSP runs systems that hold customer personal data, it usually acts as a processor. Under Article 28(1), a controller may use only processors that provide sufficient guarantees to implement appropriate technical and organisational measures. The MSP must show those guarantees through its own operations, not only through its marketing.

Processor contract: Agree a written contract that sets out the subject matter, duration, nature and purpose of processing, the data types and the instructions the MSP will follow.
Security measures: Run the controls the MSP has promised, including configuration baselines, patching, access reviews and monitoring for intrusions. Regulators have criticised providers for weak checks when new software is installed and for missing real-time monitoring.
Breach notice: Report each incident to every affected controller without waiting to assess the risk. Under EDPB Guidelines 9/2022, the controller is in principle aware once the processor has informed it.
Remote access: Treat remote administration from outside the EEA, even viewing data for support, as a transfer that needs a valid mechanism.
Evidence: Prepare logs, runbooks, change records and configuration evidence that show what was done, when and by whom.

Before you sign, confirm that the MSP's own operations match each clause of the contract, because the contract alone does not satisfy Article 28.

When remote administration from outside the EEA counts as a transfer

Remote administration from a third country is a transfer under the GDPR even when the engineer only looks at data and changes nothing. The EDPB's Guidelines 9/2022 on breach notification say that remote access from a third country, including viewing data for support or administration, counts as a transfer, and that storing data in a cloud outside the EEA offered by a service provider also counts. The EDPB's Guidelines 05/2021 on the interplay between Article 3 and Chapter V explain the wider test for when a transfer exists. For an MSP, the practical question is not where the company is headquartered but where every person and system that can reach customer data sits, and this applies to follow-the-sun help desks, engineers working from home abroad, offshore monitoring teams and sub-processors' support staff.

Start by mapping access paths for each customer environment: VPN and bastion hosts, remote desktop and privileged access tools, ticketing systems that hold database extracts, backup consoles, log platforms and hypervisor management. For each path, record the country of the administrator, the country where the tooling and logs are hosted, and whether any sub-processor sits in the chain. Where the answer is outside the EEA, the controller and processor need a lawful transfer mechanism before that access starts. The main options are an adequacy decision, such as the EU-US Data Privacy Framework under Commission Implementing Decision (EU) 2023/1795, or standard contractual clauses under Commission Implementing Decision (EU) 2021/914, which must be backed by a transfer impact assessment. The Data Privacy Framework is subject to the pending appeal in Case C-703/25 P, *Latombe v Commission*, so confirm the current status of that appeal with counsel before relying on it for any customer.

Treat the mapping as a living record, not a one-time exercise. Each new engineer location, outsourced shift or sub-processor change can create a new transfer, and customer contracts often require advance notice of such changes. Ask your counsel to confirm which mechanism applies to each access path and whether the customer's own transfer analysis needs your input. Your team should also be able to show which administrators accessed which environments from which locations, so that the customer and any supervisory authority can see the actual access pattern rather than a general policy statement.

Choose a hosting and remote access model that fits the transfer rules

This table compares four ways an MSP can host customer systems and administer them, from fully EEA-based administration to customer-controlled access through jump hosts. Read each row against the transfer rules: any remote view of personal data from a third country counts as a transfer, so the model you pick sets how much documentation and transfer analysis you must carry. The main takeaway is that the fewer third-country access paths you allow, the less transfer work you own.

Model	When it fits	What the MSP must document	Effort at a high level
EU-hosted, all administration from inside the EEA	Customers that require EU-only handling of personal data and have no need for out-of-hours support from outside the EEA	Hosting locations, administrator locations, access roles, and the processor instructions covering who may administer systems	Lowest transfer effort, but staffing and follow-the-sun coverage must be planned within the EEA
EU-hosted, some third-country support under an adequacy decision	Support staff sit in a country covered by an adequacy decision, and the customer accepts that access route	Which countries staff connect from, the adequacy basis relied on, and the sub-processor and instruction records covering that access	Moderate: confirm the adequacy basis still applies and keep it current with the Commission's list of decisions
EU-hosted, third-country support under standard contractual clauses and a transfer impact assessment	Support must come from a country without an adequacy decision, or the MSP cannot rely on an adequacy route for that country	Executed transfer clauses, a transfer impact assessment for each importing country, supplementary measures, and records of every remote access event	Highest: each third-country access path needs its own assessment, and the assessment must be reviewed when circumstances change
Customer-controlled administration through jump hosts and session recording	Customers want to approve, observe and record every administrative session on their own infrastructure	Jump host design, named accounts, session recording and retention, approval workflow, and what the MSP can and cannot do without customer action	Moderate to high: effort shifts to building and running the access platform and to handling customer approvals on time

How to choose an auditor, consultant or implementation partner

Outside help with GDPR for managed service providers can cover readiness, evidence and testing, but none of it replaces the controller's or processor's own responsibility. The cards below set out what to check in an auditor, consultant or implementation partner before any contract is signed.

Confirm independence and accreditation

The GDPR requires no audit or attestation, and Article 42 certificates are issued only by accredited certification bodies or supervisory authorities. Any firm that offers a GDPR certificate should show you who accredited it and under which scheme. Ask whether the assessor has any role in designing or running the controls it will later judge. Ask: who accredited you for this specific certification, and can we see the accreditation scope?

Check processor contract and incident experience

A managed service provider serving many customers must handle one incident across several contracts, each with its own notice terms. Ask whether the consultant has drafted Article 28 terms for processors and worked through a breach that touched several controllers at once. Experience with processor contracts and multi-customer incident handling matters more than general privacy knowledge. Ask: show us a processor agreement and an incident notice you have prepared for a service provider with multiple customers.

Prepare evidence, do not sign reports

A consultant or implementation partner can prepare systems, policies, logs and records for review. Only an independent auditor or certification body issues a report or certificate. Confirm in writing that the partner will not present itself as the assessor and will not sign attestations on your behalf. Ask: which deliverables will you produce, and which will the independent assessor issue?

Agree a fixed written scope first

Scope defines which systems, customer environments, sub-processors and processing activities are covered. Without it, you cannot tell whether an incident, a remote support path or a backup location falls under the work. A fixed scope with named deliverables and timelines, agreed before work starts, makes the quote comparable across firms. Ask: what is in scope, what is excluded, and what triggers a change order?

Map sub-processors and remote access

The partner may itself use sub-processors, and its engineers may view customer data from outside the EEA for support. Under the EDPB's approach, remote access from a third country, even read-only viewing, counts as a transfer. Ask for a named list of every party and location with access, and whether each engineer's access is logged. Ask: where are your engineers located when they access our systems, and which sub-processors can see customer data?

Define what you keep at the end

When the engagement ends, you should own the documentation, configuration records, runbooks, access logs and evidence packs, and know how they are stored. Confirm how credentials and administrative access are revoked and how data held by the partner is returned or deleted. Without this, you may depend on the partner to explain your own systems. Ask: what exactly will we receive at close-out, in what format, and how are our credentials and partner-held data removed?

How an MSP prepares GDPR evidence for customer audits

This sequence turns a managed service provider's scattered operational knowledge into a set of role maps, transfer records, tested procedures and per-customer evidence packs that a customer can check against Article 28 and Article 32. The MSP owns each artifact, and an outside partner may prepare some of them.

Map each customer's data flows and roles
For every customer, list the systems you run for them, the personal data those systems hold, where it is stored and backed up, and which party decides purposes and means. Confirm whether you act as processor for that activity or whether any function has moved you toward controller status under Article 28(10). The output is a role map per customer and a data flow diagram that your team signs off. Done means every system in scope is tied to a customer, a data category and a stated role.
Inventory sub-processors and third-country access paths
Record every sub-processor, hosting location and support path that touches customer data, including your own engineers and vendors who can see data during administration. Flag any remote access from outside the EEA, even read-only viewing for support, because the EDPB's Guidelines 9/2022 treat that as a transfer. The output is a sub-processor register and a transfer register that names the transfer mechanism for each third-country path. Done means every access path has a documented owner and a mechanism or an explicit decision to stop it.
Align Article 28 terms and the sub-processor list
Compare each customer's processing agreement with what you actually do, covering instructions, confidentiality, sub-processor authorisation, assistance with rights and breaches, deletion or return, and audit cooperation. Check that the sub-processor list you publish matches the register from the previous step and that the notice and objection terms in each contract are the ones you follow. The output is a clause-by-clause deviation list and a current sub-processor list per customer. Done means legal and operations have agreed the gaps and each gap has an owner, whether that means amending the contract or changing the service.
Assess and document Article 32 measures
Assess the security measures that protect the customer systems you operate, based on the risks you identified in the data flow work. Cover change control for new software and configuration, access management for administrators, encryption, backup and restore testing, and logging with monitoring that can detect intrusions. The IMY's 2026 fine against Miljödata cited inadequate checks when installing new software and no automated real-time monitoring, so test those two areas first. The output is a control narrative with evidence for each measure. Done means each measure names the system it covers and the record that proves it operated during the review period.
Write and test a multi-customer breach runbook
Write a runbook that starts when you detect an incident affecting any customer and ends with notice to each affected controller. The runbook must cover how you scope which customers are hit, how you give each controller the information it needs, and who approves communications. Under the EDPB's Guidelines 9/2022, you do not assess likelihood of risk before notifying, because that judgement belongs to the controller, so the runbook should not wait for it. Run at least one tabletop exercise that covers several customers at once. The output is a tested runbook, a contact register for each controller and an exercise record. Done means the exercise shows that every affected customer can be notified from your records.
Assemble audit-ready evidence packs per customer
For each customer, collect the role map, sub-processor and transfer records, contract deviations, control evidence and breach test records into one pack, indexed to the audit questions the customer is likely to ask. Confirm that the pack reflects the customer's own scope and does not expose other customers' data. The output is a dated evidence pack that a customer's assessor can review. Done means a person outside the delivery team can locate the answer to each Article 28(3)(h) audit request in the pack within the review. An outside partner can help assemble packs, but you decide what each pack says and remain responsible for its accuracy. Confirm with your partner and your customers what they expect in each pack before work begins.

What usually delays an MSP's GDPR work or inflates its cost

Most delays in an MSP's GDPR work come from unclear roles, hidden data flows and paperwork that does not match the systems. Each card below names one pitfall that tends to add rework, and one check to run before the work starts, so the scope and quote reflect what the platform actually does.

Treating the MSP as controller by default

Many service contracts label the provider a controller, or say nothing at all, and teams assume the label settles the question. Under Article 28, a processor that only follows the customer's instructions is a processor, but a provider that decides purposes or means becomes a controller for that processing and carries its own duties. Check each processing activity separately, such as hosting, patching, log analysis and support tickets, and confirm the role in writing with each customer before scoping the work.

Overlooking engineers working from abroad

Remote administration is often the largest transfer an MSP makes without noticing. The EDPB's Guidelines 9/2022 treat remote access from a third country as a transfer even when the engineer only views data for support, and the same applies to storage in a cloud outside the EEA run by the provider. Map where support staff sit, which accounts they use and whether follow-the-sun rotations reach outside the EEA, then choose a transfer mechanism before the access starts.

Scoping only the core platform

Scope documents usually list the production application and its database, while monitoring, backup, ticketing and logging tools also hold personal data such as IP addresses, user identifiers, configuration dumps and copies of records. These systems are often administered by different teams and sit in separate accounts. Inventory them, record each one in the processing records and apply the same Article 32 controls to backups and telemetry as to the primary system.

No evidence of change checks

Regulators look for proof that changes were checked before they reached production. In the Miljödata decision, the Swedish IMY cited inadequate checks when installing new software, alongside the lack of automated real-time intrusion monitoring. Keep records of change requests, peer review, test results, approval and rollback plans for every release or patch, and make sure the ticketing system links each change to a named approver.

Breach runbook that notifies only the parent

Where one provider serves several customers, a single incident can affect many controllers. EDPB Guidelines 9/2022 require the processor to report to each affected controller, and the processor does not need to assess the likelihood of risk first. A runbook that informs only the parent company or the largest client leaves the other controllers unable to meet their 72-hour window. Build a contact matrix per customer, test it with a tabletop exercise and record each notice sent.

Sub-processor lists that drift

Sub-processor lists go stale when a provider adds a backup vendor, a managed monitoring service or an offshore support partner and forgets to update the customer list. Under Article 28, controllers must be able to name each sub-processor at any time and object within the period set in the contract. Assign one owner to the list, tie every new tool or vendor to a pre-onboarding check, and send notices before the new processing starts.

Questions MSPs and IT outsourcers ask about GDPR

Is a managed service provider always a processor under GDPR?

No. The role is decided for each processing activity by the facts, not by the label in the contract. An MSP that runs infrastructure on a customer's instructions is usually a processor, but an MSP that decides why or how personal data is used for its own purposes can become a controller for that activity, as explained in EDPB Guidelines 07/2020 on the concepts of controller and processor. Map each service you provide (backup, patching, helpdesk, monitoring, remote administration) to a role, and confirm the role with each customer in writing. Under Article 28(10), a processor that starts deciding purposes and means is treated as a controller for that processing.

Does GDPR require our MSP practice to be certified?

No. The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the responsibility of the controller or processor for compliance. Customers may still ask for third-party evidence, such as an ISO/IEC 27001 certificate or a SOC 2 report, as one input to their own assessment of sufficient guarantees. Only an independent auditor or certification body issues such evidence. Ask each customer which evidence their procurement team accepts before choosing a framework to prepare for.

How much effort does audit preparation take for an MSP, and what drives it?

The effort depends on the number of customers, the number of locations and data centers, the number and change rate of sub-processors, and how mature your evidence already is. Most of the work is not a single project but a set of recurring records: processor contracts, a current sub-processor list, transfer assessments, access reviews, patch and change logs, and breach runbooks. Teams with consistent tooling that already produces logs and approvals usually need less time to answer a customer audit request than teams that assemble evidence by hand for each one. Ask any outside party for a fixed-scope estimate tied to these drivers rather than a generic figure.

Can our MSP prepare for GDPR without outside help?

Yes, if you have people with privacy and security skills and the time to keep records current. In-house teams usually handle processor contracts, instructions, access controls and logging well. Outside help is common for specific tasks: reviewing processor agreements across many customers, assessing transfers when remote administration happens from outside the EEA, running independent security tests, and building a breach process that covers every affected customer. Define which tasks you keep and which you buy before you start, and write the scope down so the work and its outputs are clear.

What do we need from our customers to prepare GDPR evidence?

Customers provide the facts that only they can confirm. Ask each customer to confirm its controller role, the categories of personal data and data subjects in the systems you run, the locations where data is stored, and which of its staff may request access or changes. You also need agreed instructions, a named contact for breach notices, and a decision on whether the customer authorises sub-processors by general or specific approval. Without these inputs, a data map and a processor record cannot be complete, and an audit request cannot be answered accurately.

Can a single security incident lead to a GDPR fine for an IT service provider?

Yes. In a 2026 decision, Sweden's IMY fined the IT service provider Miljödata SEK 1,800,000 (about EUR 160,000) under Article 32(1) after a 2025 cyberattack affecting 2.2 million people. The authority cited inadequate checks when installing new software and no automated real-time monitoring for intrusions or suspicious activity. The lesson for MSPs is that regulators examine the provider's own controls, not only the customer's. Review how software is checked before deployment and whether intrusion monitoring runs continuously across the systems you operate.

What must an MSP do when a breach affects several customers?

Under EDPB Guidelines 9/2022, a processor serving several controllers must report the incident to each affected controller. The processor does not need to assess the likelihood of risk first, because that assessment belongs to the controller, which is considered aware once the processor has informed it. The controller keeps the legal duty to notify the supervisory authority and affected individuals. Your contracts should state the notice channel and timing, and your runbook should identify every affected customer quickly enough to let each one meet its own deadlines.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the systems that hold customer personal data can be shown to meet your processor duties. We prepare systems and evidence for your assessments, while your organization owns its controls and an independent auditor or certification body issues any report.

How we scope

Engagements are fixed-scope, with systems, customer tenants and deliverables agreed in writing before work starts.
The written scope names which customer environments, remote admin paths and sub-processors are covered.
We confirm where each customer's data is stored and which support access paths reach it from outside the EEA.

How we build

We configure access controls, logging and intrusion monitoring for the platforms that hold customer personal data.
We document change checks for software installs and updates, so each new component has a recorded review before release.
We test security measures against the risk your services carry, and record gaps with owners and fixes.

How we hand over

You receive documented configurations, runbooks and evidence mapped to your processor obligations and Article 32 measures.
Breach notice procedures are written to notify every affected controller, with contact records kept current.
Handover sessions train your operations staff to run, monitor and produce the evidence themselves.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, agreed in a separate written scope.
We help prepare evidence packs for customer audit requests, while the customer or auditor decides what to accept.
Ask us to confirm which parts of the program remain your responsibility after handover.