Article 32(1)(a) pseudonymization and encryption

What Article 32(1)(a) requires for pseudonymization and encryption

Article 32(1)(a) names the pseudonymisation and encryption of personal data as examples of appropriate technical measures, and the controller must choose them only after weighing the risk, the state of the art and the cost of implementation. If an auditor, a customer questionnaire or a data protection officer asks how personal data are protected, the answer must show which measures were chosen, why they fit the risk, and where the keys live. The GDPR does not prescribe a particular algorithm, key length or product, and it does not impose a general duty to pseudonymise every dataset. The controller owns that decision and must be able to justify it in writing, including why a measure was left out when a reasonable alternative existed.

Key handling is usually the hard part. Encryption only protects data if the keys are held separately, access to them is tightly limited and logged, and rotation and recovery are tested. For pseudonymisation, Article 4(5) requires the additional information that links a pseudonym back to a person to be kept separately and protected by technical and organisational measures. Ask who can read the key store, whether application administrators can reach both the data and the mapping table, and how a key compromise would be detected. Platforms such as OpenBao can hold and rotate encryption keys for applications, but the design of who may use them remains the controller's responsibility and needs to be documented.

The GDPR requires no certificate for this measure. No independent body must test or attest that encryption or pseudonymisation is in place, and certification under Article 42 is voluntary and does not reduce the controller's responsibility. Evidence therefore has to be assembled by the organisation itself: the risk assessment, the data flow and key inventory, configuration exports, key rotation records and access reviews. An implementation partner can prepare that evidence, but only an independent assessor can issue an assurance report that a client or regulator may accept. Confirm with your own counsel or assessor which of these artefacts your customers and supervisory authority expect.

How an assessor tests pseudonymization and encryption

This table sets out, row by row, what an assessor tests for Article 32(1)(a), what evidence they ask for, and the findings that most often appear. Read each row as a question the assessor will put to your records and systems, then check the evidence you can produce before the review starts.

Test area	Evidence requested	Common findings
Data inventory and locations	Data map of personal data stores, backups, logs and exports, with at-rest and in-transit paths	Stores missing from the inventory, such as backups, search indexes, logs or developer copies
Pseudonymization decision	Written justification of whether pseudonymization is applied, which fields, and who holds the re-identification capability	No documented decision, or pseudonymized data treated as anonymous when re-identification remains possible
Encryption coverage per store	Configuration exports showing encryption at rest and TLS settings for each system in the inventory	Encryption enabled on the primary database but not on replicas, object storage, caches or file shares
Key generation and storage	Key management policy, key hierarchy diagram, and proof keys are held in a dedicated store, not beside the data	Keys stored in configuration files, source repositories or the same volume as the encrypted data
Key access and rotation	Access lists for key administrators, rotation schedule, and logs of key use and rotation events	Shared administrator accounts, no rotation history, or no record of who can decrypt
Separation of re-identification keys	Architecture showing the mapping table held apart from pseudonymized data, with separate access controls	Mapping table in the same database and reachable by the same roles as the pseudonymized records
Breach communication reliance on encryption	Documented analysis showing whether encrypted data were unintelligible and whether keys were compromised	Reliance on encryption claimed without evidence that keys stayed outside the breached environment
Transfer risk relying on encryption	Records showing who holds the keys for any transferred data and where those keys are kept	Keys held by a non-EEA provider while the exporter assumes the data are protected

How to implement encryption and key separation, step by step

This sequence moves from knowing where personal data sits to proving that encryption and key separation work in practice, so each decision about pseudonymization or encryption is traceable to a specific dataset and a documented key arrangement.

