Article 5 GDPR principles: requirements and evidence

What Article 5 principles require from system design

If you are preparing for an audit, reviewing a product design, or deciding whether to bring in a partner, the core answer is this: Article 5(1) requires that every processing of personal data follows six principles, and the controller must be able to show that its systems put them into practice. The six principles are lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; and integrity and confidentiality. Each one is a design obligation, not a policy statement, so an assessor will look for the schemas, settings, jobs and logs that make it true. Breaching the basic principles carries the highest tier of GDPR fines under Article 83: up to EUR 20 million or 4% of total worldwide annual turnover, whichever is higher.

The principles are hard to evidence for two reasons. First, they are broad and apply to every processing purpose, so a single system may hold dozens of purposes, each with its own lawful basis, retention need and recipients. Second, they overlap with other obligations, so a control built for one principle often supports another. The EDPB's Guidelines 4/2019 on data protection by design and by default (version 2.0, adopted 20 October 2020) translate the principles into design and default elements with practical cases, and they are the most useful starting point for mapping each principle to a system component. Ask your team to list every purpose each system serves before reviewing any principle, because the purpose drives the other five.

This page is the overview for the principle-specific pages that follow. Read storage limitation for retention schedules and deletion jobs, and integrity and confidentiality for the security principle that links to Article 32. The accountability duty in Article 5(2) is covered in its own page, as are the lawful basis in Article 6, consent under Article 7 and special categories under Article 9. Confirm with your legal or privacy team which lawful basis applies to each purpose before you finalize any design decision, since the basis determines which data subject rights apply.

Which systems, data and teams the Article 5 principles reach

The Article 5 principles follow personal data wherever a processing purpose puts it, not only into the production database. Each card below is a place where personal data tends to hide, and each one changes which evidence an assessor will ask for. Decide the scope before designing controls, because a copy left out of scope is still a copy the principles reach.

Source systems and databases

Production databases, application stores and document repositories are the obvious starting point, and each one needs a documented purpose for every personal data field it holds. Check whether fields exist only because a past feature needed them, since purpose limitation under Article 5(1)(b) and data minimisation under Article 5(1)(c) apply to fields as much as to tables. Ask each system owner to list the purposes served and the fields that serve them.

Logs and telemetry

Application logs, access logs, error traces and monitoring pipelines often capture email addresses, IP addresses, user identifiers or request payloads without anyone deciding that they should. Treat them as processing in their own right, with their own purpose, field list and retention period. Check whether debug logging is enabled in production and whether log shippers forward data to third-party monitoring services.

Analytics and reporting copies

Data warehouses, business intelligence extracts and spreadsheets built for reporting are copies created for a new purpose, which triggers the purpose limitation test in its own right. Identify which copies contain direct identifiers and whether the reporting purpose needs them at all. Pseudonymised or aggregated extracts may satisfy the purpose with far less personal data, which is the design choice an assessor will expect you to have considered.

Non-production environments

Test, staging and development environments are frequently refreshed from production dumps, and those dumps carry the full personal data set into systems with weaker access control. Ask whether test data is masked, synthetic or a real copy, and who can reach each environment. A copy made for testing is a separate processing purpose, so it needs its own justification, access rules and deletion schedule.

Backups and archives

Backups preserve personal data beyond the point where the source record was deleted, which makes them central to storage limitation under Article 5(1)(e) and to the accuracy principle when a restored record reappears. Confirm the backup retention period, how deletion requests reach backup sets, and whether restores are tested against the same access controls as production. Ask for the documented procedure, not only the backup schedule.

Processors acting for the organization

Hosting providers, SaaS tools, support contractors and managed service providers process personal data on the organization's behalf, and the principles still bind the controller for that processing. List each processor, the categories of data it receives and the instructions it operates under. Scope decisions here change the evidence: contracts, sub-processor lists and transfer records join the internal system inventory as required artifacts.

How an assessor tests the Article 5 principles

