Article 32(1)(b) GDPR: requirements and evidence

What GDPR Article 32(1)(b) asks your systems to guarantee

If you are a compliance lead or engineer, the question you will eventually face is simple: can you show that the systems processing personal data keep it confidential, intact, available and resilient under the GDPR security test? Article 32(1)(b) answers that question in four named properties. Confidentiality means only authorized people and services can read the data. Integrity means the data cannot be altered without authorization or detection. Availability means authorized users can reach the data when they need it. Resilience means the systems keep working and recover when load rises or something fails. The article names these properties and leaves the choice of products to you. It does not prescribe a vendor, a protocol or a configuration, so the evidence you produce has to show that your own chosen controls deliver each property.

The duty is risk-based and shared. Under Article 32, a controller decides what level of security fits the risks to individuals, and a processor must provide measures that meet the same standard for the processing it performs for the controller. Neither party can hand the duty to the other by contract. Both need to know which systems hold personal data, who can reach them, and what happens when they fail. Because the duty spans identity, network protection, logging and capacity at once, it is harder than it looks. A single gap in one area can defeat good controls in the others, and an assessor will test the path from the outside user to the stored record, not each control in isolation.

Most gaps come from defaults and unmanaged access rather than from missing tools. A system installed with its vendor settings may accept logins without a second factor, expose an administrative interface, keep logs for no defined period, or run without capacity limits. Accounts for former staff, shared service accounts and vendor access often stay active for years. Before you plan remediation, ask your team to list every system that holds personal data, record who can authenticate to it and how, and check its default configuration against your own baseline. Confirm with your supervisory authority guidance and your own risk assessment which gaps you must close first. Your outcome is evidence that each property is protected in practice, and that evidence is what a regulator will ask to see.

Which systems, data and teams fall under GDPR Article 32(1)(b)

Article 32(1)(b) applies to the processing systems and services that handle personal data, so the scope starts with where that data is processed and every component that can affect its confidentiality, integrity, availability or resilience. The decisions below change how much work the assessment involves, and each one determines whether an access path, dependency or third party sits inside or outside the boundary you assess.

Systems that hold personal data

Start with an inventory of every application, database, file store and analytics pipeline that stores or processes personal data, including copies in test, staging and reporting environments. Article 32(1)(b) covers these systems in full, so a database that is only used for backups or exports still counts. Ask the owner of each system to confirm which data categories it holds and which teams can query it. Each system with personal data needs a named owner and a documented boundary.

Identity providers and directories

Identity providers and directories decide who can reach personal data, so they sit inside the scope even when they hold no personal data themselves. This includes single sign-on services, LDAP or Kerberos directories and the multi-factor settings that protect them. Check whether applications delegate sign-in to a central provider or keep their own credential stores, because each local store is a separate confidentiality risk. Open-source options such as authentik, FreeIPA and Keycloak are common in self-hosted estates, and each needs its own configuration review.

Network entry points

Every route from outside the trusted network into a system holding personal data belongs in scope, including VPN concentrators, reverse proxies, load balancers, remote administration consoles and API gateways. The Hôpital Privé de la Loire decision by the CNIL, reported by the EDPB, turned on a patient record system reachable by outside users without VPN or multi-factor authentication. Inventory each entry point, record which authentication it enforces and confirm that no path bypasses the controls on the others.

Logging and monitoring platforms

Log stores, SIEM tools and monitoring dashboards record access to personal data and must themselves be protected, because they often hold usernames, IP addresses and query contents. Scope them for access control, retention and integrity so that an attacker cannot alter the record of their activity. Confirm who can read, delete or export logs, whether logs are forwarded off-host, and how long they are kept. Logging platforms are also how you detect availability and integrity breaches, so their own uptime matters.

Capacity-bearing and shared services

Services that provide capacity or resilience, such as load balancers, message queues, DNS, shared storage, container orchestration and backup infrastructure, support the ongoing availability and resilience of personal data processing. Include them in scope when a failure in them would stop or degrade access to personal data. Confirm which services are shared with unrelated workloads, how capacity limits are monitored and whether a single outage could remove access to several systems at once.

Controller, processor and third-party access

The controller owns the obligations under Article 32, but a processor that runs the systems must meet the same requirement for the processing it performs, and both roles remain responsible for their own part. Hosting providers, managed service firms and remote support engineers with administrative access must sit inside the assessed boundary, or be covered by written evidence of their own controls. Ask each third party which accounts, networks and tools it uses to reach your systems, and who approves that access. Any vendor with administrative reach into personal data systems belongs in scope.

How an assessor tests confidentiality, integrity, availability and resilience

