GDPR Article 25 requires that data protection be built into system architecture by design and that data minimisation be the default configuration. These are architectural requirements, not operational ones. They apply at the point systems are designed and deployed, not only when data is being processed. An organisation that deploys a system with broad default access to personal data and then attempts to restrict it through policy is operating in the opposite direction to what Article 25 requires.
Article 25 has two distinct obligations. Article 25(1) requires data protection by design: technical and organisational measures designed to implement data protection principles effectively must be integrated into processing activities from the outset. Article 25(2) requires data protection by default: by default, only personal data necessary for each specific purpose should be processed, and access to personal data should be restricted by default without requiring individual Data Subjects to take action to limit it.
For IAM specifically, Article 25 means that access to personal data systems must be restricted by default. Expansion of access scope requires explicit authorisation. The access control architecture must implement the data minimisation principle at the identity and access layer, not rely on users exercising restraint. A system where every user has read access to all customer records by default, with restrictions applied only for specific roles, inverts the Article 25(2) requirement.
This blog covers what Article 25(1) and 25(2) each require technically, how they apply to IAM architecture, and which controls satisfy each obligation. All article references are drawn from the GDPR and Akku’s GDPR compliance mapping documentation.
Article 25(1) requires that controllers implement appropriate technical and organisational measures designed to implement data protection principles effectively and to integrate the necessary safeguards into the processing. The data protection principles in Article 5 are the reference point: lawfulness, fairness, and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality.
The integrity and confidentiality principle under Article 5(1)(f) is the most directly relevant to IAM architecture. It requires that personal data be processed in a manner that ensures appropriate security, including protection against unauthorised or unlawful processing and against accidental loss, destruction, or damage, using appropriate technical or organisational measures.
Implementing integrity and confidentiality by design means that access controls, authentication requirements, and audit trail generation are built into the system architecture from the point of deployment, not added as security layers after the fact. A system deployed without MFA, with the intention to add it later, is not designed with integrity and confidentiality in mind.
Article 5(1)(b)’s purpose limitation principle requires that personal data collected for specified purposes not be processed incompatibly with those purposes. By design, this means that the access control architecture limits which users can process personal data for which purposes, enforced technically rather than relying on users to self-limit.
Article 5(1)(e)’s storage limitation principle requires that personal data not be kept longer than necessary. By design, this means automated lifecycle management workflows that trigger data deletion or access cessation when processing purposes are fulfilled, rather than manual cleanup processes.
The access governance infrastructure implements Article 25(1)’s by-design requirement across multiple controls. RBAC defines access entitlements at the role level, ensuring that access to personal data systems is scoped to the processing purposes each role requires, by design, from the point of user provisioning. The IGA SoD rules engine prevents conflicting access combinations that would enable a single user to process personal data across incompatible purposes, implementing the purpose limitation principle architecturally.
Adaptive MFA implements the integrity and confidentiality principle by design at the authentication layer. Every access to personal data systems requires authentication assurance proportionate to the sensitivity of the data, enforced through the identity layer rather than relying on application-level controls.
Automated deprovisioning implements the storage limitation principle at the access layer. When a user’s employment ends or a processing purpose is fulfilled, access to personal data systems is revoked automatically without requiring a manual deprovisioning action. The automated workflow is the by-design implementation of the storage limitation principle for access rights.
Akku’s GDPR mapping shows Identity and Access Governance addresses Articles 24(1), 25(2), and 32(1)(d). Access Manager addresses Articles 5(1)(f), 24(1), 25(2), 29, and 32(1)(b) across five mapping points.
Article 25(2) requires that, by default, only personal data necessary for each specific purpose is processed. Access to personal data should be restricted by default. Data Subjects should not have to take action to protect their privacy. The default configuration of systems must implement data minimisation without requiring user intervention.
Article 25(2) applied to IAM architecture means that the default access state for any new user is no access to personal data systems. Access is granted explicitly, based on a documented processing purpose tied to the user’s role, through a formal authorisation process. The default is restriction, not access.
This is the opposite of many legacy system architectures where broad read access to customer or employee data is the default, with restrictions applied only for specific sensitive functions. Article 25(2) requires inversion of this default: restriction is the baseline, and access must be actively granted based on demonstrated need and authorised processing purpose.
The data minimisation requirement also applies to the scope of access within systems. A user whose role requires viewing customer contact details to process a service request should not by default have access to payment card data, health information, or other personal data categories held in the same system but irrelevant to their function.
Akku’s default access model implements Article 25(2) architecturally. No user is granted access to personal data systems without explicit role assignment and provisioning through a structured workflow. Birthright access is defined at the role level, scoped to the processing purposes that role legitimately requires, and does not include access to personal data systems beyond what the role requires.
ABAC refines access scope within systems, limiting what data categories a user can access based on attributes beyond role, including their current active processing context. Contextual access controls add a further restriction layer, limiting access to authorised devices, networks, and time windows even for users with legitimate role-based entitlements.
The IGA who-has-access-to-what view provides administrators with continuous visibility into whether the data minimisation default is being maintained across all users and systems. Access that has accumulated beyond current processing requirements is surfaced through access reviews for revocation.
Akku’s GDPR mapping shows Cloud Directory addresses Article 25(2). The broader access control module stack, covering Access Manager, Adaptive MFA, Identity and Access Governance, and Privileged Access Manager, implements data minimisation by default across the full access lifecycle.
Article 25’s by-design requirement has specific implications for privileged access to systems that process personal data. Database administrators with direct query access to tables holding personal data, system administrators with file system access to personal data stores, and infrastructure administrators with access to the network segments where personal data systems reside are all processing personal data under Article 25’s scope.
By design, privileged access to personal data systems must be governed through the same data minimisation and purpose limitation principles as standard user access. A DBA should not have standing, unrestricted access to production customer databases by default. The by-design requirement means that the architecture prevents standing privileged access rather than relying on the DBA to exercise restraint.
Article 25(1)’s integrity and confidentiality requirement for privileged access means that every privileged session to a personal data system is authenticated with appropriate assurance, brokered through a session proxy that records activity, and governed through a formal approval workflow that documents the processing purpose for each session.
JIT access implements Article 25’s by-design requirement for privileged access. No DBA, system administrator, or infrastructure administrator holds standing access to personal data systems. Access is granted for the duration of an approved, time-bound session with a documented processing justification. The architecture prevents standing privilege by design rather than relying on policy adherence.
AkkuArka generates per-session ephemeral credentials for every privileged session. The credential is generated at session approval, scoped to the access level required for the session’s processing purpose, and permanently revoked on session close. This implements the data minimisation principle at the credential layer: each privileged session has access only to what the approved purpose requires, not to everything the privileged account could potentially access.
SMARTAudit Trails record every privileged session to personal data systems at the protocol layer. This produces the audit evidence that Article 25(1)’s by-design integrity requirement implies: a demonstrable record that privileged access to personal data was governed, controlled, and logged throughout its duration.
Privileged Access Manager addresses Articles 5(1)(f), 29, and 32(1)(d) in Akku’s GDPR mapping.
Article 25 compliance is assessed through the accountability principle in Article 24 and Article 5(2): the controller must be able to demonstrate that processing is performed in accordance with the GDPR. For Article 25 specifically, this means demonstrating that data protection was built into the architecture by design and that data minimisation is the operational default.
Demonstrating by-design compliance requires architectural documentation showing that access controls, MFA, and audit trail generation were designed into the system from the point of deployment, not added retrospectively. It also requires operational evidence showing that the by-design controls are actually functioning: that no user accesses personal data systems without explicit authorisation, that privileged access to personal data systems is governed through JIT workflows, and that access minimisation is enforced through ongoing access reviews.
Demonstrating by-default compliance requires evidence that the default access state for new users is restriction, not access. Provisioning records showing that every user starts with no access to personal data systems and receives access only through a documented authorisation process constitute this evidence.
The provisioning audit trail, covering every access grant with requester, approver, justification, and timestamp, is the evidence that by-default access minimisation is operationally maintained. The access review records, showing periodic certification or revocation of access to personal data systems, demonstrate that the by-default minimisation posture is continuously maintained rather than set once and left to drift.
The JIT access workflow records for privileged sessions, covering every session request, approval, scope definition, and credential lifecycle event, demonstrate that by-design privileged access governance is operating for every session to personal data systems.
Akku’s append-only audit log architecture ensures these records are tamper-evident, making them suitable for submission to a supervisory authority examination of Article 25 compliance.
Does the default access state for a new user at your organisation include any access to personal data systems, or is the default no access with explicit authorisation required for every grant?
Can you demonstrate to a supervisory authority that access to personal data systems was built into your architecture as a restricted-by-default model from the point of system deployment, rather than added as a security layer after deployment?
Do database administrators and system administrators with access to personal data systems hold standing credentials that allow them to connect at any time, or is privileged access to personal data systems governed through JIT workflows with documented processing justifications?
Are access reviews for personal data systems run on a defined cadence throughout the year, with documented evidence that access accumulated beyond current processing requirements is revoked, or does review occur only before audit events?
Can you produce, for any user currently holding access to a personal data system, the authorisation record showing which processing purpose justified the access grant and who approved it?
See how Akku addresses GDPR Article 25 data protection by design requirements across access controls, privileged access governance, and audit trail generation.
Book a conversation with the Akku team to assess your current IAM architecture against GDPR Article 25’s by-design and by-default obligations.
What is the difference between Article 25(1) data protection by design and Article 25(2) data protection by default?
Article 25(1) requires that technical and organisational measures implementing data protection principles be integrated into processing activities from the outset. It is about how systems are designed and built. Article 25(2) requires that, by default, only necessary data is processed and access is restricted without requiring Data Subject action. It is about the default operational state of systems once deployed. By design means the architecture implements protection from the start. By default means the starting configuration minimises data access without user or administrator intervention to restrict it.
How does the data minimisation principle under Article 5(1)(c) apply to IAM architecture?
Article 5(1)(c) requires that only personal data adequate, relevant, and limited to what is necessary for the processing purpose is collected and processed. Applied to IAM architecture, data minimisation means that each user’s access is scoped to the personal data their role requires for its authorised processing purposes, and no more. A customer service representative whose role requires access to contact details should not by default have access to payment card data or health information held in the same system. RBAC and ABAC implement data minimisation at the access layer by scoping entitlements to what each role’s processing purposes actually require.
What does Article 25 require for third-party and contractor access to personal data systems?
Article 29 requires that processors and persons acting under the authority of the controller process data only on instructions from the controller. Applied to third-party and contractor access, this means their access to personal data systems must be governed through the same by-design and by-default controls as internal user access. Contractors should not have standing access to personal data systems. Their access should be time-bound, scoped to the specific processing they are authorised to perform, and governed through the same JIT access workflows and session recording controls that apply to internal privileged users.
Does Article 25 apply to legacy systems that were deployed before GDPR came into force?
Yes. Article 25 does not exempt legacy systems from the by-design and by-default requirements. Controllers are expected to have reviewed and, where necessary, updated their systems to implement appropriate technical measures since GDPR came into force in May 2018. A legacy system that was deployed with broad default access and has not been updated to implement access controls appropriate to Article 25 is not compliant. The practical approach is to extend the IAM access control and governance layer to legacy systems, bringing them within the centralised authentication and access governance infrastructure even if the systems themselves cannot be modified.
How does Article 25 interact with Article 32’s security of processing requirements?
Article 25 covers the design and default configuration of systems. Article 32 covers the ongoing security measures applied to processing operations. Article 25 is satisfied by building access controls, MFA, and audit trail generation into the architecture from the outset. Article 32 is satisfied by the operational security controls including encryption, authentication assurance, and incident response capability that protect personal data during processing. Both apply simultaneously. An organisation can satisfy Article 32’s operational security requirements while still failing Article 25 if the default access configuration grants broader access than necessary before the Article 32 controls restrict it.
What evidence does a supervisory authority examination of Article 25 typically look for?
A supervisory authority examining Article 25 compliance typically looks for architectural documentation showing that data protection was considered at system design, access control configuration records showing that the default access state implements data minimisation, provisioning records demonstrating that every access grant to personal data systems required explicit authorisation, access review records showing that access minimisation is continuously maintained, and privileged access governance records demonstrating that administrative access to personal data systems is controlled and logged. The accountability principle requires that the controller can produce this evidence, not merely assert compliance.
Introduction ISO 27001:2022 Annex A.8.15 requires that logs recording user activities, exceptions, faults, and security events be produced, kept, and…
Introduction Every compliance audit, regardless of framework, arrives at the same point: the auditor requests evidence that specific controls operated…
Introduction SOC 2 CC6 is the Logical and Physical Access Controls criterion cluster and is where the majority of IAM-relevant…
Introduction RBI 2023 Master Direction Clause 19 is the most technically detailed access control provision in the framework. It establishes…
Introduction SEBI CSCRF's Protect function contains the Access Authentication sub-category PR.AA, which runs from PR.AA.S1 through PR.AA.S17 and represents the…
Introduction DPDPA Clause 6 sets specific conditions for consent as a lawful basis for processing personal data. Consent must be…