Inventory personal data stores and flows
The privacy or data owner and the system owners list every store, backup, log, export and integration that holds personal data, including copies held by sub-processors and support tooling. Each entry records the system, the data categories, the storage location and the systems that read or write it. The output is a data flow register. You know this step is done when a system owner can confirm that the register matches what runs in production, and when no store is missing from the list.
Decide per dataset where pseudonymization applies
For each entry, the privacy lead and security architect decide whether the processing can run on pseudonymized data, which means the identifiers are replaced and the mapping table is held apart under its own controls. Keep in mind that pseudonymized data remain personal data under the GDPR, so this step reduces exposure but does not remove the obligations. The output is a decision record per dataset stating the chosen measure and the reason. It is complete when every personal data store has a recorded decision, including the decision not to pseudonymize.
Decide per dataset where encryption applies
For each dataset, the security architect determines whether data at rest, in transit, in backups or in exports need encryption, and whether file names, metadata or folder structure also expose personal data that the chosen tooling does not protect. Where a product encrypts only file contents, record that gap and the compensating control. The output is an encryption scope table that covers storage, transport and backup paths. It is complete when every path in the register has an encryption status and a named owner.
Select algorithms and key management for the risk
The security architect selects established, state-of-the-art algorithms and a key management service that fits the risk level, the platform and the operating model. Confirm with each vendor which algorithms, key lengths and key storage options the product supports, and do not assume them. Where a transit encryption service is used, confirm whether it supports versioned keys and rotation, since that affects later steps. The output is a cryptography standard for the platform and a short vendor confirmation for each product. It is complete when the chosen design has been reviewed against the data flow register.
Separate keys from data and from unneeded administrators
The security engineer places key material in a location and under an access model where the data custodian cannot read keys by default, and where administrators who manage the storage do not hold decryption rights they do not need. Keys held in the same system and by the same administrator as the encrypted data provide little separation. Record which roles can create, use, rotate and revoke keys. The output is a key custody record listing each key, its location, its custodians and its access path. It is complete when a test shows that a storage administrator alone cannot decrypt the protected data.
Test restores and key rotation
The operations team runs a restore of encrypted and pseudonymized datasets from backup into a test environment, using only the documented key arrangement. They then rotate a key under the documented procedure and confirm that existing data remains readable and that new writes use the new key version. Keys that are lost or unavailable make encrypted data unrecoverable, so restores must be tested before they are needed. The output is a restore test log and a key rotation record. It is complete when both tests pass and the results are filed with the key custody record.
Record decisions and link them to breach and transfer files
The privacy and security leads consolidate the register, the decision records, the custody record and the test logs into the documentation set for Article 32. They also note how encryption status affects breach assessment, since data encrypted with a sound algorithm whose key was not compromised may fall outside the notification duty under Article 34(3)(a). Likewise, they record how key location affects transfer risk for any export outside the EEA. The output is a consolidated security measures file reviewed on a set schedule. It is complete when an assessor could trace each dataset from the register to its measure, key and test evidence.

Which self-hosted open-source tools produce encryption and key evidence

Nextcloud is an AGPL-3.0-only self-hosted file platform that can apply server-side encryption to file contents at rest on local and external storage. The protection covers what is written to disk, but the keys are kept on the server, so the evidence shows that the platform encrypts content. It does not show that a server compromise would leave data unreadable. Treat the encryption setting as one input to Article 32(1)(a), not as a finished measure.

Content encryption: Server-side encryption protects file contents at rest, and the admin configuration documentation describes how it is enabled and managed.
Key location: Keys sit on the server, so the controller must record who can reach them and how the server is hardened.
Metadata gap: File names and folder structure are not encrypted, so personal data can still be exposed through paths and names.
Storage scope: Confirm which local and external storage backends are covered and whether any are excluded.
Transport and access: Encryption at rest does not replace transport encryption or access control, which need separate evidence.

Confirm the encryption configuration, key storage location and metadata exposure against the client's actual deployment before listing Nextcloud as evidence.

Evidence that passes for pseudonymization and encryption

Assessors testing Article 32(1)(a) look for proof that the controller decided where pseudonymization and encryption apply, that the protections are configured and that the keys are governed. The six artifacts below connect those decisions to records a reviewer can sample, and each one needs a refresh rhythm so it still describes the systems in place at audit time.

Data inventory of protected stores

A register listing each store holding personal data, whether it is encrypted at rest, whether identifiers are pseudonymized and where the additional information is kept. Assessors use it to pick systems for sampling, so a store missing from the inventory is a finding even if it is encrypted. Keep it current by tying each new database, bucket or backup target to a change ticket that cannot close until the inventory row is updated. Confirm that backups and logs appear in the register too.

Pseudonymization decision and risk rationale