This table compares how an assessor tests each Article 5(1) principle, the evidence usually requested and the gaps seen most often. Supervisory authorities judge the principles through documentation and how systems actually behave, and the GDPR itself issues no audit report or certificate, so the evidence has to show the system in operation.

Principle or sub-test	How the assessor tests it	Evidence requested	Common findings
Lawfulness, fairness and transparency (5(1)(a))	Document review of privacy notices, then interviews with product owners to compare notices with actual processing.	Record of processing, privacy notices, lawful basis recorded per purpose.	Basis not recorded per purpose; notices describe processing the systems no longer perform.
Purpose limitation (5(1)(b))	Inspect schemas, exports and data flows against the stated purposes, and interview staff about secondary uses.	Purpose register, data flow diagrams, change records showing new purposes were assessed.	Existing fields reused for new purposes without assessment; analytics extracts with no documented purpose.
Data minimisation (5(1)(c))	Inspect data dictionaries and forms for fields without a stated purpose, sample logs for personal data, and review default settings under Article 25(2).	Field inventory, data dictionary, default configuration, sampled log extracts.	Optional free-text fields collecting unneeded identifiers; full request bodies written to application logs.
Accuracy (5(1)(d))	Inspect validation rules, sample records for duplicates and stale entries, and time a rectification request through the workflow.	Validation rule configuration, deduplication reports, rectification tickets with timestamps.	No path to correct downstream copies; no named owner for rectification requests.
Storage limitation (5(1)(e))	Compare the retention schedule with deletion job configuration, then sample backups and logs for data kept past its period.	Retention schedule, deletion job run history, backup and log retention settings.	Deletion jobs exist but fail silently; backups keep data beyond the schedule. See the storage limitation page.
Integrity and confidentiality (5(1)(f))	Inspect access control, encryption and logging configuration, and review a sample of privileged access grants.	Access reviews, encryption settings, audit logs, incident records.	Shared accounts; privileged access never reviewed. See the integrity and confidentiality page and the Article 32 pages.
Accountability (5(2))	Check whether the other six points can be demonstrated from written records rather than recollection of staff.	Policies, versioned procedures, dated approvals and records of decisions.	Policies exist but do not match system behavior; no version history showing when rules changed.

Implementing the Article 5 principles in systems, step by step

This sequence turns the six Article 5(1) principles into system configuration, schema decisions and documented evidence, so that each principle can be traced to a specific design choice and a record that shows it was applied. The steps run from purpose definition through to a documented baseline that the controller can present to an assessor or supervisory authority.

Record the purpose for each processing activity
Start by listing every processing activity that touches personal data, and for each one write down the specified, explicit and legitimate purpose it serves. The product owner or business process owner drafts the entry, and the privacy lead reviews it against Article 5(1)(b). Keep the wording concrete, such as recording a customer's delivery address to dispatch orders, rather than a generic label like improving services. The output is a purpose register with one row per activity, linked to the system and the owner. The step is complete when every system in scope has at least one registered purpose and no field is processed for a purpose that is not listed.
Map data elements to each purpose
Build a field-level data inventory that connects each personal data element in databases, APIs, files and integrations to one or more purposes from the register. Engineers can extract the schema from databases and API definitions, and the data owner confirms why each field is needed. Any field with no purpose, or with a purpose that could be met with less data, is flagged for removal or redesign. The output is a data inventory that lists field name, data category, purpose, system of record and recipients. The step is complete when the inventory reconciles with the live schema and every flagged field has a documented decision.
Set schema and log minimisation defaults
Translate the inventory into defaults that apply without manual action, as Article 25(2) requires for the amount collected, the extent of processing, the storage period and who can access the data. In practice this means optional fields are not collected by default, free-text fields are restricted, logs omit or mask identifiers that are not needed for troubleshooting, and new records are visible only to roles that need them. The EDPB Guidelines 4/2019 on data protection by design and by default list design and default elements for each principle and are a useful checklist for reviewers. The output is a configuration baseline covering schemas, forms, logging levels and access defaults. The step is complete when a test record created with default settings contains only the fields the register permits.
Define accuracy correction paths
Accuracy under Article 5(1)(d) requires that reasonable steps are taken so that inaccurate data are erased or rectified without delay. Define how errors are detected, such as validation rules at entry, periodic reconciliation with source systems and reports from data subjects, and set a named owner and route for each correction. Include how corrections propagate to downstream systems, backups and processors, so a corrected record does not revert after a restore. The output is a correction procedure with validation rules, reconciliation checks and a propagation map. The step is complete when a test correction is traced through every system that holds the record and the owner has signed off the route.
Set retention and integrity controls
Attach a retention period to each purpose in the register and configure the systems to enforce it, including deletion or anonymisation jobs, backup retention and log retention. Pair this with integrity and confidentiality controls for the principle in Article 5(1)(f), such as role-based access, encryption in transit and at rest, change logging and backup testing. Confirm what the retention periods are with the business owner and legal counsel, since the GDPR does not set fixed durations for most data. The output is a retention schedule and a control baseline mapped to the systems that enforce them. The step is complete when a test deletion job runs against a sample dataset and the results are logged and reviewed.
Document the result as demonstrable evidence
Bring the outputs of the earlier steps together into a single compliance record that a controller can present under Article 5(2). The record includes the purpose register, data inventory, configuration baseline, correction procedure, retention schedule, control baseline and the test results that show each control operated. Store the documents under version control with named approvers and review dates, so changes are traceable. The output is a versioned evidence pack indexed by principle. The step is complete when an internal reviewer who was not involved can trace each of the six principles to a configuration setting, a test result and an owner.

