authentik for GDPR security of processing: what it helps with and what it does not
If you are a controller or processor responsible for systems holding personal data, Article 32 asks you to implement security appropriate to the risk, and Article 25 asks you to build data protection into those systems by default. authentik can support part of that work: it provides access control, multi-factor authentication and event logging for the applications you place behind it. It does not make your organization compliant, and the GDPR requires no certificate or attestation from any vendor. Compliance rests on the measures you choose, how you run them, and whether you can show they remain effective over time.
The useful split is between what the platform does and what your organization must still decide. authentik can enforce MFA for a group of users on a given application, restrict which users can reach an application through its policies, and record authentication events that you can review. Your organization still owns the risk assessment, the choice of which systems count as personal data systems, the access review process, the joiner and leaver procedures, and the records of processing that describe the Article 32(1) measures. The EDPB's Guidelines 4/2019 stress that the duty applies regardless of organization size and to systems that existed before the GDPR, and that measures need regular review of their effectiveness. A configured authentik instance is an input to that review, not a substitute for it.
Before you write this up for an assessor, confirm the scope against your own records. List each personal data system, state which authentik provider or application protects it, and note which controls are enforced in authentik and which depend on procedures outside it. The GDPR text cited on this page comes from the GDPR on EUR-Lex, and the articles discussed here are the starting point for that scoping exercise.
Mapping GDPR Articles 25 and 32 to authentik capabilities and configuration
This table maps each GDPR obligation in scope to the authentik capability that supports it, the configuration it needs and the record an assessor would expect to see. Read each row as a starting point for your own design: authentik supports these controls, but your processing, risk assessment and application list determine what must be enforced. Confirm MFA enforcement settings against your authentik version before relying on them.
| Obligation | authentik capability and configuration | Evidence to keep |
|---|---|---|
| Article 32(1) security appropriate to risk | Use OIDC, SAML or LDAP providers for each application handling personal data, so sign-in runs through one controlled identity provider with policies applied per application | Application-to-provider inventory, with the protocol and the bound authorization flow for each system |
| Article 32(2) risk of unauthorised access | Bind policies to applications and groups so only users with a documented business need can reach personal data systems; review denied attempts in event logs | Group membership lists, policy bindings export, and sampled denied-access events |
| Article 32(1) strong authentication | Enforce MFA through authentication flow stages for sensitive applications; confirm the exact MFA enforcement settings and available factors in your authentik version before rollout | Flow configuration export and test records showing a password-only login is refused for protected applications |
| Article 25(1) data protection by design | Scope each provider to the minimum set of attributes and scopes the application needs, so identity data passed to applications is limited to what each purpose requires | Attribute and scope mapping per provider, approved by the data owner before go-live |
| Article 25(2) access limited to what is necessary by default | Default new accounts to no application access and grant access through explicit group assignment; use enrollment flows that do not assign privileged groups automatically | Default group settings, enrollment flow configuration and the approval record for each group grant |
| Article 25(2) storage period and accessibility | Review how long event and audit data is kept in your deployment, since authentik stores its data in PostgreSQL; set retention in line with your records schedule and confirm the available settings for your version | Retention settings, database backup and purge schedule, and the written retention rule |
| Article 30(1)(g) records of processing | Record the Article 32(1) measures in your records of processing for each system, naming authentik as the identity control, the protocol used and the MFA and policy controls applied | Records of processing entries that describe the authentik-enforced measures for each system |
Evidence authentik can leave for a data protection assessment
A supervisory authority or auditor reviewing Article 32 measures will want to see how access was configured, who held it, and how it was watched over time. The cards below list the artifacts that answer those questions and the version records that tie them to a supported release.
Access configuration exports
Export the provider, application, flow and policy configuration as it stood on a given date, so an assessor can see which login requirements applied to each system holding personal data. Store exports alongside the authentik version that produced them, because settings and defaults change between releases. Confirm the export method for your deployment with DeployOpen or your authentik release notes before you rely on it as a record.
Group and application assignments
Records of which users and groups can reach each application that processes personal data show least privilege in practice. Keep dated snapshots of these assignments, since an assessor sampling access will ask who had access at a specific point, not only who has it today. Pair each snapshot with the approval or review that produced it.
Authentication and admin event logs
Login successes and failures, MFA challenges and administrative changes give evidence that controls operated. Forward these events to a log store you control and confirm which fields, such as user, source address and outcome, your logs keep. Audit logging beyond the basic set is listed on the pricing page as an Enterprise feature, so confirm your edition before you design the evidence trail.
Retention settings for events
Event and log retention decides how far back an assessor can look at access to personal data. Document the retention period you configure in authentik and in the external log store, and state who approves changes. Align the figure with your records of processing and with the storage period that Article 25(2) asks you to limit to what is necessary.
Records of processing entries
Article 30 expects a general description of the Article 32(1) measures in the records of processing. Describe authentik's role, the protocols and MFA requirements it enforces, and where it runs, so the entry matches the configuration exports. Review the entry whenever a release changes how a control works.
Version and support records
Keep a dated record of the authentik version in each environment and the upgrade history. Security fixes are applied only to the versions the security policy lists as supported, so an assessor may ask whether a deployment was on a supported line at the time of an event. Check the security policy and the releases page regularly and file each upgrade with its change notes.
Why self-hosting in the EU changes the transfer analysis
Self-hosting moves the transfer question to where you place authentik, not to the software itself. authentik runs in infrastructure you control, so the identity store (PostgreSQL holds all configuration and data except uploaded files) and the server and worker containers sit wherever your cloud accounts, data centers or private networks are located. That placement decides the first transfer question, but it does not settle it. EDPB Guidelines 05/2021 state that storage in a cloud outside the EEA is a transfer, and that remote access from a third country is a transfer even when the person only views data on a screen for support or administration. An administrator in another country who logs into the authentik console or troubleshoots a login from abroad therefore needs to be in the scope of your transfer analysis, alongside the hosting location.
The third-country exposure of any cloud or hosting provider also needs its own assessment. EDPB Recommendations 01/2020 say that where a provider needs access to data in the clear and the destination's public authority powers go beyond what is necessary and proportionate, no effective technical supplementary measure can be envisioned. Using an EU-based processor subject to third-country law with extraterritorial effect is not itself a transfer under Example 12 of the Guidelines 05/2021, but complying with a third-country authority request would be, so the exposure should be assessed before you engage the provider. The CJEU's Schrems II judgment of 16 July 2020 invalidated the Privacy Shield while leaving standard contractual clauses valid, which is why the assessment is per provider and per data flow. Confirm with your provider, in writing, where backups, logs and support access are held and who can reach them.
Do not treat the EU-US Data Privacy Framework as settled. Commission Implementing Decision (EU) 2023/1795 finds adequacy only for US organizations on the Data Privacy Framework List, and an appeal against the General Court's September 2025 judgment is pending as Case C-703/25 P. Record which providers rely on that decision, check whether they are on the list, and plan a fallback under standard contractual clauses or an EU-only hosting arrangement. The check is worth repeating at each review, because the outcome of the appeal could change the analysis for any US-linked provider in your authentik hosting chain.
Configuring authentik to support Article 32 and Article 25 controls
This sequence turns authentik into a documented access control layer for personal data systems, from the initial inventory through hosting, MFA, retention settings and recurring review. The output is a configuration that matches the measures your controller records can describe and that you can test.
Inventory personal data systems and their access needs
The controller's privacy or security lead lists each application that stores or processes personal data, the groups of people who need it, and the authentication each system can accept. Note which applications speak OIDC, SAML, LDAP or need a proxy outpost, because that determines how authentik can sit in front of them. The step is complete when every in-scope system has an owner, a data category, a list of user groups and a documented authentication method.
Decide the hosting location and data flows
Decide where the authentik server, worker and database will run and confirm that every copy of identity data stays where you intend. Authentik stores its configuration and data in PostgreSQL, so backups, logs and any hosting provider's access paths count as storage locations. Ask your cloud or data center provider to confirm where data is stored and who can access it, and check the transfer analysis in the GDPR topic guidance before choosing a third-party host. The output is a short data location statement that the record of processing can reference.
Deploy authentik with a separately managed PostgreSQL
Install authentik using the Docker Compose or Kubernetes guide, with the server and worker containers and PostgreSQL as the single data store. Authentik's documentation positions Compose for test setups and small-scale production, and the Helm chart's bundled PostgreSQL for demonstration and testing, so production should use a database you manage with its own backup and access controls. Authentik 2025.10 moved caching, tasks and sessions into PostgreSQL, so size connection limits accordingly. The step is complete when the instance runs on a supported release and a restore test of the database has succeeded.
Enforce MFA and group-based access per application
Create groups that mirror the roles in your inventory, bind each personal data application to a provider and an authorization policy, and require MFA for those bindings through an authentication flow. Give administrators separate accounts and restrict application access to the groups that need it, so access is granted by purpose rather than by default. Test each application with a user who should be denied, and record the result. The output is a policy export and a test log showing that unauthorized and unauthenticated access fails for every in-scope system.
Set session and event retention to match the storage period
Configure session lifetimes and inactivity timeouts for each application's risk level, and set event and audit log retention so it does not exceed the period you have justified for each purpose. Article 25(2) ties the storage period to what is necessary for each purpose, so authentik's audit records are personal data and need their own retention rule. Confirm which events the enterprise audit logging feature covers in your edition, and forward logs to a store with a deletion schedule. The step is complete when the retention values are written down, applied and verified by checking that older events are removed on schedule.
Document measures in the record of processing
Write a general description of the authentication, authorization, MFA, hosting and retention measures and attach it to the records of processing for each affected activity, as Article 30 expects where possible. Include the configuration references, such as provider names and policy names, so an assessor can match the description to the running system. Keep the document under version control alongside the authentik configuration. The output is an approved record entry for each personal data activity that cites the measures in place.
Schedule regular effectiveness reviews
Set a recurring review of group membership, application bindings, MFA coverage, retention settings and the authentik release in use. The EDPB's guidance says the measures must be reviewed regularly for effectiveness, and that duty applies to systems that predate the GDPR. Include a check of the supported release list in the authentik security policy and the security advisory schedule, since security releases are announced at least 24 hours in advance. The step is complete when the review interval, owner and evidence template are approved and the first review has been recorded.
What authentik does not cover for GDPR security of processing
Does authentik detect and report personal data breaches under Articles 33 and 34?
No. authentik produces authentication and audit events, but it does not decide whether an incident is a personal data breach, assess its risk to individuals, or notify the supervisory authority or data subjects. Those duties sit with the controller under Articles 33 and 34, and they depend on your incident response process, your legal team and your data inventory. Ownership is with the client. A partner can help design the detection rules, log forwarding to a SIEM and a runbook that links identity events to breach assessment, but the decision and the 72-hour notification clock remain with your organization. Confirm the notification timeline and roles with your data protection officer before you configure alerts.
Who is responsible for data minimisation inside the business applications?
The client owns it. authentik controls who can sign in and which claims an application receives, so it can limit the attributes passed to each application, but it cannot decide which personal data an application stores, how long it keeps records, or whether a screen shows more fields than a purpose requires. Article 25(2) applies to the application design itself. A partner can review claim mappings, scope requests and group-based access for each connected application, and flag over-sharing. Data retention rules in the applications themselves need owners in the business units.
Does authentik provide pseudonymisation for personal data stores?
Not as a general feature. authentik can use stable internal identifiers and avoid exposing usernames or email addresses in some tokens and logs, but pseudonymisation under Article 25(1) is a design decision about how each dataset links identities to records. That work covers key management, the mapping table, who can re-identify, and how pseudonyms are handled in exports and backups. Ownership is shared: the client sets the data model and legal basis, and a partner can implement and document the technical approach. Confirm exactly which identifiers appear in each token, log and API response in your version before relying on that design.
Who encrypts backups and storage for an authentik deployment?
The client owns encryption at rest and backup protection, with a partner usually implementing it. authentik stores its configuration and data in PostgreSQL, and uploaded files are held separately, so the database volumes, object storage, snapshots and backup copies all need encryption keys, access control and retention rules defined in your infrastructure. Key custody, rotation and restore testing are operational tasks. Confirm where the database and backups run, who holds the keys, and whether backup copies stay inside the EEA before you finalize the design.
Does security training for administrators fall to the client or a partner?
The client owns staff training. Administrators who create providers, change policies or handle lockouts need to understand least privilege, separation of admin accounts and how to recognize phishing attempts against identity flows. A partner can prepare role-specific runbooks, hands-on exercises and a walkthrough of the authentik admin interface, and DeployOpen offers security training as a separate service. Your HR and compliance teams still need to record attendance and refresh the content as roles change.
Who handles vendor contracts and transfer assessments for a self-hosted identity platform?
The controller does. Self-hosting in your own EU infrastructure keeps authentik data under your control, but it does not remove the need for due diligence on the cloud provider, hosting partner, managed database service or support vendor you use. Under Chapter V, remote access from a third country and storage outside the EEA can count as transfers, so the controller must check where support staff and hosts sit. Article 28 terms with processors, and any transfer impact assessment, are legal work for your counsel and procurement team. A partner can supply a data flow map and infrastructure details to support that review.
Which GDPR-related audit features require the enterprise license?
Enhanced audit logging and password history are listed as enterprise-only features on the authentik pricing page, along with mTLS client certificate authentication and privileged access management. The open source edition, which is licensed under MIT for most of the code, does not include them. The enterprise directory uses a separate license. If your evidence plan depends on these features, budget for the subscription and confirm current terms directly with authentik. Enterprise Plus, starting at $20k annually according to the pricing page, adds dedicated support and FIPS compliance. Ask a partner to map which features your processing records actually need before choosing an edition.
Who keeps the security measures under regular review after go-live?
The controller must review them, and a partner can run that review on contract. EDPB Guidelines 4/2019 say the obligation applies to all controllers regardless of size and requires regular review of the effectiveness of chosen measures. Your team must track authentik releases, apply security updates within the supported version windows listed in the security policy, and retest access controls after configuration changes. Ongoing support and continuous testing are available as DeployOpen retainers, but the review evidence and the decision about residual risk stay with your organization.
What recent enforcement shows about technical measures
Supervisory authorities judge technical measures by whether access to personal data was controlled and whether a failure exposed it. On 8 October 2026 the Swedish supervisory authority fined Miljödata i Karlskrona approximately EUR 160,000, and the EDPB's national news item describes the decision as concerning insufficient technical measures. On 9 September 2026 the CNIL fined Hôpital Privé de la Loire EUR 500,000 over a health data breach. The published summaries give the dates, amounts and general subject, but not the full reasoning. Before you draw conclusions about any specific failing, obtain and read the decision text in the original language.
Use the two cases as a prompt to check your own setup. Confirm that every account able to reach systems holding personal data maps to a named person or a documented service identity, that MFA is enforced for the applications and groups that hold such data, and that administrator access runs through separate accounts. Confirm that leavers lose access on a defined schedule and that idle or long-lived sessions are bounded. Then check logging: identify which authentication events, failed logins and administrative changes are recorded, how long they are kept, who can read or alter them, and whether anyone reviews them. EDPB Guidelines 4/2019 expect the chosen measures to be reviewed regularly for effectiveness, so record when each check was last performed.
These two cases do not establish requirements for any specific product. Article 32(1) asks for measures appropriate to the risk, taking account of the state of the art and implementation cost, and it does not name an identity platform. An identity provider such as authentik can support the access control, MFA and event logging you need, but the design must follow your own risk assessment and processing records. Article 83 sets the upper fine band for infringements of Articles 25 to 39 at EUR 10 million or 2% of worldwide annual turnover, whichever is higher, so the question for your organization is whether your controls match the risk to the people whose data you hold.
Questions buyers ask before hiring help with GDPR access controls
What drives the cost of an authentik implementation for GDPR access controls?
The cost is driven by scope, not by the software license. The main drivers are the number of applications that hold personal data and need SSO or MFA, the number and type of integrations (directories, HR systems, SaaS applications), whether authentik runs in your cloud account, a data center or an air-gapped network, and how deep the evidence trail must go for your DPO and assessors. Each of these adds design, configuration and testing work. DeployOpen does not publish a price list. Ask for a written scope that lists each application, integration and hosting target, the deliverables (configuration, runbooks, evidence procedures) and what the client team must provide, so quotes can be compared line by line.
Is authentik free to use for GDPR-related access control?
The core open-source edition is available under the MIT license (SPDX: MIT), and most of the repository falls under that license. Code in the authentik/enterprise/ directory is covered by a separate enterprise license defined in that directory, so read the terms before relying on enterprise features. According to the authentik pricing page, the Enterprise edition is listed at $5 per user per month billed annually, plus $0.02 per external user per month. Enterprise Plus starts at $20k annually. Enterprise-only features on that page include mTLS client certificate authentication, privileged access management, password history and enhanced audit logging, which may matter for Article 32 evidence. Confirm current pricing and terms directly with authentik before budgeting.
How long does a GDPR-focused authentik deployment take?
Duration depends on the same drivers as cost: the number of systems holding personal data, the number of identity sources to connect, how many applications need MFA by group, and whether the hosting environment already has PostgreSQL, storage, reverse proxy and backup services in place. Infrastructure approvals, change windows and the time your DPO and security team need to review the access model often set the pace more than the configuration itself. Plan the work in phases: a pilot on one application, then the remaining systems, then evidence and review. No duration is quoted here because none has been supplied for this scope. Ask for a timeline in the written scope that names the dependencies on your side.
What does the engagement need from our IT and DPO teams?
The IT team provides access to the target hosting environment, decisions on the directories and applications to connect, the reverse proxy and certificate arrangements, and approval for changes to production identity flows. The DPO and privacy team provides the register of processing activities, the list of systems holding personal data, the data categories and purposes, and the decisions on minimum data attributes, log content and retention periods for authentication events. Application owners confirm who should have access to each system and which roles map to which groups. Without these inputs, access rules and retention settings cannot be justified in the records of processing, so agree the responsibilities and sign-off points in the scope document before work starts.
Can our internal team implement authentik for GDPR access control without outside help?
Yes, an internal team can deploy and configure authentik if it has the skills in identity protocols (OAuth2/OIDC, SAML, LDAP), PostgreSQL operations, container or Kubernetes operations and security review. The Docker Compose guide positions Compose for test setups and small-scale production, while the Kubernetes guide recommends a separately managed PostgreSQL for production, so an internal team should plan that operating model from the start. The harder parts are usually the access model, the records of processing, the retention settings and keeping evidence current after the first rollout. Ask whether your team has capacity for upgrades, which follow the project's supported versions and advance security notice, and for ongoing reviews of the effectiveness of your measures.
Does DeployOpen or authentik issue a GDPR certificate for our deployment?
No. The GDPR does not require an audit, attestation or certificate, and neither DeployOpen nor authentik issues one for this work. DeployOpen plans, implements, hardens, documents and supports self-hosted platforms and prepares systems, controls and evidence for compliance assessments. Certification under Article 42 is voluntary and is issued by accredited certification bodies or supervisory authorities, and it does not reduce the controller's or processor's responsibility. Your records of processing and the Article 32 measures remain your responsibility, and the assessments you rely on come from your own review or from independent parties you choose.
What should we ask a provider about evidence and retention before signing?
Ask how the provider will document the access model, the MFA policy per application, and the event logging configuration, and who will own each record. Confirm which authentication and admin events are retained, where they are stored, and how long, since Article 25(2) ties storage period and accessibility to what is necessary for each purpose. Ask whether the hosting plan keeps personal data inside the EU or EEA, and how transfers to third countries, including remote administrative access, will be assessed under Chapter V. Finally, ask how the provider will support the regular review of effectiveness that the EDPB guidelines expect, and whether that review is included in the fixed scope or sold as a retainer.
What goes wrong most often in GDPR-focused identity projects?
The most common problems are unclear scope, where the list of systems holding personal data is incomplete, and access rules copied from directories without review. Teams also underestimate the effect of upgrades on running systems, since the 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading, and the project requires a sequential upgrade path. Other frequent gaps include leaving bundled demonstration databases in production, failing to forward authentication logs to the systems that retain them, and setting retention periods without a documented purpose. Agree on these checks in the scope, and test them during the pilot rather than after go-live.
Keeping authentik supported while the processing continues
A GDPR security control only stays effective if the software behind it keeps receiving fixes. The authentik security policy lists 2026.5.x and 2026.8.x as the release lines receiving security fixes, and the project announces security releases at least 24 hours in advance. The latest release shown on the project's GitHub releases page is 2026.8.4, published on October 14, 2026. Before go-live, confirm which line your deployment will track, record it in the processing documentation, and decide who is responsible for applying security releases inside that 24-hour window, including weekends and holidays.
EDPB Guidelines 4/2019 state that the obligation applies to all controllers regardless of size and requires regular review of whether the chosen measures remain effective. For authentik, that review should be a scheduled task with a named owner, not an ad hoc response. Each review should check the running version against the supported lines, note any upgrade that is pending, and confirm that the authentication controls described elsewhere on this page still behave as the records of processing say they do. Treat a version that falls off the supported list as a finding that needs a dated plan, because it weakens the Article 32 argument for that system.
Upgrades also affect infrastructure planning. The authentik 2025.10 release notes state that authentik no longer uses Redis, moving caching, tasks, sessions and WebSocket functions to PostgreSQL, and warn of roughly 50% more PostgreSQL connections after upgrading. If your deployment was sized around a Redis-based design, confirm the PostgreSQL connection limits, pooling approach and server capacity before any upgrade that crosses that release, and rehearse the upgrade in a non-production environment. Record the outcome of each rehearsal, since it becomes evidence that your security measures were kept current.
How DeployOpen scopes and delivers GDPR access control work on authentik
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For authentik used as an access control layer for personal data systems, we start from the processing inventory and the access model, then build and evidence the controls that your controller obligations under Article 32 and Article 25 depend on.
How we scope
- We list the systems holding personal data and the applications that must sit behind authentik for access and MFA.
- The written scope names the providers, groups, MFA rules, session settings and event retention periods to be configured.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build work starts.
- We confirm which authentik edition and enterprise features your required controls depend on before quoting.
How we build
- We deploy authentik in infrastructure you control, with PostgreSQL, storage, backups and reverse proxy configured for your EU hosting requirements.
- We configure OAuth2/OIDC, SAML or LDAP providers per application, with group-based authorization and least-privilege role mapping.
- We set MFA enforcement, session timeouts and deletion or retention settings for events, then test each access path against the written scope.
How we hand over
- You receive configuration documentation, the access matrix, and a record of the measures for your Article 30 processing records.
- We document the test results, including denied-access cases, MFA prompts and log entries that show the controls operate.
- Your team is trained to run the authentik administration, approve access changes and review the controls on a schedule.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so the controls keep pace with authentik releases.
- We help you review the effectiveness of measures periodically, as EDPB Guidelines 4/2019 expect controllers to do.
- DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and supervisory authorities make the final determinations.