A dated record stating which datasets are pseudonymized, why, what additional information exists and who holds it, and the residual risk accepted. The EDPB treats pseudonymized data as still personal data, so the record should not describe the output as anonymous. Review it at each material change to the dataset, the recipients or the re-identification route, and capture the sign-off of the accountable owner and the data protection officer where one is appointed.

Encryption configuration exports

Machine-generated exports showing the encryption settings that actually run, such as server-side encryption modes, TLS versions and cipher settings, and volume or database encryption flags. A screenshot of the admin page is weaker than a configuration file with a timestamp and hash. Schedule the export to run on a fixed cadence and on each configuration change, and retain the diffs. Note any gap, for example that Nextcloud server-side encryption does not cover file names or folder structure, and show how that residual exposure is handled.

Key management policy with custody records

A policy defining who may create, store, rotate and destroy encryption keys, where keys are held and which keys are kept separate from the data they protect. Under Article 4(5) the additional information used for pseudonymization must be kept separately and protected, so the custody record should show that separation. Update the custody register whenever a key holder changes and sign off the policy at least annually, recording the reviewer and the date of each approval.

Access reviews for key administrators

Periodic reviews confirming that only named people and service identities can administer key stores, approve key export or read the pseudonymization mapping table. Assessors look for the reviewer, the population reviewed, the decision taken on each account and the removals actioned. Separate the key administrator role from the data administrator role in the review. Run the review on a recurring schedule and after staff moves, and file each review with a dated sign-off.

Rotation and restore test records

Logs from key rotation events and from restore tests of encrypted data, showing that rotated keys still decrypt retained data and that backups can be opened with the escrowed or managed keys. A rotation without a successful restore test can leave data unreadable after an incident. Record the test date, the scope, the operator, the outcome and any failure with its fix. Repeat the test on the cadence set in the policy and after any change to the key service.

What meeting Article 32(1)(a) costs in money and effort

This table lists the cost components of pseudonymization and encryption under Article 32(1)(a), who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to shape a written scope and to check that each quote covers the same components. No figures are given because none are supplied; ask each bidder for the amounts.

Cost component	One-time or recurring	What drives it up or down	What to request in a quote
Tooling or licenses	Recurring	Commercial key management or encryption products are priced by vendor terms. Self-hosted open-source components such as OpenBao remove license fees but not hosting or support costs. Confirm license terms with each vendor.	Itemized license or subscription lines, support tiers, and any per-node or per-environment fees
Engineering time for encryption and key design	One-time	Number of data stores, whether file names and folder structure need protection beyond server-side encryption, and whether applications must be changed to encrypt fields or pseudonymize identifiers	Written inventory of stores in scope, design document for key hierarchy and pseudonym mapping, and named deliverables
Key separation and pseudonym mapping storage	One-time, then recurring	Number of pseudonymized datasets and whether the additional information is held in a separate, access-restricted system in the EEA or another trusted location	Architecture showing where mapping tables and keys sit, who can reach them, and how separation is tested
Key operations and rotation	Recurring	Number of keys and versions, rotation frequency set by the organization, and whether a managed key service is bought or self-hosted. Self-hosting moves effort into patching, backup of key material and on-call duties.	Rotation procedure, key backup and recovery steps, staff hours assumed for operations, and the service levels offered if managed
Evidence upkeep	Recurring	Frequency of configuration reviews, changes to encrypted stores, and the number of teams that must produce records	List of evidence artifacts, update cadence, and who maintains each record
External review or testing	Recurring, usually per engagement	Scope of cryptographic configuration review, transfer exposure needing a transfer impact assessment, and whether keys are retained outside the EEA	Fixed scope with tested components, deliverables, and a statement of what the review does not cover
Auditor sampling and assessor time	Recurring, set by the assessor	Number of systems sampled, number of encryption and key changes during the period, and clarity of records	Assessor's written sampling approach and the evidence list they expect before fieldwork (the organization pays the assessor directly)

Who does what: the organization, a partner and the assessor