Evidence that shows the Article 5 principles are applied

Article 5 is demonstrated through records that stay current, not through a one-time policy. The artifacts below connect purpose, minimization, accuracy, retention and security decisions to something a supervisory authority or auditor can inspect. Keep each one under version control with named owners and review dates so it reflects the systems as they run today.

Purpose register and processing records

A purpose register lists each processing purpose, the personal data it uses, the systems that hold it and the recipients. It is the first place an assessor checks whether data collected for one purpose has quietly moved to another. Each entry should name an owner and a review date, and any new system or integration should trigger an update before go-live. Check that every system in the inventory maps to at least one recorded purpose.

Data inventories and schema reviews

A data inventory records which fields exist in each database, API and file store, and why each field is needed. Schema reviews compare proposed changes against that inventory before a new column or data feed is approved. Assessors look for fields that no purpose justifies, such as optional identifiers copied into analytics tables. Keep the review record with the change ticket so the decision and its reviewer are traceable.

Log field standards

Logs often hold more personal data than the application that produces them, including IP addresses, user identifiers and request payloads. A log field standard defines which fields are permitted, which must be masked or hashed, and which must never be written. Test the standard by sampling production logs against it at each review. Record the standard's version and the date of each sample so you can show the control was checked, not only written.

Accuracy correction records

Accuracy depends on a procedure for correcting or erasing inaccurate data without delay. The evidence is the correction log: the request or detection source, the records changed, who made the change, and the timestamps for receipt and completion. Sources that feed the same person's data into several systems need a rule for propagating corrections. Review a sample of closed corrections to confirm the timestamps show the delay stayed within your internal target.

Retention rules and deletion job logs

Retention rules set how long each data category stays in identifiable form, and deletion job logs prove they run. Record the approved period for each category with its legal or business reason, then keep the job configuration in version control. The evidence that matters is the output: logs showing which records were deleted, when, and whether backups and replicas were covered. Confirm the periods with your legal and records owners, because they must come from your own assessment.

Access and change records

Access and change records show who could reach personal data and who altered the systems that govern it. Role assignments, access reviews and change approvals together demonstrate integrity and confidentiality in practice. Keep access reviews dated and signed, and retain the history of role changes so an assessor can reconstruct any period. Most inventory and documentation tools keep this history natively, so confirm each one retains it before you rely on it.

What meeting the Article 5 principles costs in money and effort

