GDPR self-hosted platforms: what changes and what stays

Does self-hosting GDPR-compliant platforms reduce what we must do?

Self-hosting usually removes processors and transfer routes, but it does not remove controller responsibility. Under Articles 24, 25 and 32, the organization that determines the purposes and means of processing remains answerable for its measures, its default settings and its security wherever the platform runs. If a customer, contract or regulator asks for evidence, the question is not whether a vendor is involved but whether your own team can show what the controls are, who operates them and how they were tested. Removing a SaaS provider removes a processing contract and its sub-processors from the chain, which simplifies the supplier list. It does not remove a single obligation owed to the data subject.

The effort moves inside the organization rather than disappearing. Storage on your own infrastructure is still processing, so the work shifts to detecting breaches early enough to notify the supervisory authority within 72 hours under Article 33(1), restoring availability in a timely manner under Article 32(1)(c), testing security measures regularly under Article 32(1)(d) and answering rights requests within one month under Article 12(3). How much of this is new work depends on where the data sits, whether it stays in the EEA and administered only by your own staff, and whether your team already runs logging, backup and patching for production systems. Confirm these points for each platform before you estimate effort, and ask whether a remote support provider in a third country will see data, since that access would be a transfer.

The GDPR requires no audit, attestation or certificate, so no outside party is needed to make a self-hosted platform lawful. Certification under Article 42 is voluntary, and an independent auditor or accredited certification body is the only party that can issue a report or certificate. An implementation partner such as DeployOpen can prepare the systems, configuration and evidence, but it does not issue those reports. Ask any partner to state its role in writing, and ask your own assessor, customer or regulator which evidence they will accept before you commit to a scope.

Who is paid for what when self-hosting for GDPR

This table shows who carries each cost when an organization runs open-source platforms on its own infrastructure to meet GDPR security and accountability duties, and whether each cost is one-time or recurring. Use it to decide which work stays in-house and which to scope with an implementation partner. DeployOpen does not publish prices; a quote follows from the written scope.

Cost component	Who is paid	One-time or recurring	What drives it
Internal platform and security staff	The organization's own employees, plus any contractors it hires directly	Recurring	Number of systems, rights request volume, patch cadence and how many people are needed to answer breach and rights duties within deadlines
Implementation partner for hardening and evidence	The implementation partner, under a fixed-scope written agreement	One-time, with optional recurring retainer for upgrades	Number of platforms, depth of Article 32 hardening, documentation needed for Article 24 and Article 25, and whether processing agreements or transfer assessments are in scope
Logging and monitoring tooling	Software licence or service provider, or open-source tooling run by the organization	Recurring, plus one-time setup	Log volume, retention periods, whether intrusion monitoring runs in real time, and whether alerts can meet the 72-hour notification clock under Article 33(1)
Backup and restore infrastructure	Cloud or data center provider, or the organization's own hardware and staff	Recurring storage, plus one-time design and restore testing	Data volume, retention, geographic location of copies, encryption key custody and how often restores are tested under Article 32(1)(c) and (d)
DPO or legal review where needed	Internal DPO, an external DPO service or outside counsel	Recurring for a DPO role, one-time for specific reviews	Whether a DPO is mandatory, the number of processing activities, DPIA volume and any transfer assessments for remote support or foreign authority access
Independent assessment if required	An independent auditor or certification body, never the implementation partner	Typically one-time per assessment cycle, then recurring	Whether a customer or contract requires it, the scope of systems tested, and the number of assessment rounds needed; the GDPR itself requires no audit or certificate

What makes self-hosted GDPR work cost more or less

Self-hosting moves cost from vendor contracts into your own staff, infrastructure and evidence work. The drivers below decide how much effort the GDPR obligations take, and each one is within your control if you set its limits early and in writing.

Number of systems and data categories

Every platform you run adds records of processing, access reviews, backup scopes, retention rules and rights-request paths. Costs rise fastest when one tool holds several categories of personal data, such as customer contacts, employee records and support tickets, because each category needs its own purpose, lawful basis and retention period. Limit the first phase to the systems that hold the most personal data, and inventory the rest before you deploy them. Ask your implementation partner to map each system to its data categories in the scope document.

Data location and remote access