The controller or processor remains responsible for Article 32(1)(a) in full. Its own team decides which personal data are pseudonymized, which encryption applies to which data stores and transfers, who holds the keys, and how those choices fit the risk assessment and the breach response plan. Responsibility cannot be handed to a vendor or consultant, even when the work is outsourced. The organization must also be able to explain its choices to a supervisory authority, including why a given data set is treated as pseudonymized rather than anonymized, and why encryption is or is not considered sufficient in a breach scenario.

Decisions on scope: Naming the data sets, fields and backups that are pseudonymized or encrypted, and recording the reasons.
Key governance: Setting who may hold or use keys, where they are kept, and how rotation and revocation happen.
Records: Keeping the mapping tables and additional information separate from the pseudonymized data, under documented access rules.
Breach and transfer reasoning: Documenting how encryption affects notification decisions and transfer risk assessments.
Operating evidence: Retaining configuration, key rotation logs and access reviews.

Check that each named owner can show the decision record and the evidence that the control runs as described.

Where organizations fall short on encryption and pseudonymization

Most shortfalls under Article 32(1)(a) are not missing encryption. They are encryption that protects the wrong thing, keys that sit beside the data, and decisions nobody wrote down. Each card below names one gap, why it weakens the security argument, and the fix an assessor or regulator will expect to see.

Keys stored beside the data

Encryption at rest is weak when the decryption key sits on the same server, in the same bucket or in the same backup set as the ciphertext. Anyone who can copy the storage can usually copy the key too. Check where each key lives, who can read it, and whether the key store is separate from the systems it protects. Where keys are held by a server-side feature, document that the controller or a trusted party in the EEA keeps control. Separate key custody from data custody and record it in the design.

No documented pseudonymization decision

Many teams pseudonymize some fields in analytics or test data without recording why, what the re-identification key is, or who holds it. Article 4(5) requires the additional information to be kept separately and protected by technical and organizational measures. Illustrative case: a test database uses hashed customer IDs, but the same hashing salt sits in the application repository. Write down the purpose, the mapping owner, the storage location of the mapping, and who may reverse it.

Encryption on databases but not backups or logs

Teams often encrypt the primary database and forget the copies: nightly backups, replicas, exports, debug logs and monitoring stores. Those copies frequently hold the same personal data and sometimes lose the protection applied to the source. Build an inventory of every location where personal data lands, then check each one for encryption, key ownership and access rights. Treat an unencrypted backup as a possible notifiable exposure, not a minor gap.

Unprotected file names and metadata

Server-side encryption in some file platforms protects file contents but not file names or folder structure. A folder called with a patient or employee identifier can disclose personal data even when every file is encrypted. Check which metadata the design depends on, decide whether names themselves carry personal data, and rename or restructure where needed. Confirm the exact coverage with the vendor for your version, since encryption scope varies by product and configuration.

Untested key rotation

Key rotation that exists only in a policy document often fails the first time it is needed. Rotation can break decryption of older records, stall batch jobs or leave stale copies of old keys in configuration files. Test rotation in a non-production environment, confirm that versioned keys still decrypt historical data, and keep dated evidence of each run. Ask the platform owner which key versions remain decryptable and how retired versions are destroyed.

Breach and transfer arguments without key evidence

Organizations often claim that a breach need not be communicated, or that a transfer is low risk, because the data were encrypted. Those arguments hold only when the key was not compromised and remained under the controller's control or with a trusted party in the EEA or an equivalent jurisdiction. Without evidence of key custody, access logs and the key location at the time of the incident, the argument is an assertion. Keep a written record that shows where each key was held and who could use it, and review it before relying on encryption in a notification or transfer assessment.

How much work is encryption and pseudonymization, and can we do it ourselves?

How much effort does encryption and pseudonymization take?

The effort depends on how many systems hold personal data, how many of them already encrypt it, and how much pseudonymization the processing actually needs. No supplied source gives a standard effort figure, so treat any number from a vendor or consultant as a claim to test. The main drivers are the inventory of data stores (databases, file shares, backups, logs, analytics exports and SaaS tenants), the number of key management decisions, and whether applications must change to tokenize or pseudonymize fields. Ask for a written scope that lists each system, the measure applied to it, who changes configuration, and what testing proves it works.

How long does it take to get encryption evidence ready?

