Article 5(1)(f) Integrity and confidentiality requirements

What Article 5(1)(f) requires of personal data security

Article 5(1)(f) requires that personal data be processed in a way that ensures appropriate security, including protection against unauthorized or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organizational measures. If you are a compliance lead, engineer or buyer facing this principle, the practical question is not whether the principle applies (it applies to every processing activity) but which measures you can show are appropriate for the data and the risk. The principle protects three security properties: confidentiality (only authorized parties can see the data), integrity (the data cannot be altered or corrupted without authorization) and availability (the data can be accessed and restored when needed). Each property maps to failure modes you can name in your own environment, such as an over-permissive administrator role, a silent schema change, or a backup that cannot be restored after ransomware.

The principle is the security anchor of the GDPR, and it connects to two other duties. Article 32 sets out the detailed obligation that controllers and processors must meet, naming measures such as encryption and pseudonymisation, the ability to restore availability, and regular testing of effectiveness. Article 4(12) defines a personal data breach as a security breach leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data. A breach is therefore the moment this principle fails in practice, and it is the trigger for the notification duties in Articles 33 and 34. Under Article 83, an infringement of Article 5 falls in the higher fine tier of EUR 20 million or 4% of total worldwide annual turnover, whichever is higher, while an Article 32 infringement falls in the lower tier of EUR 10 million or 2%. In practice, regulators usually start by asking for the Article 32 evidence (risk assessment, access controls, encryption, logging, restore tests), because that evidence shows whether the principle was met.

What usually makes this hard is that the principle is broad. It asks for appropriate security without listing the measures, so the real work is turning it into specific, testable controls for each system that holds personal data. Start by listing the systems, the data classes they hold and the risk of each failure mode, then decide which measures address each property. Confirm with your own legal and security teams how the appropriate level is documented for your organization, and keep the decisions and their reasons on file, since an assessor will ask why a control was chosen as much as whether it exists.

Which systems, data and teams fall under the security principle

Article 5(1)(f) covers any place personal data is processed, stored, copied or accessed, not only the production application. The cards below list the scoping decisions that most often change the size of the work, so they can be settled before any control design or evidence collection starts.

Systems that store or transmit personal data

Every application, database, file store, message queue and integration that holds or moves personal data sits inside the principle, including test and staging copies that contain real records. Decide which systems hold personal data by inventory and data flow, not by the name of the application. Check for exports, reports, spreadsheets and analytics pipelines, because these often copy data outside the main system and are easy to miss. Assessors will ask how each store is protected against unauthorized access and accidental loss.

Backups and logs holding personal data

Backups and logs are personal data stores in their own right. A backup copy of a database carries the same confidentiality risk as the source, and application logs often record identifiers, IP addresses or request bodies. Decide who can restore backups, where copies are kept, how they are encrypted, and how restores are tested for integrity. Confirm that log pipelines and log stores have access controls matching the systems that generate them.

Identity and access infrastructure

Directories, single sign-on providers, secrets managers and key stores control who can reach personal data, so their compromise defeats every other control. Decide which identity components are in scope, how administrator accounts are separated from daily accounts, and where encryption keys are generated and rotated. Record which applications delegate sign-in to a central identity provider, since a gap in one integration can bypass the rest.

Processors and sub-processors

When a hosting provider, managed service or support vendor processes personal data for you, the security obligation still rests with the controller and its processors under the shared Article 32 duty. Decide which vendors touch personal data, including remote support access and sub-processors they use in turn. Confirm each contract states the security measures expected and how the vendor will notify you of a breach. Vendor access paths often fall outside internal reviews unless they are listed up front.

Staff and contractors with privileged access

Administrators, database operators, support engineers and contractors with elevated rights can read or change personal data at scale, so they are a core part of the principle rather than an HR matter. Decide which roles hold privileged access, how access is granted, reviewed and removed, and which activity is logged. Include temporary and emergency access paths, such as break-glass accounts and vendor support logins. Assessors typically test whether these accounts are limited, approved and traceable.

How an assessor tests the security principle

This table compares what an assessor examines for Article 5(1)(f), the evidence each area usually produces, and where findings tend to appear. Read it as a map of questions an assessor asks about whether your measures fit your risk, not as a checklist to tick off.