Where data is stored and who can reach it decides whether a flow is a transfer. Data kept in the EEA and administered only by your own staff is not transferred, but remote support from a provider outside the EEA is. Each external access path adds a contract, a transfer assessment and monitoring work. Confirm in writing which support staff can reach production, from which countries, and through which session controls before you agree a support model.

Backup and log retention

Backups and logs are where personal data quietly accumulates and where erasure requests become hard to honor. Longer retention increases storage cost and the number of places an erasure must reach, while shorter retention can weaken breach investigation. Set retention periods per data category, document how restored backups handle deleted records, and confirm that backup copies sent outside your environment are encrypted with keys you or a trusted EEA entity control.

Staff capacity for 24/7 detection

The 72-hour clock in Article 33(1) starts when you become aware of a breach, so detection cannot wait for a Monday morning. Running systems in-house means your team, or a contracted monitoring service you control, must watch logs, alerts and availability around the clock. The IMY's 2025 fine on Miljödata cited missing automated real-time intrusion monitoring. Decide early whether you staff this internally, buy a monitoring service, or combine both, and price that choice before go-live.

Number of tenants or entities

Each tenant, legal entity or customer environment may need its own controller analysis, its own records, and separate access and retention rules. Shared instances across entities reduce infrastructure cost but complicate role separation, joint controller questions and deletion scopes. Decide the tenancy model before design, since splitting a shared platform later is far more expensive than designing separation at the start.

Evidence maturity

Regulators and customers judge your measures by the evidence they can see: configuration baselines, access reviews, change records, restore tests and incident logs. Teams that build this evidence as they deploy spend far less than teams that reconstruct it during an audit or complaint. Ask your partner to deliver evidence templates and an evidence calendar with each system, and confirm which artefacts your own staff will keep up to date after handover.

Which transfers and processors disappear

Running a platform on infrastructure you control removes some of the GDPR's external dependencies, but only the ones that actually leave your hands. The EDPB's Guidelines 05/2021 set the test: personal data kept in the EEA and administered only by your own employees is not transferred, even when one of those employees logs in from abroad (Example 8 of the guidelines). A remote support session from a provider in a third country is a different matter. Where a vendor's engineer in a non-adequate country can view or touch your data, that is a transfer under Chapter V (Example 11), and it needs a transfer mechanism and a transfer impact assessment before the access happens.

Check the vendor support model before you assume the transfer problem is gone. Ask who can reach your environment for patches, troubleshooting and incident response, from which countries, through which tools, and whether support staff can see personal data or only system metadata. Example 12 adds a second layer: an EU-established provider that is subject to third-country law may receive foreign authority requests, and complying with one would itself be a transfer. Assess that exposure before you sign, and record the answer in your transfer documentation. Confirm these points in writing with each vendor, since support arrangements change over time.

Backups are where many self-hosted designs quietly create a transfer. EDPB Recommendations 01/2020 accept encryption before data leave the organization as an effective measure for storage abroad only when the decryption keys stay solely with you or with a trusted entity in the EEA or an equivalent jurisdiction. If a backup provider outside that group needs data in the clear to process it, the Recommendations see no effective technical measure. For self-hosted platforms, decide who holds the key material for offsite and cloud backups, where key management runs, and whether any managed backup or disaster recovery service can access plaintext. Those answers determine whether your backup chain removes processors or adds them.

How a self-hosted GDPR readiness project runs

The project moves from defining what personal data the self-hosted systems hold to handing the controller a set of documented measures, tested workflows and evidence it can show a customer, complaint handler or supervisory authority. Each phase produces a named output, and the timeline follows the written scope.

