How the GDPR applies to public sector organizations
A public body asked by a customer, contract or regulator to show GDPR compliance should start with two facts: the GDPR requires no audit, attestation or certificate, and the controller remains accountable for its processing whatever evidence it offers. Public authorities and bodies must also designate a data protection officer, as Article 37(1) requires, except courts acting in their judicial capacity. Article 37(3) allows several public authorities or bodies to share a single DPO, taking account of their organizational structure and size. Confirm with your national supervisory authority and legal team whether your body is covered by a national designation rule, and document how a shared DPO's time, access to systems and reporting line will work across the participating organizations.
Several provisions bite differently for public bodies. Legitimate interests under Article 6(1)(f) cannot be relied on for processing carried out in the performance of public tasks, so each system that processes personal data for a statutory function needs a lawful basis such as a public task, official authority or legal obligation, and the team must be able to name it. The portability right in Article 20 does not apply to processing necessary for a public task or official authority, and the Article 20(3) and (4) limits mean that export features built for citizen self-service should be scoped with counsel before they are promised. Under Article 49(3), the consent, contract and compelling legitimate interest derogations do not apply to public authorities exercising their public powers, which narrows the options for transfers outside the EEA.
Fines are where the answer varies most. Under Article 83(7), each Member State decides whether and to what extent public authorities can be fined, so the exposure for a ministry, municipality or public company may differ from that of a private controller in the same country. Public bodies should confirm with their national authority how that choice applies to them and to any functions they perform as companies. Whatever the national rule, the technical and organizational work is the same: keep the records, risk assessments and breach documentation that would let a supervisory authority see what was decided and why.
When a public body must appoint a DPO and whether it can share one
This sequence establishes whether each public body is covered by the mandatory DPO rule, whether one officer can serve several bodies, and what documented decision each body keeps on file. The output is a signed designation decision per body that the organization can show to a supervisory authority.
Confirm the body is a public authority or body
Start by listing every legal entity in scope and recording whether each one is a public authority or body under the law of its Member State. Legal counsel or the records owner should confirm the status, since the GDPR leaves the definition to national law and this is the first trigger under Article 37(1). Record the legal basis for the status, such as the founding statute or the register entry. The step is done when each entity has a status note signed off by someone able to answer for it.
Check the court exception for each body
Article 37(1) excludes courts acting in their judicial capacity from the mandatory appointment, but the exception covers judicial work only, not the administrative functions of a court. For each body, separate processing carried out in a judicial capacity from administrative processing such as HR, procurement and building access. A body that has both should still appoint a DPO for the administrative side unless another trigger is absent. The output is a short note per body that states which processing falls under the exception and which does not.
Test the other Article 37(1) triggers
Where a body is not excluded, confirm whether the appointment is mandatory for the public authority reason alone, which is the rule that applies to public bodies in the first place. Also map the body's processing against the other two triggers in Article 37(1), regular and systematic monitoring of data subjects at large scale and large-scale processing of special category or criminal offence data, so the file records every reason that applies. Ask the processing owners to list their largest data sets, such as benefits, health, policing or licensing records, and check them against those triggers. The output is a trigger table per body.
Assess whether one DPO can serve several bodies
Article 37(3) allows several public authorities or bodies to designate a single DPO, taking account of their organizational structure and size. Compare the bodies on reporting lines, shared IT and records systems, geographic spread and the volume of requests and incidents each one generates. A shared DPO for small municipalities with common systems is a different question from one for a national ministry and its agencies. The output is a sharing assessment that states which bodies could share, under what conditions, and which need their own officer.
Verify the shared DPO can meet Article 39 duties
Before sharing, confirm the officer can realistically perform the tasks in Article 39 for every body in the arrangement, including advising, monitoring compliance, supporting DPIAs and acting as the contact point for the supervisory authority. Article 38 requires that the DPO be involved properly and early, be given the resources needed, operate independently without receiving instructions on how to perform the tasks, and avoid conflicts of interest. Ask the candidate to show their time allocation across bodies, their access to each body's systems, and how they will handle a conflict between two bodies. The output is a resourcing and conflicts memo signed by each body's senior management.
Record the designation decision for each body
Write one designation decision per body. Each record should state the status finding, the trigger or exception applied, whether the body shares a DPO and with whom, the resources allocated, and the reporting line to the highest management level. Have the accountable executive sign it and file it with the records of processing. The output is a documented decision per body that an auditor or supervisory authority can read without needing the people who made it.
Publish contact details and notify the authority
Publish the DPO's contact details and communicate the designation to the relevant supervisory authority as the national rules and the controller's processes require. Confirm the contact details reach data subjects through privacy notices and the public website, and that each shared DPO's contact route works for every body they serve. The output is evidence of publication, such as the saved website page and a copy of the notification, stored alongside the designation record.
Review the designation when structure changes
Set a review trigger in the designation record for any change in the bodies' structure, size, mergers, new systems or a change in the DPO's workload or conflicts. Each review should repeat the trigger test and the sharing assessment and produce an updated decision. Responsibility stays with each controller or processor, so the file should show that a shared DPO does not move accountability for compliance away from the body itself. The output is a dated review log linked to the original decision.
Which lawful bases and rights change for public tasks
When a public authority processes personal data to perform its tasks or exercise official authority, the lawful basis is usually the public task or official authority ground in Article 6(1). The more important constraint is what drops away. Public authorities cannot rely on legitimate interests for processing carried out in the performance of their tasks, so a system built around a balancing test for those activities has no lawful footing. The public-task ground also brings the Article 20 portability right down to nothing for that processing, because the right does not apply where processing is necessary for a public task or official authority.
- Legitimate interests are removed: Article 6(1)(f) cannot be used for processing done in the performance of public tasks, even where the balancing test appears to favor the authority.
- Portability does not apply: Article 20(3) excludes processing necessary for a public task or official authority, so systems should not be built to export such data on request.
- Erasure still applies: The portability exclusion is without prejudice to erasure under Article 17, so deletion workflows must still run for this data.
- Other rights still apply: Access, rectification and objection rights are not removed by this exclusion, so request handling must continue for public-task records.
- Confirm the task basis: Identify the specific national statute or mandate that creates each task before mapping a processing activity to Article 6(1)(e).
Confirm with your legal team which national law defines each of your public tasks, because the scope of the public-task ground depends on that source.
Where a public body must process data to comply with a legal obligation under Union or Member State law, the basis is the legal obligation ground in Article 6(1)(c). This basis is often the strongest footing for public bodies, but it is only as wide as the statute that creates it. The obligation must be set out in law, and the processing should stay within what that law requires. Systems should therefore record which provision authorizes each dataset so that the scope of processing can be checked against it.
- Statute defines the scope: The processing should match what the cited legal provision requires, not general administrative convenience.
- Record the provision: Store the article or section reference against each processing activity in the record of processing.
- Rights still follow the basis: Because the legal obligation is not the public-task ground, the Article 20 portability analysis must be checked against the exact basis applied.
- Retention follows the law: Where a statute sets a retention period, configure deletion to match it and remove data when that period ends.
- Revisit when law changes: Review system configuration whenever the underlying national law is amended.
Confirm with the authority responsible for each data set which statute creates the obligation and whether it sets retention or access rules.
Public authorities often assume that consent or a contract can cover a service, but the GDPR limits both when public powers are involved. The derogations in Article 49(3) for consent, contract and compelling legitimate interests do not apply to public authorities exercising their public powers. Consent is also rarely a freely given choice when a citizen needs a public service, so it is a weak basis for core administrative processing. Contract may be available for purely commercial-style services a public body provides, but it does not extend to the exercise of public authority.
- Article 49(3) excludes public powers: Consent, contract and compelling legitimate interest transfers cannot be used to move data abroad when public powers are exercised.
- Consent is a weak choice: Where a service is needed to access a public function, the consent may not be freely given, so a different basis is usually needed.
- Contract has limits: Contract can apply to ancillary services, but not to the exercise of public authority.
- Transfers need another route: Public bodies sending data abroad should identify an adequacy decision, appropriate safeguards or a basis under Chapter V that does not depend on Article 49(3).
- Document the choice: Record why consent or contract was or was not used in the processing documentation.
Confirm with counsel whether any service you offer is an ancillary commercial activity or an exercise of public power, since that decides whether the consent or contract route is open at all.
What changes the scope and effort of GDPR work in a public body
Public bodies rarely share the same GDPR workload. The size of the processing inventory, the way the body is organized, where its processors host data, the national rules on penalties and the volume of sensitive data each change how much work the controls require. Use these drivers to size the programme before asking for a quote.
Number of processing activities and systems
Every processing activity needs a record, a lawful basis, a retention rule and a security assessment under Article 32. A body with hundreds of activities spread across legacy systems carries far more documentation and testing than one with a small, well-mapped set. Start by building a single register of processing activities and linking each to the systems that hold the data. Ask any implementation partner to price the work per activity and per system rather than as a flat total, so you can see where the effort sits.
Single authority or shared structure
Under Article 37(3), several public authorities or bodies may designate one DPO, taking account of their size and structure. A shared DPO can cut the cost of the role, but the arrangement needs written terms covering how the DPO reaches each body, how conflicts are handled and who answers requests. Where a body sits inside a larger ministry or group, confirm which entity is the controller for each system, because that decides who owns the records, the DPIAs and the breach notices.
Cloud and foreign-hosted processors
Each processor that hosts or accesses personal data needs a contract under Article 28, and any transfer outside the EEA needs a transfer mechanism. Remote support from a non-EEA vendor counts as a transfer even when no data is stored abroad. Map every processor and sub-processor, record where data is stored and accessed, and confirm whether a transfer tool such as the EU-US Data Privacy Framework applies to each one. This analysis usually takes longer than the technical hardening itself.
National fining and penalty rules
Under Article 83(7), each Member State decides whether and to what extent public authorities can be fined, and Article 84 lets it set other penalties. The same breach can therefore carry very different financial exposure depending on the country and the type of body. Check the national data protection act and the supervisory authority's published position on public bodies before scoping. The answer changes how much budget should go to preventive controls, since it defines the cost of a failure for your body.
Volume of special category and criminal data
Health, social care, policing, justice and benefits bodies often hold special category data or criminal offence data at scale. Processing these data at large scale is one trigger for a mandatory DPO and a DPIA under Articles 35 and 37, and it raises the security bar under Article 32. Identify which datasets contain this data, restrict access to named roles, and log each access. Ask any partner to scope these systems first, because they usually set the timeline and the testing depth.
How national choices on fining public bodies affect exposure
The maximum fine levels in Article 83 apply in principle, but they do not automatically reach public bodies. Article 83(7) lets each Member State decide whether and to what extent public authorities and bodies established in that state can be fined. Some states have chosen not to impose administrative fines on public bodies at all, others limit them, and others apply the full range. Article 84 adds a separate duty: Member States set other penalties for infringements that are not subject to administrative fines, and those penalties sit in national law rather than in the Regulation. For a public sector organization, the practical question is therefore not what Article 83 says in the abstract but what its national data protection act and any related administrative law say about public bodies. Ask your data protection officer or legal counsel to document that answer for each jurisdiction and each public entity in scope, including bodies that deliver public services under contract.
Where a fine is available, the amount is not chosen at random. The EDPB's Guidelines 04/2022 on the calculation of administrative fines set out how supervisory authorities assess the seriousness of an infringement, the categories of data involved, the duration of the breach, the degree of responsibility and cooperation, and mitigating or aggravating factors. Those guidelines describe the method that applies where a fine is imposed, so the value of documented security measures and a timely response to incidents still matters for a public body even where the national regime limits the outcome. Confirm with your supervisory authority how it applies that method to public bodies in your state.
Enforcement against technical security failures is not theoretical. In 2026 the Swedish supervisory authority fined Miljödata i Karlskrona, an organization processing personal data, approximately EUR 160 000 for insufficient technical measures, as reported by the EDPB national news. That case concerned a private organization, so it does not show how a Swedish public authority would be treated. It does show the kind of failure that draws a fine: weak technical controls that an Article 32 assessment would have caught. Public bodies should check which of their systems hold personal data for public tasks, whether their national regime allows fines against them, and who would decide the response if a supervisory authority opened an inquiry.
What a public sector GDPR programme costs and who is paid
This table compares each cost component of a public sector GDPR programme by who is paid, whether the cost is one-time or recurring, and what moves it up or down. No amounts are stated because none are supplied for this topic, so use the drivers to build the questions you put to each supplier and to your own budget owner.
| Cost component | Who is paid | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Internal or shared DPO time | Your body, or the body that shares the DPO under Article 37(3) | Recurring | Number of bodies sharing one DPO, volume of processing, and the number of DPIAs and requests the DPO must review |
| Legal and national-law review | External counsel or your own legal team | One-time, then periodic | Number of national public-sector rules that apply to your tasks, and how often those rules change |
| Lawful basis and task mapping | Your staff, with optional outside support | One-time, then on change | Number of processing activities, and whether each one traces to a legal task rather than legitimate interests |
| Implementation partner work to prepare systems | Implementation partner under a written, fixed scope | Mostly one-time | Number of legacy systems, data flows to rebuild, and whether access and retention features already exist |
| Logging, access controls and retention | Your platform team and the implementation partner | One-time build, recurring operation | Number of systems holding citizen data, log volume, and how many roles need access reviews |
| Evidence collection and records | Your staff, with optional partner support | Recurring | Frequency of assessments, size of the processing record, and how much evidence is generated automatically |
| Independent assessment, if commissioned | Independent auditor or certification body, if you choose one | Periodic | Scope of the systems reviewed and whether the body requires a certificate or only a readiness review. GDPR itself requires no audit |
| Tooling and recurring review | Software vendors, hosting providers and your staff | Recurring | Licence model, hosting location, and the frequency of testing and policy review |
How a public body moves from gap review to documented compliance
The sequence starts by fixing what the organization processes and on which basis, then tests the systems against the security and documentation duties, and ends with evidence that a supervisory authority or auditor can follow. Each phase produces a named output that the next phase depends on.
Scope processing activities and lawful bases
The organization's data protection lead, with business owners of each service, lists every processing activity that involves personal data and records the Article 6(1) basis for each one. For public authorities, the review confirms whether a task rests on a legal obligation or a public task or official authority, because legitimate interests cannot be relied on for processing carried out in the performance of those tasks. The output is a scoped inventory of processing activities, systems, data categories and bases, reviewed and signed off by the accountable manager. The step is complete when every system in scope maps to one activity and one documented basis.
Designate the data protection officer
The public body confirms it must appoint a DPO under Article 37(1), since public authorities are covered except courts acting in their judicial capacity. Where several public bodies share a structure, Article 37(3) allows one DPO to serve them, taking account of organizational structure and size. The appointing body records the designation, reporting line, resources and contact details, and publishes the contact details as required. The output is a written designation and a confirmed DPO mandate that the DPO can actually perform, including access to systems and the time to review them.
Assess gaps against Article 32 and the records of processing
The security and data protection teams compare current controls for each in-scope system against the risk-based security duty in Article 32, using the scoped inventory as the starting point. They also check that the record of processing covers the same activities and that the stated measures match what is configured. Gaps are logged with an owner, a risk rating and the evidence that would close them. The output is a gap register tied to specific systems and a reconciled record of processing. The step is complete when the DPO has reviewed the register and no in-scope activity lacks an entry.
Run a DPIA where the processing triggers one
For processing likely to result in high risk, such as large-scale special category data or systematic monitoring, the controller carries out a data protection impact assessment under Article 35 and consults the DPO. The DPIA describes the processing, assesses necessity and proportionality, identifies risks to individuals and sets out the measures that address them. If high risk remains after mitigation, prior consultation with the supervisory authority under Article 36 is needed before processing starts. The output is a signed DPIA with named mitigations and a review date, linked to the gap register.
Remediate gaps with an implementation partner
The organization assigns each gap to an internal owner and, where the work needs engineering capacity, an implementation partner prepares or hardens the systems in the client's own environment. Typical work includes access control, logging, encryption, backup and restore testing, and configuration changes in self-hosted platforms. The organization approves each change, and the partner records what was changed and why. The output is a set of implemented controls with change records and test results. The step is complete when the owner of each gap confirms closure and the DPO accepts the evidence. The partner prepares systems and evidence but does not decide compliance.
Assemble the evidence pack
The DPO and the control owners collect the documents a supervisory authority or an independent assessor would ask for: the record of processing, the scoped inventory, lawful basis notes, DPIAs, the gap register with closure records, configuration exports, access reviews, test results and breach response procedures. Each item is named, dated and linked to the control it supports. The output is a versioned evidence pack with an index. Confirm with your supervisory authority or legal adviser which formats and documents they expect, since GDPR requires no certificate and sets no fixed artifact list.
Review periodically and after material change
The DPO schedules reviews of the inventory, the record of processing and the DPIAs, and triggers an earlier review when a system, supplier, data category or legal requirement changes. Security testing and access reviews feed back into the gap register. The output is a dated review log and an updated evidence pack. Note that GDPR itself is not currently amended, but the Omnibus IV and Digital Omnibus proposals are pending, so the review should check for changes to obligations as they are adopted.
What must be in place before an assessment or regulator inquiry
A public body facing a supervisory authority inquiry or an internal audit is asked to show its paperwork and its systems agree. The cards below cover the records and decisions an assessor will request first, and each one says how to check that it exists, is current and matches what the systems actually do.
Record of processing activities
The record lists each processing activity, its purpose, categories of data and data subjects, recipients, transfers and retention periods. For a public authority it should map each record to the task or legal power it serves. To check it, pick three systems at random and confirm each one appears in the record with the same purpose and retention period that the system actually applies. Ask who signs off changes and when the record was last reviewed.
Documented lawful basis per task
Public bodies cannot rely on legitimate interests for work carried out in performing their tasks, so each processing purpose needs a basis tied to a public task, legal obligation or another permitted ground under Article 6(1). To check it, confirm that every purpose in the record names a basis and the statutory or regulatory provision behind it. Where a basis is consent, verify that the public body has a genuine free choice available to the person.
DPO designation record
A public authority must designate a data protection officer, and several bodies may share one DPO if the structure and size allow it. The designation record should name the officer, the bodies covered, the contact details published to the public and the resources provided. To check it, confirm the DPO is reachable, has time and budget for the role, and is not assigned tasks that would create a conflict of interest with the decisions they review.
DPIAs for high-risk processing
A data protection impact assessment documents the risk to individuals from processing likely to be high risk, such as large-scale profiling or monitoring of citizens. For public bodies these assessments often cover citizen registers, case management and new digital services. To check them, confirm each assessment exists for the processing that requires one, lists mitigations, records the DPO's advice and has a review date tied to changes in the system.
Processor contracts and sub-processor list
Shared hosting, outsourced case management and managed support all make the vendor a processor under Article 28. The contract must set out instructions, confidentiality, security measures, sub-processor controls and deletion or return at the end. To check it, compare each signed contract against the record of processing, confirm the sub-processor list is current, and confirm the public body received notice of changes it could object to.
Access, logging and breach response plan
Assessors look for evidence that only authorized staff reach personal data, that access is logged and reviewed, and that a breach can be detected and reported within the 72 hours Article 33 allows. The response plan should name decision makers, the DPO's role and the criteria for notifying the supervisory authority. To check it, request recent access review records, sample log entries for a case file, and run a tabletop exercise to confirm the plan can be followed on a working day.
Who owns controls, who prepares evidence, and who reports
The public authority or body acting as controller keeps the decisions that the GDPR assigns to it. That covers which public task justifies each processing activity, whether a legal basis exists in national law, how risk is assessed, which measures are appropriate, and who answers to data subjects and the supervisory authority. Article 5(2) and Article 24 make the controller accountable for demonstrating compliance, so this responsibility cannot be handed to a vendor or consultant.
- Legal basis decisions: the controller determines the public task or legal obligation behind each processing activity, because legitimate interests are not available for tasks carried out as a public authority.
- Risk and control ownership: the controller decides which Article 32 measures are appropriate and accepts residual risk.
- Data protection officer: a DPO must be designated for public bodies, and one DPO can serve several bodies where structure and size allow.
- Records and DPIAs: the controller maintains records of processing and carries out DPIAs where required.
- Regulator contact: the controller answers the supervisory authority and handles data subject requests.
Before engaging anyone, confirm internally who signs off each control and who holds the DPO mandate in writing.
An implementation partner such as DeployOpen works on the systems that hold personal data. In a self-hosted deployment, the work happens inside the public body's own cloud accounts, data centers or air-gapped networks, so data does not leave the organization's control during setup. The partner prepares the technical evidence the controller will rely on, but it does not decide the legal position and does not issue any compliance report.
- Configuration and hardening: access control, logging, encryption, backup and restore are configured to the controller's written requirements.
- Evidence preparation: configuration records, access reviews, log samples and restore test results are organized so the controller can present them.
- Documentation support: technical descriptions for the record of processing and DPIA inputs are drafted for controller review.
- Testing: security testing can be scoped in writing to check the controls that were built.
- Ongoing operation: upgrades and support are available through a separate retainer if the controller wants them.
Ask for the written scope, the list of deliverables, and a statement that the partner will not sign, certify or represent the controller's compliance.
Independent scrutiny of GDPR compliance comes from supervisory authorities, which enforce the regulation, and from parties the controller chooses. The GDPR requires no audit, attestation or certificate. An Article 42 certification is voluntary, issued by an accredited certification body or a supervisory authority for at most three years, and it does not reduce the controller's responsibility. Supervisory authorities, not auditors, decide on infringements and fines.
- Supervisory authorities: national authorities investigate complaints, can order remedies and set fines, and under Article 83(7) each Member State decides whether public authorities can be fined.
- Accredited certification bodies: these may issue Article 42 certifications, which are voluntary and time-limited.
- Independent assessors: an organization may commission an independent review of its controls, but its findings are advisory to the controller.
- Internal audit: the public body's own audit function tests whether its controls operate as documented.
- Limits of certification: a certificate is evidence of a process, not a guarantee of compliance in every processing activity.
Confirm with the relevant national authority which review or certification routes exist for your sector before committing budget.
How to choose a DPO service, consultant or certification body
Outside help for GDPR comes from three different roles: a DPO service, a consultant who prepares systems and evidence, and a certification body that issues Article 42 certificates. Each needs different checks, so confirm the role and the scope before comparing prices or signing anything.
Confirm accreditation for any certificate
Article 42 certification is voluntary and is issued by accredited certification bodies or supervisory authorities, never by a consultant. Before you rely on a certificate, ask the body which accreditation it holds, who granted it, and which certification criteria apply. A consultant who offers to "certify" your processing is describing a claim that carries no formal weight. Certification also lasts at most three years and does not reduce your responsibility for compliance.
Separate the DPO role from consulting
If you buy both a DPO service and a consultant to build your evidence, the DPO should not also be the person who designed the systems they will later judge. Article 38 expects the DPO to avoid conflicts of interest, and the Article 29 Working Party guidance on DPOs treats roles that set processing purposes or means as a conflict. Ask who will sign off the DPIA, who reports to the DPO, and whether the same firm would review its own work.
Check experience with public bodies
Public authorities work under national administrative law, sector rules and in some cases national GDPR add-ons, and each Member State decides whether public bodies can be fined. Ask for references from comparable public bodies in your country or sector, and confirm the consultant knows how your national supervisory authority has treated similar processing. Generic private-sector experience rarely covers public task lawful bases or transfer derogation limits.
Verify handling of confidential data
Reviewing records of processing, DPIAs and incident files exposes citizen data, security architecture and sometimes criminal offence data. Ask where the provider stores your documents, who on their team can access them, whether they will work inside your environment, and how they handle sub-processors. Require a data processing agreement under Article 28 before any document leaves your organization. Confirm that staff sign confidentiality undertakings.
Insist on a written scope
Vague scopes produce open-ended invoices and unclear accountability. A written scope should name the processing activities covered, the systems and sites in scope, the deliverables such as a record of processing or DPIA, the acceptance criteria, and what the provider will not do, such as issuing an audit opinion. Ask how changes to scope are priced and approved, and who owns each control after the engagement ends. Most fixed-scope engagements agree this before work starts.
Ask these questions before signing
Before signing, ask: Which accreditation or role do you hold, and who issues any certificate? Who on the team will do the work, and what public sector experience do they have? Where will our data be stored and who can access it? What is excluded from scope? What do we own at the end, and what recurs after it? Which parts depend on our own staff? Get written answers, and compare them against the scope in the quote rather than the sales summary.
Questions public bodies ask before hiring outside help
Can several public authorities share one data protection officer?
Yes. Article 37(3) allows several public authorities or bodies to designate a single DPO, taking account of their organizational structure and size. The arrangement works best when the shared DPO has enough time, access to each body's processing activities and a clear reporting line in every organization. Before agreeing to it, confirm in writing how many bodies the DPO covers, how many hours each body can expect, who handles requests when the DPO is unavailable, and how conflicts of interest between the bodies will be managed. Whether a shared DPO is appropriate depends on the size and scope of each body's processing, so the decision should be documented in each organization's governance records.
Does a public body have to hire outside help for GDPR compliance?
No. The GDPR requires no outside firm, and it requires no audit, attestation or certificate. Public bodies must still meet the obligations themselves, including the mandatory DPO, security of processing, records and breach notification. Outside help is a choice made to fill capacity or skills gaps, such as technical security testing, documentation support or hardening a self-hosted platform. Responsibility stays with the controller. An implementation partner can prepare systems and evidence, and an independent auditor or certification body can issue reports or certificates where those are used. Confirm internally which tasks your staff can own and which need external capacity before you issue a request for proposal.
How long does GDPR preparation take for a public body?
It depends on scope. The duration is driven by how many systems process personal data, how well the current processing is documented, whether a DPIA is needed for high-risk processing, how many departments must be involved, and how much of the platform is self-hosted versus procured from vendors. A narrow scope covering one register and one platform will take far less time than a multi-department programme that spans records, retention, access control and breach procedures. We do not publish a fixed duration. Ask any provider for a written scope and a timeline tied to specific deliverables, and ask which of those deliverables depend on your staff's availability.
What does the work require from our own team?
Most of the work needs decisions and knowledge that only your organization holds. Expect to commit a named data protection lead or DPO, system owners who can confirm what each platform stores and who can access it, IT staff who can grant access to logs and configuration, and legal staff who can confirm the lawful basis and any national rules that apply. Procurement and records staff are often needed to collect contracts and processor details. Agree these roles and their time commitments in the written scope, because delays usually come from waiting for internal input rather than from the technical work.
Do the Digital Omnibus or Omnibus IV proposals change the GDPR now?
No. As of October 2026 the GDPR text has not been amended. The Omnibus IV proposal (COM(2025) 501, procedure 2025/0130(COD)) has a text agreed in interinstitutional negotiations on 26 June 2026 that is awaiting Parliament's first-reading vote. The Digital Omnibus proposal (COM(2025) 837, procedure 2025/0360(COD)) is awaiting committee decision. Until those proposals are adopted and published, current obligations apply. Track their status on the European Parliament Legislative Observatory and plan your programme against the existing articles, noting that Regulation (EU) 2025/2518 on cross-border enforcement procedure applies from 2 April 2027.
How do we confirm the fining rules that apply to our public body?
Article 83(7) lets each Member State decide whether and to what extent public authorities can be fined, and Article 84 lets it set other penalties for infringements not subject to administrative fines. The answer is therefore national. Confirm it with your national supervisory authority and with your legal team, and check the implementing national data protection law that covers public bodies in your country. Record the source you relied on and the date you checked it, because national rules can change. Ask any outside adviser to state which national provisions they assume and to cite them in their written scope.
How DeployOpen prepares public sector systems and evidence
DeployOpen works with public authorities to prepare the systems, controls and records that GDPR obligations touch, including the DPO's working environment and the evidence the organization keeps. The organization keeps ownership of its decisions, lawful bases and DPO independence, while DeployOpen plans, implements and documents the technical side inside the organization's own infrastructure.
How we scope
- Each engagement starts with a written scope that names the systems, data flows and public tasks in question.
- We map which processing relies on public task or legal obligation, so technical work does not assume a legitimate interest basis.
- The scope states who owns each decision, including the DPO's role, and what the organization must confirm with its own legal team.
How we build
- We implement self-hosted open-source platforms inside your cloud accounts, data centers or air-gapped networks, keeping personal data where your legal team has approved it.
- We configure access control, logging, backup and restore, and data retention so the controls can be tested against Article 32 expectations.
- We build request-handling workflows for access and erasure, including the limits on portability for processing carried out under a public task.
How we hand over
- We deliver configuration records, architecture diagrams, runbooks and test results that your DPO and internal assessors can review.
- We document transfer paths and any third-country access so your team can prepare its own transfer analysis under Chapter V.
- We train operators on the procedures they must follow, and we leave the evidence in your environment, not ours.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We re-test changed systems and update documentation when processing purposes or hosting arrangements change.
- Independent auditors, supervisory authorities and certification bodies assess and certify. DeployOpen prepares the evidence but does not issue reports or certificates.