The table lists the properties and the access and logging controls behind them, with the test an assessor typically runs, the evidence they ask for and the findings that recur. The GDPR issues no certificate, so these tests are run by supervisory authority investigators, customer auditors or internal audit, who judge whether the controls work in practice and match the risk.

Area	How the assessor tests it	Evidence requested	Common findings
Confidentiality: access to personal data	Samples user accounts with access to the systems holding personal data and checks each grant against a documented need	Access lists exported from directories, approval records, role definitions, leaver removal tickets	Shared or generic accounts, dormant accounts still active, access granted by default to whole teams
Authentication and MFA	Attempts sign-in from outside the network and checks whether a second factor is required for remote and privileged access	Identity provider policy settings, MFA enrolment reports, VPN or gateway configuration	Internet-facing systems reachable without a second factor, MFA exempt for administrators, weak recovery paths
Network protection	Scans exposed services and reviews segmentation between internet, application and database tiers	Firewall or security group rules, network diagrams, recent scan results and remediation tickets	Database or admin interfaces exposed to the internet, flat networks, outdated rules nobody reviewed
Logging and monitoring	Selects a sample of access events and checks whether logs exist, are protected from alteration and are reviewed	Log source inventory, retention settings, sample alerts, review records, evidence of log integrity controls	Logs disabled on some systems, no review of privileged activity, logs stored where administrators can edit them
Integrity of data and configuration	Compares production configuration against the approved baseline and checks change approval for a sample of changes	Change records, baseline configurations, version control history, data validation rules	Undocumented emergency changes, default settings left in place, no check that records are unaltered
Availability and capacity	Reviews capacity monitoring and the response to load or failure events in recent history	Capacity reports, monitoring alerts, incident tickets, service availability records	No alert thresholds, capacity planned only after an outage, single points of failure for personal data services
Resilience under stress	Asks how systems behave under attack or failure and reviews past incidents and tests	Incident post-mortems, resilience test reports, documented failover procedures	Lessons from past incidents not implemented, failover never exercised, no record of tests
Vendor and hosting access	Checks who outside the organization can reach systems holding personal data and under what controls	Processor contracts, support access logs, remote access approvals	Vendor support accounts with standing access, no record of when remote access was used

How breach types map to each property the article protects

The EDPB Guidelines 9/2022 sort personal data breaches into three categories that line up with the properties named in Article 32(1)(b). A confidentiality breach is an unauthorised or accidental disclosure of, or access to, personal data. An integrity breach is an unauthorised or accidental alteration of personal data. An availability breach is an accidental or unauthorised loss of access to personal data, or its destruction. One incident can fall into more than one category, and the controller must classify each one against the facts it can establish, not against the label that is easiest to report.

The CNIL's EUR 500,000 fine against Hôpital Privé de la Loire, decided on 3 September 2026, shows how this works in practice. Outside users could reach a patient record system holding data on 524,867 patients without a VPN or multi-factor authentication, and an attacker used that exposure to take the data. The core failure is confidentiality: access control and authentication did not stop unauthorised people from reaching personal data. Illustratively, a controller in the same position should record which access paths existed, whether they required a second factor, and which accounts were used, because those answers decide the breach scope. Teams can use an identity provider such as Keycloak or Zitadel to enforce MFA on every external path, then check the configuration against the logs. Confirm the exact findings and any further detail in the EDPB national news item.

Resilience failures can create availability breaches even when no data leaves the organization. If ransomware or a failed platform encrypts or removes records and the controller cannot restore them in time, the loss of access is itself a breach that must be assessed. Integrity breaches arise when records are changed without authorization, for example through an attacker editing clinical entries, and they need separate detection, such as file integrity checks and audit logs. The mapping decides what the controller must document and assess: the category shapes the risk assessment, the decision whether the supervisory authority must be notified within 72 hours, and whether affected individuals must be told. Each category needs its own evidence trail from the start of the incident.

How to implement the requirement in sequence

This sequence turns Article 32(1)(b) from a general aim into a set of inspectable records covering systems, access, network entry, logging, capacity and resilience decisions. It is the writer's own working order, not a sequence the GDPR or any regulator prescribes.