This table breaks the cost of meeting the Article 5 principles into its main components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. No price list exists for this work, so use the rows to build a written scope and ask for a quote against each line. The main takeaway is that schema and log engineering is usually the largest one-time effort, while evidence upkeep is the cost that recurs.

Cost component	One-time or recurring	What drives it up or down	Role of self-hosted open source
Tooling and licenses	Recurring (subscriptions) or one-time (perpetual)	Number of users, systems in scope and whether the vendor prices per seat or per asset. Confirm licensing terms in writing.	Open-source tools such as GLPI, BookStack and XWiki carry no license fee for the software itself. Hosting, storage and support still cost money.
Engineering time for schema and log changes	One-time for the initial redesign, recurring for new data fields	Number of personal data fields, age of the existing schema, and whether purposes are tagged in the data model. Legacy systems with unclear data flows take longer.	Open-source platforms let your own engineers change schemas and logging in code you control, which avoids vendor change requests but still needs skilled staff.
Purpose and retention mapping	One-time, then recurring on each new processing activity	Number of processing purposes, how many teams own them, and whether purposes already exist in documentation.	A wiki with version history, such as XWiki, can hold the purpose register and show who changed it and when.
Accuracy controls and data quality checks	One-time build, recurring operation	Number of sources feeding each record, frequency of updates from individuals, and the volume of correction requests.	Validation and reconciliation jobs can run on existing open-source data stacks, so cost is mainly staff time to design and monitor them.
Evidence upkeep	Recurring	How often configurations change, how many systems produce evidence, and whether evidence is collected manually or by tooling. This is usually the largest ongoing cost.	Compliance platforms such as CISO Assistant, which covers GDPR among its frameworks, can organize evidence, but its licensing and deployment effort should be confirmed before purchase.
External review or testing	Recurring or periodic	Scope of systems tested, whether privacy engineering review is included, and how often the review repeats after changes.	Independent testing is still bought from a specialist. Self-hosting does not remove the need, but it lets the tester examine the systems you run.
Assessor or auditor sampling	Recurring at each review cycle	Number of processing activities sampled, depth of records requested and the quality of evidence on the first pass. Ask the assessor for its sampling approach in writing.	Well-indexed evidence in a version-controlled wiki and an asset inventory in GLPI shortens sampling, because records can be located without manual searches.
Internal staff time for governance	Recurring	Number of owners assigned to each principle, frequency of management review and the degree of automation in asset and access inventories.	Role-based permissions in BookStack help limit who edits policy documents, which reduces review effort for approvers.
Implementation partner scope	One-time, with optional retainer	Number of systems prepared, documentation depth and whether testing is included. DeployOpen does not publish a price list, so request a written scope quote from DeployOpen or another provider.	Not applicable

Self-hosted tools that hold Article 5 evidence

Article 5 is demonstrated through records, policies, inventories and access controls that sit in your own systems. The four tools below can hold that evidence inside your infrastructure, but each one only records or structures what your team puts into it, and none of them enforces the principles by itself.

Compliance assessments in CISO Assistant

CISO Assistant (AGPL-3.0-only) ships a GDPR framework entry and can run assessments against it, with automatic mapping between frameworks. Use it to track, per principle, which measures you have implemented, who owns each one and what evidence supports it. Before relying on it, confirm in the installed version which Article 5 controls are present as discrete items, since coverage of individual principles is something to verify rather than assume. Check the mapping output before an assessor sees it.

Version history in XWiki

XWiki (LGPL-2.1-or-later) keeps every change to a page under version control, recording what changed, when and by whom. That history is useful for a purpose register, where you need to show that a stated purpose was not quietly broadened, and for retention and minimisation policies that change over time. Ask whether your reviewers can compare any two versions and roll back, and whether the page history is retained long enough to cover your accountability period.

Role-based policy access in BookStack

BookStack (MIT) assigns abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. Use it to decide who may edit policy evidence such as accuracy procedures or retention schedules, while letting a wider group read them. Separating editors from approvers protects the record from being changed by the people it describes. Check that your permission model matches your approval chain, not just your org chart.