Test area	What the assessor checks	Evidence requested	Common findings
Risk assessment	Whether the chosen measures follow from a documented assessment of risks to personal data	Risk register, data flow maps, the rationale for each control, dated review records	Measures listed without a risk basis, or assessments not refreshed after system changes
Access control records	Whether only people and services that need personal data can reach it, and whether access is removed when roles change	Role definitions, access review logs, joiner and leaver tickets, privileged account inventory	Shared administrator accounts, stale access after staff moves, no periodic review
Encryption and key management	Whether data is protected in transit and at rest, and who controls the keys	Configuration exports, key inventory, rotation records, key access logs	Keys stored beside the data they protect, no rotation history, undocumented exceptions
Backup and restore tests	Whether personal data can be recovered after loss or destruction, and whether restored data stays protected	Backup policy, restore test reports with dates and results, encryption status of backup copies	Restores never tested, backups outside the access controls applied to production
Incident and breach handling	Whether security events are detected, triaged and recorded, and whether breaches are assessed against the Article 4(12) definition	Incident logs, breach register entries, triage decisions, lessons learned records	No record of decisions not to notify, detection gaps for unauthorized access
Processor oversight	Whether suppliers that handle personal data are bound to equivalent security and are checked	Processing agreements, security questionnaires, audit or assurance reports from suppliers, sub-processor lists	Contracts without security terms, no review of hosting or support providers

How to implement the principle in systems, step by step

This sequence turns the Article 5(1)(f) security principle into a documented, tested set of system controls, with each step producing evidence that the controller can show to a supervisory authority or auditor.

Inventory personal data and the systems that hold it
The controller lists every system, service and storage location where personal data is collected, stored, transmitted or processed, including backups, logs, exports, analytics copies and sub-processor environments. Each entry records the data categories, the owner, the hosting location and the purpose it serves. The inventory is complete when the system owners have confirmed it and no processing activity in the record of processing lacks a matching system entry. A partner can draft the first inventory from configuration and interviews, but the controller must approve it because only the controller knows the purposes and owners.
Assess risk to confidentiality, integrity and availability
For each system in the inventory, the team identifies threats that could cause unauthorized access, unlawful processing, accidental loss, alteration or destruction, and weighs their likelihood and impact on individuals. The output is a risk register that maps each risk to the security property it affects, the existing controls and the residual risk. The register is complete when the controller has accepted residual risks in writing. The partner can run the workshops and draft the register, while the controller signs off on risk acceptance.
Select technical and organizational measures
Using the risk register, the team selects measures such as encryption at rest and in transit, key management, identity and access controls, logging, backup and restore, network segmentation, and staff procedures. Each measure is tied to the risks it addresses and to the Article 32 example measures it implements. The output is a control selection with a rationale for each choice and any measures deliberately excluded. The controller approves the selection, since it defines the appropriate level of security for its own processing.
Implement and configure the chosen controls
Engineers apply the selected measures to each system and write a configuration baseline that records settings, versions and owners. For example, a team using Nextcloud can enable server-side encryption and note that file names and folder structure remain unencrypted, which the risk register must reflect. Secrets and encryption keys are placed in a managed store such as OpenBao, and applications delegate sign-in to a central identity provider such as authentik or FreeIPA. The step is done when each baseline is stored under change control and deviations are logged with an approver. Partners can implement and document this work under a fixed scope.
Test access controls, integrity and restoration
The team tests whether access rights match the approved roles, whether unauthorized access attempts are detected and logged, whether data changes can be traced, and whether backups restore within the recovery objectives the controller set. Results are recorded as test scripts, screenshots, log extracts and restore reports with dates and the tester's name. Failed tests return to the configuration step with a tracked fix. The controller reviews the results and decides whether residual risk remains acceptable. Partners can execute and report on the tests, but only the controller can accept the outcome.
Maintain evidence and review on change
The controller schedules periodic reviews and triggers an extra review whenever a system, sub-processor, data category or threat changes, or after a personal data breach. Each review updates the inventory, risk register and baselines, and records what changed and why. The step is complete when the evidence set is current and a named owner can produce it on request. Partners can support recurring reviews and testing as a retainer, and the controller remains accountable for the outcome.

Which evidence passes an audit for this principle

Assessors looking at Article 5(1)(f) want proof that protections exist and keep working, not a policy that says they should. The artifacts below are the ones that connect a security principle to something a regulator or auditor can sample. Each should be refreshed on a schedule so the record reflects operations over time.

Current risk assessment

The risk assessment shows which personal data sets exist, which threats apply to them, and which measures were chosen to reduce those risks to an appropriate level. Article 5(1)(f) asks for security that is appropriate, so this document is where the choice is justified. Check that each system holding personal data appears, that the likelihood and impact ratings were reviewed after any significant change, and that every treatment decision names an owner and a status.

Access review records