Timing depends on the scope and on how quickly the organization can confirm where its data sits. No supplied source gives a duration, so confirm it in the written scope. Evidence work usually follows a predictable path: inventory, configuration changes in each system, key handling design, a test that shows encrypted data cannot be read without authorization, and records that show the setup in operation. Ask any provider to state which steps depend on your staff, such as approvals, change windows and access to cloud accounts.

What must our team supply before a partner can start?

Expect to supply the data inventory, system owners, access to the hosting accounts or data centers, and decisions on key custody. Without these, work stalls. A partner can prepare configurations and evidence, but the organization owns its controls and its keys. Before work starts, confirm which people must approve changes, who holds administrative access to key stores, and where backups and logs are kept.

Can an internal team encrypt and pseudonymize data without a partner?

Yes, many internal teams do this work, provided they have engineers who know the storage layers, key management and the applications that handle personal data. A partner adds most value when the organization lacks capacity, runs several platforms, or needs an outside view of the design. Whichever route you choose, the organization keeps responsibility for its controls. Independent auditors or certification bodies, not implementation partners, issue any report or certificate. Confirm internal skills in key rotation, backup handling and application changes before committing to an in-house plan.

Is pseudonymization mandatory under the GDPR?

No. The GDPR does not impose a general obligation to pseudonymize data, according to EDPB Guidelines 01/2025 on pseudonymisation, which were adopted as a version for public consultation. Pseudonymisation is named in Article 32(1)(a) as one appropriate measure among others, chosen after a risk assessment. Pseudonymized data that can still be linked back using additional information remain personal data, so the obligations continue to apply. Read the EUR-Lex text of the GDPR and confirm with your legal team whether pseudonymization reduces your risk in a specific processing activity.

How does encryption change breach notification under Article 34(3)(a)?

Encryption can remove the duty to tell affected individuals, but only when the encrypted data were rendered unintelligible to anyone not authorized to access them. Under Article 34(3)(a), communication to data subjects is not required in that case. EDPB Guidelines 9/2022 add that a breach of data encrypted with a state-of-the-art algorithm is still a personal data breach that must be assessed, yet if the key was not compromised the data are in principle unintelligible and the breach is unlikely to adversely affect individuals. Confirm that keys sit outside the compromised system, that key access is logged, and that your breach procedure records this analysis.

Does encryption alone resolve transfer risk for personal data?

No. EDPB Recommendations 01/2020 treat strong encryption as an effective supplementary measure for transferred data only when the keys are retained solely by the exporter or by a trusted entity in the EEA or an equivalent jurisdiction, and the data need no access in the clear at the destination. If a foreign provider can access data in the clear, encryption alone does not close the risk. Confirm who holds keys, where administrators sit, and whether any remote support can view plaintext before you rely on this measure in a transfer impact assessment.

How DeployOpen scopes and prepares encryption evidence

DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, including the encryption, key management and pseudonymization configuration that Article 32(1)(a) pseudonymization and encryption asks you to account for. We prepare the systems and evidence; your organization owns the controls and any assessment is performed by an independent party.

How we scope

Inventory which personal data stores, backups and logs need encryption at rest and in transit, and which hold data that must be pseudonymized.
Record where encryption keys would sit, who administers them and whether any key could be reached from outside the EEA.
Agree the scope, deliverables and timelines in writing before work starts, since most engagements are fixed-scope.

How we build

Configure server-side encryption for file storage and confirm in testing which metadata, such as file names and folder structure, remains unencrypted.
Deploy a secrets and key management service with versioned keys and rotation, keeping key custody inside the boundary you define.
Set up pseudonymization where it is part of the agreed design, with the additional information stored separately under access controls.

How we hand over

Document the configuration, key custody model, rotation schedule and the data each control protects, in a form your assessor can test.
Provide test records showing encryption settings, key rotation events and access restrictions on the separated key material.
Hand over runbooks for key recovery and for confirming that encrypted data stayed unintelligible during an incident.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, so configurations stay current with platform releases.
Review key custody and encryption settings when the data flow, hosting location or sub-processors change.
Confirm with your auditor or assessor which evidence they will accept, since DeployOpen prepares evidence but does not issue reports or certificates.

Article 32(1)(a) Pseudonymization and encryption