Inventory processing systems and personal data flows
Start by listing every system and service that processes personal data, including production applications, databases, identity stores, backups, logging pipelines and support tooling. For each one, record what personal data it holds, where it runs, which sub-processors or hosting providers it touches, and which teams administer it. The product owner, system owners and the privacy lead usually complete this together. The step is done when a system inventory and a data flow diagram exist, each system has a named owner, and the inventory has been reconciled against the record of processing so that no processing system is missing from either.
Set the access and authentication baseline
For each system in the inventory, define who may access it, through which identity source, and with which authentication strength. Confirm that every user account is tied to a named person, that privileged roles are separated from everyday roles, and that multi-factor authentication applies to remote and administrative access. Open-source identity providers such as authentik, Keycloak and Zitadel can centralize sign-in for applications, and FreeIPA can cover Linux and UNIX estates, but you should confirm each product's current capabilities against your own environment before relying on them. The output is an access register listing roles, approvers, account types and MFA status per system, plus a written authentication standard that the register references.
Protect network entry points
Map every route by which a user, partner or outside network can reach a processing system, including public endpoints, remote administration paths, VPN concentrators, API gateways and support connections. Remove any entry point that does not need to be reachable from outside, and require the remaining paths to pass through authentication and encryption in transit. Regulators have treated patient record systems reachable from the internet without VPN or multi-factor authentication as a serious shortfall, so this step should be checked against that pattern explicitly. The output is an exposure map, a firewall or security group rule set exported from each environment, and a short sign-off record showing that each external path was reviewed.
Configure logging and capacity monitoring
Enable event logging for authentication, privileged actions, configuration changes and data access on each system, and forward logs to a store that the system administrators cannot silently alter. Set alerts for failed logins, unusual access volumes and resource exhaustion, and define who receives them and how fast they must be triaged. Capacity monitoring is part of resilience because a system that fills its disk or exhausts its connection pool loses availability without any attack. The output is a logging standard, a configuration export showing log sources and retention settings, and a sample of alert records demonstrating that the alerts fire and reach a responder.
Harden configurations against a baseline
Compare each system's live configuration with a written baseline covering default accounts, default passwords, unused services, encryption settings, patch levels and administrative interfaces. Remove or change defaults before go-live, because default configuration is one of the measure families that security reviewers examine. Record each deviation from the baseline with a reason and an approver. The output is a configuration baseline document, scan or review results for each system, and a deviation log with dated approvals.
Document resilience decisions
Record the decisions that determine whether processing systems stay confidential, accurate and available under stress: which components are single points of failure, how capacity is planned, what happens to integrity if a system is partly restored, and which outages would count as a personal data breach because access to data was lost. Assign an owner to each decision and link it to the risk assessment that justified it. The output is a resilience decision record for each system, reviewed when the architecture changes, and it gives an assessor a traceable line from risk to design choice.
Review and maintain the evidence set
Schedule a recurring review of the inventory, access register, exposure map, logging configuration and baseline deviations, and trigger an extra review after major changes, incidents or new sub-processors. Keep dated versions of each record so that you can show what was in force at a given date. Independent auditors and certification bodies, not your implementation partner, decide whether the evidence is sufficient for any assessment you undergo. The output is a maintained evidence folder with a change history and an owner for each record.

Which evidence artifacts pass an assessment of this article

An assessor testing Article 32(1)(b) looks for records that show who can reach personal data, how systems are configured, what happened on them, and whether they stayed available. The cards below cover six artifacts that answer those questions, and each one needs a refresh process so it is current when the assessor asks.

Access control register with role assignments

A register lists every account and group with access to systems that process personal data, the role each one holds, who approved it and when it was last reviewed. It shows the confidentiality property directly, because it answers who can read, change or delete data. Check that the register covers service accounts and administrators, not only end users, and that leavers and role changes are removed. Keep it current with a scheduled export from the identity provider plus a change record for every grant and revocation.

MFA enforcement for externally reachable applications

Evidence here is the configuration that shows which applications accept sign-in from outside the network and whether a second factor is enforced for every user of them. A policy export that lists each external application, its provider and its MFA setting is stronger than a statement that MFA is in use. Confirm the enforcement applies to administrators and local accounts, since those are common gaps. Export the policy on a fixed schedule and record any exception with an owner and a review date.

Configuration baselines including default configuration

Baselines record the hardened settings for each operating system, database, web service and identity component that processes personal data, including the default configuration that ships with each product. Assessors compare the live system against the baseline, so the baseline must name the setting, the expected value and the reason. Test for default accounts, default passwords and open management ports. Keep baselines in version control so each change has an author, a reviewer and a date, and run a comparison against live systems on a set cycle.

Centralized event logs with retention

Central logs collect authentication events, administrative actions, access to personal data and changes to security settings from every system in scope. They support both confidentiality, since unauthorized access becomes visible, and integrity, since unexpected changes are recorded. Confirm that the retention period is written down, that logs are protected from modification by administrators, and that someone reviews alerts. Ask the platform owner which events are captured by default and which need explicit configuration before the assessment.