Access reviews are signed records showing who can reach personal data, why, and whether that access was still needed when the review ran. They evidence protection against unauthorised processing, which is the core of the confidentiality limb of the principle. Keep the export from each directory or identity provider, the reviewer's sign-off, and the list of revocations made, and confirm that privileged and service accounts are covered in the same cycle.

Encryption configuration exports

Configuration exports prove which encryption settings were active on the systems that store or transmit personal data. For a self-hosted file platform, this means the server-side encryption state, the storage backends covered, and the key location. Note what the export does not cover, such as file names and folder structure in Nextcloud server-side encryption, so that those gaps are documented and handled by other controls rather than assumed to be encrypted.

Key rotation logs

Key rotation logs show that cryptographic keys are replaced on a defined schedule and that older ciphertext remains readable where it must be. Versioned keys in a secrets engine such as OpenBao produce a history of key versions and rotation events that an assessor can sample. Check that rotation events match the documented policy, that decommissioned keys are retired with a record, and that access to key material is itself logged.

Backup restore test reports

Restore test reports prove that personal data can be recovered after loss, destruction or damage, which is the availability side of the accidental-loss protection in the principle. A backup that has never been restored is not evidence. Record the date of each test, the data set restored, the time taken, the integrity check performed, and any failures and their fixes. Confirm that restored data still applies the same access controls and retention rules as production.

Incident and breach records

Incident records show how the organisation detected, classified and responded to security events affecting personal data, including events that were judged not to be personal data breaches. Under Article 4(12), a breach can involve loss, alteration or unauthorised access, so each record should state which of confidentiality, integrity or availability was affected, as the EDPB breach guidelines describe. Review closed incidents for root cause and confirm that corrective actions were tracked to completion.

How self-hosted open-source tools support the evidence

Article 5(1)(f) is met through the technical and organizational measures an organization chooses and can show it operates. The four components below each cover one part of that picture: content encryption, key-based encryption of application data, sign-in delegation, and central Linux identity. Each one produces some evidence, and none of them makes the organization compliant on its own.

Nextcloud server-side encryption

Server-side encryption in Nextcloud protects file contents at rest on local and external storage, with keys kept on the server. It does not encrypt file names or folder structure, so personal data can still be visible in metadata. Confirm in your own environment whether file names and folder paths contain personal data, and document that residual exposure in your risk assessment. Keep the encryption configuration and key handling procedures as evidence that stored file contents are protected.

OpenBao transit secrets engine

The OpenBao transit engine encrypts and decrypts application data without storing the ciphertext inside the engine, signs and verifies data, and supports versioned encryption keys with key rotation. This lets applications keep personal data encrypted in their own databases while key custody stays separate. Evidence includes key policies, rotation records and access logs. Confirm who can call encrypt and decrypt operations, and how old key versions are handled when data is re-encrypted.

authentik identity provider

authentik acts as an identity provider through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so applications delegate sign-in to a single point. This supports access control evidence: who can sign in to which application, and how access is granted and removed. Confirm that each connected application actually enforces the sign-in it delegates, and that offboarding removes access in the applications that keep their own local accounts.

FreeIPA single sign-on

FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC, giving central control over user accounts and host access. It helps evidence who holds accounts on servers and workstations and when those accounts are changed. Confirm that privileged host access is reviewed regularly, that Kerberos ticket policies match your standard, and that services outside the Kerberos realm are covered by a separate access control record.

What meeting the security principle costs in money and effort

This table lists the cost components of meeting Article 5(1)(f) and marks each as one-time or recurring, with what drives it up or down. Use it to see who is paid for what before asking for a quote, since no supplied fact gives a price or duration for any component.

Cost component	Who is paid	One-time or recurring	What drives it, and how to keep it down
Tooling and licenses	Software vendors or subscription providers	Recurring	Commercial key management, identity and logging licenses scale with users, systems or data volume. Self-hosted open-source options such as OpenBao, authentik, FreeIPA and Nextcloud remove license fees, but hosting and support still cost money.
Engineering time for configuration and integration	Internal platform or security staff, or an implementation partner under a written scope	One-time, with later changes recurring	Number of systems that must enforce encryption, access control and single sign-on, and how many already share an identity setup. Reuse existing identity and key management where possible to shorten the work.
Encryption and key management setup	Internal staff or implementation partner	One-time, then recurring key rotation	Number of data stores and whether keys are held in-house. Confirm with the vendor what server-side encryption does not cover, such as file names and folder structure in Nextcloud, since gaps may need other controls.
Evidence upkeep	Internal compliance and security staff	Recurring	Frequency of access reviews, configuration exports, key rotation records and log samples. Automate evidence collection where the platform allows it and keep one owner per control.
External penetration testing or security review	Independent testing firm or consultant	Recurring, typically per cycle	Application count, architecture complexity and scope of in-house changes. Fix known weaknesses before testing to reduce retest effort, and agree scope in writing.
Auditor or assessor sampling effort	Independent auditor or certification body	Recurring per assessment cycle	Number of systems in scope, number of samples requested and quality of prepared evidence. Ready, consistent records shorten sampling. Ask the auditor for its sampling approach before work starts.
Breach response readiness	Internal teams, legal counsel or retained responders	One-time plan, recurring exercises	Number of systems holding personal data and the depth of logging. Keeping a tested response plan and clear logs reduces the effort of establishing whether a confidentiality, integrity or availability breach occurred.
Support and retainers	Implementation partner or internal platform team	Recurring	Upgrade frequency, patch cadence and number of platforms. Fixed-scope work followed by a defined support agreement keeps ongoing effort predictable.