Scope the systems and personal data
The organization and DeployOpen list every self-hosted platform in scope, the data categories each one stores or processes, the people whose data it holds, and the environments involved, including backups, logs, test copies and admin consoles. Staff from the business owner, IT and security attend, because the scope must match where personal data actually sits. The output is a written inventory of systems and data flows that the controller signs off. The step is complete when every system that holds personal data appears in the inventory with an owner.
Map controller and processor roles
For each flow, the team records who decides purposes and means and who processes data on the organization's behalf. Self-hosting does not change the controller, but it can remove external processors from the chain, so the map shows which contracts still apply and which sub-processors remain, such as a managed backup vendor or a remote support provider. Where a third party can access data from outside the EEA, the transfer question is recorded for the transfer workstream. The output is a role map with contracts linked to each relationship. The step closes when every external party has a documented role and a contract reference.
Document Article 32 measures and records
The team assesses the risk of each in-scope system and documents the technical and organizational measures chosen for it, covering access control, multi-factor authentication, encryption, logging, patching, backup and restore, and pseudonymisation where it fits. It also prepares the records of processing and the DPIA screening for high-risk activities. The output is a measures register tied to each system, with the reason each measure was chosen. The step is done when the controller has approved the register and each measure points to a named owner and an evidence source.
Implement logging, detection and tested restore
DeployOpen configures audit logging, centralized collection, alerting for suspicious access and intrusion monitoring in the client's environment, then sets up backups with defined restore procedures. The team runs a restore test and records the result, because Article 32 expects availability to be restored in a timely manner and measures to be tested regularly. Detection matters here because notification under Article 33 depends on noticing a breach in time. The output is a working monitoring setup, log retention settings and a restore test report. The step closes when alerts reach a named responder and a restore has been completed and documented.
Prepare rights-request and breach workflows
The organization and DeployOpen define how access, erasure, rectification and other requests enter the system, who verifies identity, how data is found across the platforms and backups, and how the one-month response period is tracked. The same phase writes the breach response procedure: who classifies an incident, who starts the 72-hour clock, what goes in the internal record, and how processors notify the controller. Tabletop exercises test both workflows against a realistic scenario built for this organization. The output is tested procedures with assigned roles. The step is complete when the team has run at least one exercise and recorded the gaps it found.
Hand over the evidence package
DeployOpen assembles the material the controller needs to show compliance: the system inventory, role map, measures register, records of processing, monitoring and restore evidence, rights and breach procedures, exercise reports and open actions with owners. The controller reviews it, decides which items go to customers or auditors, and confirms who maintains each item after handover. Independent auditors or certification bodies, where engaged, review the evidence on their own terms, since DeployOpen prepares systems and evidence but does not issue reports or certificates. The output is a versioned evidence package and a maintenance schedule owned by the organization. The step closes when the controller accepts the package in writing.

Detection, restore and rights duties that move inside

When a SaaS provider runs the platform, the provider usually detects the intrusion and restores the service, and your organization relies on contractual notice. On a self-hosted platform, your organization is the one that must notice. Article 33(1) requires notification to the supervisory authority within 72 hours of becoming aware of a personal data breach, and that clock does not wait for a forensic report. Confirm that logs from the application, database, reverse proxy, identity provider and operating system all flow to a central store, that alerts reach a named on-call role outside working hours, and that someone on the team can declare a breach without waiting for management approval. If a third party operates or supports the platform for you, the contract should require notice to you without undue delay so the clock can start on time.

The Swedish IMY fined the IT service provider Miljödata under Article 32(1) after a 2025 attack affecting 2.2 million people. The authority cited inadequate checks when installing software and no automated real-time intrusion monitoring (decision of 22 September 2026). Both gaps are yours to close on a self-hosted platform. Verify every release before installation, using signatures or checksums and a recorded change approval, and deploy intrusion detection that raises alerts in real time. Article 32(1)(c) also requires the ability to restore availability and access in a timely manner. Define recovery targets for each system, keep backups isolated from the credentials that administer the platform, and run restore tests on a schedule. Article 32(1)(d) asks for regular testing of these measures, so keep the test results as evidence.

Article 12(3) gives the controller one month to answer a data subject request, with extensions only in defined cases. On a self-hosted platform, the data is spread across the application database, search indexes, file stores, exports, logs and backups, and your team must find all of it. Before you rely on the platform for rights handling, test an access export and an erasure for one sample individual across every module that holds personal data. Document how deletion reaches backups and logs, including how restored backups are re-checked so erased data does not return. Ask the vendor or integrator to show these steps working in your environment, because whether a feature exists in the product is a different question from whether your deployment can meet the deadline.

Who owns which part of a self-hosted GDPR program