Capacity and availability monitoring records

Monitoring records show resource use, service uptime and alerts for systems that process personal data, which address the availability and resilience property. Keep dated reports of capacity trends, incidents that affected availability and the actions taken. Assessors look for evidence that thresholds were set by someone with authority and that breaches of them led to a documented response. Export dashboards or alert histories on a regular schedule so the record does not depend on what is still stored in the monitoring tool.

Resilience and failover test records

Test records show that failover, redundancy and recovery of processing services work as described, and that results were acted on. Each record should state the scenario, the date, the systems involved, the expected and actual results, and the corrective actions with owners. A plan that was never run gives an assessor little to rely on. Schedule tests at a defined interval, and log any real incident that exercised failover so it counts as evidence alongside planned exercises.

How self-hosted open-source identity platforms support the evidence

authentik is an identity provider under the MIT license. It delegates sign-in for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so each application can rely on one central place for authentication rather than maintaining its own user store. For Article 32(1)(b), this matters because the controller can show a single, reviewable point where user identification and authorization are enforced across connected systems.

Provider delegation: Applications are configured as OAuth2/OIDC, SAML, LDAP, RADIUS or proxy providers, and the configuration itself becomes evidence of which systems depend on central sign-in.
Protocol coverage: Legacy systems that only speak LDAP or RADIUS can still be placed behind the same identity layer, which helps where older processing systems hold personal data.
Access decisions per application: Authorization rules tied to each provider show who can reach which personal data service.
MIT licensing: The permissive license generally places few obligations on redistribution, but the organization should confirm its own licensing position with counsel.
Log and session review: Confirm which authentication events and administrative changes are recorded, and where those logs are exported for retention.

Before relying on any of this, check the current provider documentation for your version and confirm how MFA is enforced for each connected application.

What meeting this article costs in money and effort

This table breaks down the cost components of meeting Article 32(1)(b) for a self-hosted platform, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to structure a written quote, since no prices or durations are supplied here.

Cost component	Who is paid and for what	One-time or recurring	What drives it up or down
Tooling or licences	Software vendors for identity, logging, monitoring and access tools. Self-hosted open-source components remove most licence spend but not operating effort.	Recurring if commercial licences apply; open-source core is often one-time setup	Number of identity-protected systems, user count, and whether support subscriptions are bought
Engineering time to configure access, MFA and logging	Internal engineers or an implementation partner configuring identity provider, MFA policies, network paths and log pipelines	One-time for the initial build, with recurring changes as systems are added	System count, number of applications needing single sign-on, and how many integrations use legacy protocols
Evidence upkeep	Internal staff or a partner exporting access reviews, MFA enrolment reports, log samples and configuration baselines	Recurring, usually on each review cycle	Number of systems in scope, how often reviews run, and whether evidence is collected automatically
External testing or review	Independent testers who check authentication, network exposure and configuration against the control	Recurring, typically on a schedule and after major changes	Internet-facing attack surface, data sensitivity, and the depth of testing agreed in the written scope
Auditor or assessor time	The independent auditor or certification body that tests the control and issues any report. The implementation partner does not issue reports.	Recurring with each assessment cycle	Scope boundaries, number of processors, sampling depth, and how well evidence is organized before fieldwork
Capacity and monitoring operations	Platform operators who size compute, storage and log retention so services stay available and logs are not lost	Recurring	Growth in data volume, log retention periods, and the resilience design of the hosting environment

Who does what: your team, a partner and the independent assessor

Your organization remains responsible for the security of processing under Article 32, whatever help it brings in. Your team decides which systems hold personal data, what confidentiality, integrity, availability and resilience mean for each of them, how much risk is acceptable, and which measures are proportionate. Those decisions belong to named people, and they should be recorded before any technical work starts.

Risk decisions: Set the required level of confidentiality, integrity, availability and resilience for each processing system, and accept or reject residual risk in writing.
Access policy: Approve who may hold which role, how joiners and leavers are handled, and how privileged accounts are reviewed.
Authentication standard: Decide which users must use multi-factor authentication, which exceptions exist and who approves them.
Operational ownership: Run monitoring, respond to alerts, review logs and keep capacity plans current after go-live.
Sign-off: Approve the final configuration, accept the evidence set and keep it under your own document control.

Confirm that a named owner exists for every system holding personal data before engaging anyone to build or test it.

Questions buyers ask before bringing in outside help

How much effort does Article 32(1)(b) work take, and what drives it?