Who owns the security principle, who prepares evidence and who assesses it

Your organization owns the security principle. Article 5(1)(f) is a duty on the controller, and the controller decides what level of protection is appropriate for each processing activity, accepts residual risk and answers to the supervisory authority if personal data is lost or exposed. Those decisions cannot be handed to a vendor or consultant, even when outside specialists do much of the technical work.

Risk decisions: Setting the risk appetite for personal data, deciding which processing activities need stronger protection and signing off on accepted residual risk.
Control ownership: Naming an accountable owner for access control, encryption key custody, logging, backup and breach handling, with documented responsibilities.
Policy and sign-off: Approving security policies, data classification rules and the breach response plan, and recording who approved them and when.
Operational monitoring: Reviewing alerts, access reviews and key rotation results in day-to-day operations, which a partner cannot do on your behalf after handover.
Breach decisions: Deciding whether an incident is a personal data breach and whether it must be notified.

Check that each control has a named internal owner and that the people who sign policies are the same people who answer regulator questions.

Where organizations fall short on the security principle

Most failures under Article 5(1)(f) are not exotic attacks. They are ordinary gaps where a measure was chosen without a documented reason, or where a protection exists on paper but was never tested or enforced. The cards below cover the gaps assessors and regulators most often find, and what closing each one looks like in practice.

No documented risk assessment

Controls get chosen because they are familiar, not because someone assessed the risks to the personal data. Without a written assessment that names the data, the threats and the likelihood and impact of each, a controller cannot show why encryption, access limits or logging were judged appropriate. Check that each system holding personal data has a dated assessment, that the chosen measures trace back to it, and that the assessment is reviewed when the system or its data changes.

Encryption keys stored beside the data

Encrypting a database or file store means little if the key sits in the same configuration file, volume or backup as the ciphertext. Anyone who copies the store also copies the means to read it. Check where each key lives, who can read it, and whether keys are held in a separate service with access logging and rotation. Server-side encryption in Nextcloud, for example, keeps keys on the server, so the surrounding key handling still needs to be designed deliberately.

Shared administrator accounts

When several engineers share one administrator login, the logs cannot show who changed a record, disabled a control or exported a dataset. Confidentiality and integrity both depend on attributable access. Replace shared accounts with named accounts, enforce multi-factor authentication for privileged roles, and route application sign-in through a central identity provider such as authentik, so access can be granted, reviewed and removed per person.

Backups never restore-tested

A backup that has never been restored is an assumption, not a control. Article 32 names the ability to restore availability and access in a timely manner as part of resilience, and a failed restore after ransomware is itself a personal data breach affecting availability. Check that restores are run on a schedule, that the time taken is measured, that backups are encrypted and that restored data keeps its access restrictions.

Personal data copied into logs and test environments

Production extracts loaded into staging, and identifiers written into application logs or error traces, create copies that rarely receive the same protection or deletion. These copies often sit outside the access model and outlive the purpose they served. Check whether test datasets are pseudonymized or synthetic, whether logs omit or mask direct identifiers, and whether copies are included in the retention and deletion schedule.

Processors without security terms

When a vendor, hosting provider or support contractor processes personal data for you, your security obligations extend to what they do with it. Contracts that say nothing about security measures, breach notice timing, access by their staff or sub-processors leave gaps no technical control can fill. Check that each processor agreement specifies the security measures expected, requires notice of a breach without undue delay, limits access to authorized staff, and states how data is returned or deleted at the end of the service.

Questions buyers and practitioners ask about Article 5(1)(f)

Does Article 5(1)(f) require a specific security technology?