Under the GDPR the organization stays the controller once it runs a platform on its own infrastructure. Self-hosting does not change who determines purposes and means, so the controller keeps responsibility for the Article 24 measures, Article 25 design and default settings and Article 32 security wherever the processing runs. Several duties cannot be delegated to a vendor in any model, and they sit with your staff.

Controls and accountability: Deciding which Article 32 measures apply to each system, accepting residual risk and signing off the security posture.
Records and DPIAs: Maintaining the record of processing, approving data protection impact assessments and reviewing them when the processing changes.
Rights decisions: Judging identity, scope and exemptions for access, erasure and other requests, and answering within one month under Article 12(3).
Breach decisions: Deciding whether a personal data breach must be notified to the supervisory authority within 72 hours under Article 33(1), and whether affected individuals must be told.
DPO and processor oversight: Designating a data protection officer where required, and keeping the identity of every processor and sub-processor available at all times.

Confirm with your DPO or privacy lead which of these decisions have named owners and deputies outside business hours.",

What must exist before a customer or regulator review

A customer audit or regulator inquiry asks for the same core evidence whether the platform runs in SaaS or on infrastructure you control. The cards below cover what must exist on paper and in systems, and how to check each item before someone else does.

Current record of processing

The Article 30 record must list each self-hosted platform as a processing activity, with purposes, categories of data, recipients, transfers and retention. Check that the record names the controller entity, that it covers every instance including staging, backups and analytics copies, and that its last review date falls after your most recent platform change. A record that still describes the SaaS tool you replaced is a common gap.

Article 32 risk assessment

Article 32 requires security measures appropriate to the risk, and the risk assessment is the document that justifies them. For a self-hosted platform, it should cover the hosting environment, administrator access, the update path and the data the platform holds. Check that it is dated, names an owner, and links each identified risk to a specific control and to the evidence that control produces.

Access control with MFA

Administrative access to the platform, its database, its hypervisor and its cloud account is now your responsibility, not a vendor's. Check that privileged accounts are individually named, that multi-factor authentication covers every administrative path, and that access reviews are recorded with removals. Ask for an export of who held administrator rights on the review date, and compare it with the leaver list from HR.

Logging and alerting

Article 33 gives you 72 hours from becoming aware of a personal data breach to notify the supervisory authority, and that clock depends on detection. Confirm that authentication events, administrative actions, data exports and configuration changes are logged centrally, that logs are protected from the administrators they record, and that someone is alerted on suspicious activity. Test by triggering a known event and confirming it appears in the alerting path.

Tested backup and restore

Article 32(1)(c) requires the ability to restore availability and access to personal data in a timely manner after an incident, and Article 32(1)(d) requires regular testing of measures. A backup that has never been restored is not evidence. Check that backups are encrypted with keys held outside the platform, that restore tests have a recorded date, scope and result, and that the restored data was checked for the rights and retention rules that still apply to it.

Processor and sub-processor list including support access

Self-hosting removes some processors but rarely all of them. List every cloud, colocation, managed backup, monitoring and telephone or ticket provider that can reach personal data, along with any vendor engineer who gets remote access. Remote support from a third country is a transfer under EDPB Guidelines 05/2021, so record the location of each access path and confirm a contract exists for each processor.

Documented rights and breach procedures

Operators must be able to answer rights requests within one month under Article 12(3), and to decide, document and if needed notify breaches. Check that a written procedure exists for each, that the platform can locate and export one person's data across modules, and that a tabletop exercise has tested the breach path with named roles. Confirm where request and breach records are kept and who can approve a response.

Questions buyers ask about GDPR and self-hosted platforms

Does self-hosting make us GDPR compliant?

No. Self-hosting does not change who is the controller. The controller determines purposes and means under Article 4(7), and it remains responsible for the measures in Article 24, the design and default settings in Article 25, and security under Article 32 wherever the processing runs. Running a platform on infrastructure you control removes some obligations, such as a processor contract with the software vendor, but it moves rights handling, breach detection, restoration, testing and records inside your organization. Compliance is the result of those controls and their evidence, not of where the servers sit.

Do we still need a processor contract with the open-source vendor?