The effort depends mainly on how many processing systems hold personal data, how many identity sources and administrative paths they have, and how much of the access model is already documented. Access control, authentication, network protection, logging and capacity each need a current configuration baseline, and the work grows with every system that is not yet inventoried. Organizations should expect effort on both the platform side (configuring sign-in, MFA, network rules, logs and capacity limits) and the evidence side (exporting settings and showing they are enforced). Ask a prospective partner to break the estimate down by system and by property so you can see where the time goes.

How long does this work take?

The duration depends on scope: the number of systems, their hosting model, and how many access and logging gaps need closing before evidence can be collected. DeployOpen does not publish fixed durations. Most engagements are fixed-scope, so the written scope, deliverables and timeline are agreed before work starts, and the quote sets the schedule. Ask for milestones that separate remediation from evidence collection, because a control that is fixed but not yet demonstrated still leaves a gap in an assessor's view.

Can our team do this in-house?

Yes, many organizations do this work internally, and nothing in the GDPR requires an outside firm. The question is whether your staff can configure identity, network and logging controls on the systems in scope and keep the configuration current. Internal teams often need help with the parts that are easy to miss: default configurations, service accounts, administrative access paths and capacity planning. Outside help is most useful when the in-house team is stretched, when the environment spans several hosting models, or when you want an independent review of the result before a customer or regulator asks.

What does the work need from our staff?

Your staff remain the owners of the controls and the decisions behind them. Expect to need named people who can approve access policies, provide directory and identity source details, confirm which systems hold personal data, and sign off changes to production. Security engineers and system administrators will carry out most configuration, and someone accountable for data protection should confirm the risk level each control addresses. Ask the partner to name the staff time required for each phase so that your team can plan around it.

Do we need a certificate to meet Article 32?

No. The GDPR requires no audit, attestation or certificate. Article 42 certification is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. Where a customer asks for independent assurance, an assessor may test your controls against a framework you have chosen, but that report is a commercial document, not a GDPR requirement. Confirm with your customers and regulator what evidence they actually expect.

What should we ask a partner to include in a quote?

Ask for a written scope that lists each system in scope, the access, authentication, network, logging and capacity measures to be implemented or reviewed, and the evidence each measure will produce. The quote should state deliverables, the responsibilities split between your organization and the partner, what is one-time work and what recurs, and what is excluded. Confirm whether the partner prepares evidence only, or also issues any report, since only an independent auditor or certification body issues assessment reports or certificates. Request a named list of assumptions so that scope changes can be priced transparently.

Which identity platforms can support MFA and single sign-on for these controls?

Open-source identity providers can cover much of the authentication work, but the choice depends on your protocols and environment. authentik supports OAuth2, OpenID Connect, SAML, LDAP, RADIUS and proxy providers, Keycloak supports passkeys, recovery codes and one-time passwords, and Zitadel supports TOTP, U2F, passkeys and one-time passwords with Force MFA settings. FreeIPA provides single sign-on for Linux and UNIX environments. Confirm each product's capability against its current documentation for your version and configuration before committing to a design.

How DeployOpen scopes and prepares this requirement

DeployOpen works on Article 32(1)(b) by planning, building and documenting the confidentiality, integrity, availability and resilience controls inside the client's own infrastructure, using self-hosted open-source platforms where they fit. The organization stays responsible for its controls, and an independent assessor, not DeployOpen, decides whether the evidence meets the standard.

How we scope

Agree in writing which processing systems, identity flows, network paths and logging sources fall inside the Article 32(1)(b) scope.
Confirm which breach types (confidentiality, integrity, availability) each system could realistically suffer and record the owner of each property.
Fix deliverables, responsibilities and timelines in the written scope before any work starts, since most engagements are fixed-scope.

How we build

Configure access control, MFA and single sign-on on self-hosted identity platforms such as authentik, Keycloak, FreeIPA or Zitadel, as the scope requires.
Set network protection, transport and storage protection, centralized event logging and capacity limits, and harden default configurations.
Run security testing against the configured systems and fix findings before handover, so the evidence reflects the system as operated.

How we hand over

Document configuration baselines, access rules, MFA settings, logging coverage and capacity thresholds so an assessor can trace each control to its evidence.
Provide runbooks for administrators covering account onboarding, MFA enrollment, log review and capacity alerts.
Confirm with the client's assessor, in advance, which artifacts they will request so the handover package matches that request.

How we support

Support is available as a retainer for upgrades, configuration drift checks, repeated security testing and evidence refreshes.
Ongoing work can cover new applications added to single sign-on and changes to logging or capacity as the environment grows.
Ask for the retainer scope in writing, including which systems, reviews and response activities it covers and how often.

Article 32(1)(b) Confidentiality, integrity, availability and resilience