Asset ownership in GLPI

The GLPI Assets module (GPL-3.0-or-later) records computers, software, network equipment, printers, phones and racks, entered manually or pushed by the GLPI Agent through native inventory built into GLPI since version 10. Recording which asset holds which personal data store, and who owns it, lets you answer retention and accuracy questions with a named owner. Inventory only covers what the agent or your team registers, so reconcile it against cloud accounts and backups before treating it as complete.

Who owns Article 5 and what to outsource

As controller, your organization decides the purposes of processing, the lawful basis for each purpose, the retention periods and the sign-off on whether a design meets the principles. Engineers own the schemas, configuration and operational checks that carry those decisions into systems. Accountability under Article 5(2) cannot be handed to a vendor, so the people who approve purposes and retention need written authority inside the business, not only in IT.

Purpose and basis decisions: Legal, privacy and business owners record each specified purpose and its lawful basis before a field is added.
Schema and configuration ownership: Engineers decide which fields, log lines and default settings exist, and document why.
Retention and accuracy rules: Owners set retention periods and the correction process for inaccurate data.
Sign-off and review: A named role approves each new processing activity and re-checks it when systems change.
Evidence custody: Your team keeps the records, configuration exports and approvals that demonstrate compliance over time.

Before engaging anyone, confirm that each purpose in your register has a named owner who can approve changes without asking the vendor.

Where organizations fall short on Article 5 and how to close it

Most Article 5 failures are not missing policies. They are gaps between what the written principles say and what systems actually collect, keep, copy and expose. The cards below cover recurring gaps, the evidence an assessor or supervisory authority would ask for, and the closing action for each.

Purposes exist only in policy

Purpose limitation under Article 5(1)(b) requires specified and explicit purposes, but many organizations record them in a privacy notice and never bind them to the systems that process the data. A CRM field added for billing gets reused for marketing without anyone re-checking the purpose. Close the gap by tagging each data store, table and integration with its documented purpose, and by requiring a purpose review before any new use is switched on.

Logs that collect full identifiers

Application and web server logs often capture email addresses, IP addresses, national ID numbers or full request bodies by default. These copies sit outside the data minimisation controls applied to the primary database. Check log formats against a field allowlist, mask or hash identifiers at the point of write, and confirm with your logging vendor which fields are captured by default before you go live.

Test copies holding production data

Staging and QA environments are frequently refreshed from production dumps, which copies every personal data field into a less controlled environment. Data minimisation and integrity and confidentiality both apply to these copies. Replace direct copies with masked or synthetic datasets, restrict access to the same roles as production, and record each refresh so the copy can be deleted on the same schedule as its source.

Retention rules documented but not enforced

A retention schedule that says records are deleted after a set period has little value if no job runs, backups keep copies indefinitely and logs roll over on a different cycle. Storage limitation under Article 5(1)(e) needs deletion to happen in the systems. Ask for the scheduled job, its run history, and the backup retention setting, and treat any mismatch between them as a finding to fix.

Accuracy handled only at intake

Accuracy under Article 5(1)(d) asks for every reasonable step to erase or rectify inaccurate data without delay. Teams often validate fields when a record is created, then never revisit it when customers change details, when duplicate records appear after a merge, or when a source system sends a correction. Close the gap by defining update triggers, duplicate detection rules and a route by which rectification requests reach every downstream copy.

No change record for schema decisions

Adding a new personal data field, changing a column type or extending an export is a decision that affects minimisation and purpose, yet it is often made in a ticket that is later closed and forgotten. Under Article 25 the design choices behind each field should be explainable. Keep schema and data flow changes in version-controlled documentation with the reason, the approver and the purpose recorded, so an assessor can trace why the data exists.

Questions buyers ask about Article 5 cost, effort and outside help

How much effort does Article 5 take for a typical system?