It depends on whether the vendor or anyone else processes personal data on your behalf. Storage is processing under Article 4(2), so a provider that stores or otherwise handles personal data for you is a processor under Article 4(8) and needs an Article 28 contract. A project maintainer who never receives your data has no processing role toward you. Where an implementation partner accesses your systems during delivery, or a hosting provider stores your data, those parties need written terms. EDPB Opinion 22/2024 also asks controllers to keep the identity of all processors and sub-processors available at all times and to verify their guarantees, with the depth of checks varying with risk. Confirm each party's access to personal data in writing before the engagement starts.

Does remote vendor support count as a transfer?

It can. Under the three criteria in EDPB Guidelines 05/2021, data kept in the EEA and administered only by your own employees is not transferred, even when an employee accesses it while abroad. Remote support access by a provider located in a third country, however, is a transfer (Example 11 of those guidelines). The same guidelines note that an EU provider subject to third-country law may receive foreign authority requests, and complying with one would be a transfer, so you should assess that before engaging the provider. Ask support providers where their staff sit, whether access to data in the clear is possible, and how sessions are logged and time-limited. Route any transfer through the GDPR's Chapter V tools, and check the current status of the EU-US Data Privacy Framework under Commission Implementing Decision (EU) 2023/1795.

How much internal effort does self-hosting create?

Your internal effort rises because the operational duties move in-house. The main recurring items are detecting breaches in time to notify the supervisory authority within 72 hours under Article 33(1), restoring availability in a timely manner under Article 32(1)(c), testing your security measures regularly under Article 32(1)(d), and answering rights requests within one month under Article 12(3). The cost drivers are the number of systems, the volume and sensitivity of personal data, how many staff hold administrative access, and how much monitoring and patching you run yourselves. One-time work includes the data mapping, architecture, hardening and documentation. Ongoing work includes monitoring, patching, backup tests, access reviews and rights handling. Ask any partner for a written scope that separates these items, and treat the output as an estimate until your own systems have been inventoried.

Can we run a self-hosted platform ourselves, or do we need a partner?

Yes, if your team has the skills and capacity to own the controls, and many organizations do. The GDPR does not require outside help. Your team needs to cover the installation checks, hardening, logging and real-time intrusion monitoring, backup and restore, access control, rights handling workflows and breach response. The Swedish IMY fined the IT service provider Miljödata under Article 32(1) after a 2025 attack affecting 2.2 million people, citing inadequate checks when installing software and no automated real-time intrusion monitoring (decision of 22 September 2026). Whoever operates the platform needs those controls. An implementation partner such as DeployOpen can plan, implement, harden, document and support the platform inside your own infrastructure, with scope agreed in writing before work starts, while your organization keeps ownership of the controls and their evidence.

Do we need an external auditor for a self-hosted platform?

The GDPR does not require an audit, attestation or certificate, so an external auditor is not a legal requirement. Certification under Article 42 is voluntary, and it does not reduce your responsibility for compliance. Customers, contracts or sector regulators may still ask for independent evidence, and in that case the auditor or certification body is the party that issues the report or certificate. An implementation partner prepares systems, controls and evidence but does not issue audit reports or certifications. Before engaging an auditor, confirm which framework your customer or regulator expects, the scope of systems covered, and whether the auditor's work will produce a document you can share.

How DeployOpen works on this

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so the controller keeps control of where personal data sits and who can reach it. We prepare the systems, controls and evidence that support your GDPR accountability, while your organization owns the decisions and the independent assessor issues any report.

How we scope

Written scope names the platforms, data categories, hosting locations and processing activities covered by the engagement.
We map which services would remain processors, which sub-processors are removed and which remote access paths could create a transfer.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.

How we build

We configure access control, encryption, logging and backup for the platforms according to the agreed Article 32 risk assessment.
We set up monitoring that detects personal data breaches in time to support the 72-hour notification clock.
We test restore procedures and security measures, and record the results as evidence of regular testing.

How we hand over

Deliverables include configuration records, architecture diagrams, data flow maps and records of processing inputs for your team.
Runbooks cover rights request handling within one month, breach escalation and backup restoration steps.
Your staff receive documented handover so the organization can operate and evidence the platforms without DeployOpen.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer for platforms that change over time.
We can help prepare evidence for customer audits or supervisory authority inquiries, but the controller decides what to disclose.
Confirm with us during scoping which responsibilities stay with your team, your DPO or an independent assessor.

GDPR and self-hosted platforms