No. Article 5(1)(f) requires appropriate security of personal data using appropriate technical or organizational measures, and it does not name products, algorithms or configurations. What counts as appropriate depends on the risks of the processing, the nature of the data and the state of the art. Encryption, access control, logging and backups are common measures, but the controller must show that the measures chosen fit its own processing. Confirm with your supervisory authority or auditor how they expect that fit to be documented, since the regulation sets the outcome and leaves the method to you.

How does Article 5(1)(f) differ from the Article 32 security duties?

Article 5(1)(f) is the overarching principle that personal data must be processed securely. Article 32 is the detailed obligation that applies to both controllers and processors, and it names example measures such as pseudonymisation, encryption, ongoing confidentiality, integrity, availability and resilience, timely restoration and regular testing. In practice, Article 32 is how most teams show compliance with the principle. The fine tiers differ: infringing Article 5 falls under the higher tier of EUR 20 million or 4% of worldwide annual turnover, while infringing Article 32 falls under EUR 10 million or 2%, whichever is higher in each case.

How much effort does meeting the security principle take?

The effort depends on how much personal data you hold, how many systems touch it, how many processors and sub-processors are involved, and how mature your existing security program is. The largest drivers are an accurate inventory of where personal data lives, the number of access paths into those systems, and whether you already have documented risk assessments and tested backups. No standard hours figure applies to every organization, so ask any consultant to show how the estimate is built from your inventory, system count and gaps. Most of the cost is one-time analysis and remediation, with recurring costs for monitoring, access reviews and testing.

How long does preparation usually take, and what drives the timeline?

No authoritative duration applies to Article 5(1)(f), so treat any published timeline as a planning assumption rather than a rule. The timeline is driven by the size of the data inventory, the number of systems requiring changes, the time needed to procure or deploy tools, and the speed of internal approvals. Delays usually come from unclear data ownership, legacy systems that cannot support encryption or logging, and waiting on processors to provide evidence. Agree a written scope with milestones before work starts so the schedule can be checked against real dependencies.

What does the internal team need to contribute?

The internal team owns the processing, the decisions about acceptable risk and the evidence. It needs to name owners for each system holding personal data, provide access to configuration and logs, approve the security measures chosen, and keep records that show they operate. Privacy or legal staff should confirm the purposes and retention rules that define what must be protected. Engineers and administrators need time to implement and test changes. An implementation partner can prepare systems and evidence, but it cannot accept the risk on the organization's behalf.

Can we meet the security principle in-house, and what does outside help add?

Many organizations can do this in-house if they have security engineers, a clear data inventory and the capacity to document decisions. Outside help is most useful when internal staff lack experience with encryption key management, identity integration or security testing, or when the timeline is tight. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, runs security testing and prepares evidence for assessments, under a fixed-scope written agreement. It does not issue audit reports or certifications, and assessment of the outcome remains with your independent auditor or regulator.

Which open-source components can support evidence for this principle?

Several self-hosted components can produce evidence for the principle, although none guarantees compliance on its own. Nextcloud server-side encryption protects file contents at rest with keys kept on the server, but it does not encrypt file names or folder structure, so you must assess that gap. OpenBao's transit secrets engine encrypts and decrypts application data without storing it and supports versioned keys with rotation. authentik and FreeIPA support centralized sign-in, which helps show access control. Confirm each capability against your version and configuration before relying on it in an assessment.

How DeployOpen scopes and prepares security evidence for this principle

DeployOpen plans, implements and documents the technical and organizational measures behind Article 5(1)(f) Integrity and confidentiality inside your own infrastructure, using self-hosted open-source platforms. We prepare systems and evidence for your assessments, while your organization owns its controls and any independent auditor or certification body issues the reports.

How we scope

Engagements are fixed-scope, with systems, data flows and deliverables agreed in writing before work starts.
We map which processing systems hold personal data and where encryption, access control and logging are needed for confidentiality and integrity.
The written scope names the Article 32 measures we will implement and the evidence each one should produce for your records.

How we build

We deploy self-hosted platforms in your cloud accounts, data centers or air-gapped networks, with encryption at rest and controlled key management.
We configure single sign-on and access controls so applications delegate authentication and access is limited to defined roles.
We test the configured measures against the scope and record results, including gaps that your organization must decide how to address.

How we hand over

You receive configuration records, architecture notes and runbooks that show how confidentiality and integrity are maintained.
Evidence packs include access reviews, key rotation records, logging settings and test results mapped to the agreed scope.
We document how the breach definition's confidentiality, integrity and availability categories would be recognized in your logs and alerts.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial scope.
Retainers can cover platform patching, key rotation reviews and periodic evidence refreshes ahead of your assessment cycle.
Your compliance lead or independent assessor remains responsible for judging whether the measures meet your obligations under Article 5(1)(f).