The effort depends mostly on how many processing purposes the system serves, how many personal data fields it holds, and how many other systems receive copies of that data. Article 5 has no fixed workload of its own. Its work is spread across defining purposes, reviewing schemas and logs for unnecessary personal data, setting accuracy and correction workflows, configuring retention, and protecting the data. A system with one clear purpose and a short list of fields needs far less work than a customer platform that feeds analytics, marketing and support tools. Ask the implementation partner to show which purposes, data categories and downstream copies are in scope before agreeing a figure.

Can our team do Article 5 work in-house?

Yes, many organizations do much of the work in-house, and the GDPR does not require an outside party. Internal teams usually know the systems and data flows best. Outside help becomes useful when the purposes are not written down, when schemas were built without a data inventory, or when the team lacks time to test deletion and logging behavior. Treat the decision as a question of capacity and skills rather than of compliance status. The organization remains responsible for its controls in either case, and an independent assessor is not needed to meet the principles themselves.

What does Article 5 need from engineers and the data protection lead?

The work splits between the two roles. The data protection lead, or the person acting as one, owns the purposes, the lawful basis record, retention periods and the decisions about what counts as necessary. Engineers own the evidence: field-level schema reviews, logging configuration, accuracy checks in data pipelines, deletion jobs and access controls. Engineers also need the lead's written decisions to build against. When these roles work from different assumptions, the result is usually a schema that holds data nobody can justify. Agree a simple decision log at the start so each design choice traces back to a named purpose.

How long does Article 5 work take to complete?

Timing depends on scope, and no standard duration exists for this work. The main drivers are the number of systems, the state of existing documentation, how many teams must agree on purposes, and how much retention and logging behavior must be tested rather than assumed. A narrow review of one application may finish in a short cycle, while a multi-system programme needs staged delivery and repeated testing. Ask for milestones tied to specific deliverables, such as a completed purpose register or tested deletion jobs, rather than a single end date.

Do we need a GDPR certificate to meet Article 5?

No. The GDPR requires no audit, attestation or certificate. Compliance with Article 5 is an obligation the controller must meet and be able to demonstrate, using its own records and evidence. Certification under Article 42 is voluntary, is issued by accredited certification bodies or supervisory authorities for at most three years, and does not reduce the controller's or processor's responsibility. Some customers or contracts may ask for a specific certificate, so confirm that requirement with them in writing before buying an assessment.

What should we ask for in a written scope?

A written scope should name the systems and data flows covered, the processing purposes in each system, and the people responsible for each decision. Ask for a list of deliverables, such as a purpose register, a schema review with field-level findings, documented retention rules, tested deletion and log retention settings, and an accuracy workflow. Also ask which items the partner prepares and which remain with your team, what testing evidence will be produced, how changes after the start date are handled, and what is one-time versus recurring support. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so ask any provider for the same level of detail.

How DeployOpen scopes and prepares Article 5 evidence

DeployOpen prepares the self-hosted systems, configuration and records that let your organization show how it applies the Article 5 principles to personal data. The controller owns the decisions, and an independent assessor or supervisory authority judges compliance, while DeployOpen plans, builds and documents the technical side inside your own infrastructure.

How we scope

Engagements are fixed-scope, with the systems, processing purposes and principles covered agreed in writing before work starts.
Scope names each application holding personal data, the purposes you have recorded, and the schemas, logs and backups in use.
Ask for the written scope to list which Article 5(1) principles are in and out, and who owns each decision.

How we build

Configure data schemas so only fields needed for each recorded purpose are collected, with defaults set to the narrowest option.
Set log and export settings so personal data is minimized, and record where retention rules must be enforced in each system.
Document each design choice against the principle it serves, drawing on the design and default elements in EDPB Guidelines 4/2019.

How we hand over

Deliver configuration records, data flow descriptions and an evidence index mapped to each Article 5 principle.
Provide change history for configuration and documentation so your team can show when and why a setting changed.
Confirm with your assessor or data protection officer which evidence they need before handover, since they decide what is sufficient.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so evidence stays current as systems change.
Retainers can cover review of new processing purposes against the purpose limitation and minimization requirements.
Ask whether your retainer includes periodic reviews of retention jobs, accuracy workflows and access controls.