Open source customer identity for GDPR: what Articles 25, 7 and 32 ask of your login platform
The GDPR does not prescribe a product for customer login, but it does require data protection by design and by default, consent you can demonstrate, withdrawal that is as easy as giving consent, and security appropriate to the risk. For an EU controller whose login stores account data, credentials and consent records, the identity platform is where those obligations are tested first. The regulation requires no audit report or certificate. Certification under Article 42 is voluntary and does not reduce the controller's responsibility. DeployOpen prepares the configuration, controls and evidence that a controller or its assessor will ask for, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work.
Article 25(1) asks for technical and organisational measures, such as pseudonymisation, that implement principles like data minimisation both when designing the means of processing and during processing. Article 25(2) asks that, by default, only the personal data needed for each purpose is collected, stored and made accessible. In a self-hosted Keycloak, ZITADEL or Ory deployment, that means deciding which profile attributes registration forms collect, which are optional, how long inactive or unverified accounts are kept, and which administrator roles can read user records. Article 7(1) requires the controller to show that a data subject consented, so the consent record, its version and its timestamp should be stored and retrievable. Article 7(3) requires that withdrawal be possible at any time and be as easy as giving consent, and that the customer is told this before consenting. Test withdrawal from the customer's side of the login flow, not only in the admin console.
Article 32 asks for security appropriate to the risk, with specific attention to unauthorised access and loss or alteration of personal data. For customer accounts this usually covers password storage, multi-factor or passkey options, brute-force protection, session handling, encryption in transit and at rest, and access logging for administrators. Ask your implementation partner to document each control against the risk assessment, and confirm with your data protection officer which breach scenarios, such as credential stuffing or an exposed admin role, the assessment covers. Also confirm the processing location and any transfer of data outside the EEA with your counsel, because Chapter V of the regulation governs those transfers.
Which GDPR requirements a customer identity platform must meet, and how to configure them
This table maps the GDPR provisions that bear on customer login, registration and consent to the identity platform functions that meet them, and the configuration step for each. Read each row as a question to put to your team or implementation partner: what the regulation asks for, what to configure, and what evidence you should be able to show. The main takeaway is that most of the work sits in data minimization at registration, consent records that can be withdrawn as easily as given, and access and monitoring controls on customer accounts.
| Requirement | What to configure | Evidence to keep |
|---|---|---|
| Data protection by design (Article 25(1)) | Decide which profile attributes the login flow collects, use pseudonymous internal user IDs in tokens and logs, and keep optional fields out of the registration form. | Data inventory of identity attributes, design decision records and a review of each new attribute before release. |
| Data minimization by default (Article 25(2)) | Limit default registration to the attributes each application needs, restrict user attributes exposed in tokens to named claims, and set client scopes so applications receive only what they use. | Client scope and mapper configuration exports, token samples and sign-off from the data owner. |
| Storage period and accessibility limits (Article 25(2)) | Set retention rules for inactive and deleted accounts, restrict admin console roles by realm or organization, and limit who can query or export user records. | Retention schedule, role assignment reports and periodic access reviews of administrator accounts. |
| Consent that can be demonstrated (Article 7(1) and Article 4(11)) | Record consent as a separate, versioned object with the purpose text shown, timestamp, consent version and the identifier of the account. Use unticked, affirmative checkboxes and separate consents per purpose. | Consent records with version history, copies of the wording shown at each version and test cases for the consent screen. |
| Withdrawal as easy as giving consent (Article 7(3)) | Provide a self-service withdrawal action in the account page that takes effect in one step, and make the connected application stop relying on the withdrawn purpose. Tell users about this before they consent. | Test results showing withdrawal in the same number of steps as consent, logs of withdrawal events and proof that downstream applications read the updated consent state. |
| Security of customer accounts (Article 32(1)) | Enforce passkeys or MFA for sensitive actions, use password fallback only where risk allows, enable brute-force protection and lock-out policies, and require TLS for all login endpoints. | Authentication policy export, configuration baselines and results of login abuse testing. |
| Encryption of identity data (Article 32(1)) | Encrypt database connections and storage, protect the signing keys for tokens, and store client secrets and database credentials in a secrets manager rather than in configuration files. | Encryption settings for the database and volumes, key rotation records and secret store access logs. |
| Logging and monitoring for breach relevance (Article 32(2)) | Enable authentication and admin event logging, forward events to your SIEM, and set alerts for credential stuffing, mass account changes, new admin grants and export activity. | Log retention settings, alert rules, sample alerts with triage notes and the timeline used to assess breach notification duties under Articles 33 and 34. |
How a self-hosted login flow keeps consent provable and withdrawable
Where processing relies on consent, the controller must be able to demonstrate that the data subject consented (Article 7(1) of the GDPR), so the login flow has to produce a consent record as a by-product of registration, not as an afterthought. On a self-hosted CIAM platform such as Keycloak, ZITADEL or Ory, the sequence to design is: the user reaches the registration page, sees the consent text and the purposes it covers, takes a clear affirmative action such as an unticked checkbox they set themselves, and the platform then writes a timestamped record linking the user identifier, the consent text version, the purpose and the method of capture. Token issuance should follow from that point, and the access token or session should only carry the scopes the recorded consent allows. The record, not the login success, is the evidence a supervisory authority will ask to see.
Withdrawal has to be as easy as giving consent, and the user must be told so before consent is given (Article 7(3)). In practice this means a self-service preference page inside the account area, where withdrawing a purpose is one action of similar effort to granting it, and the withdrawal updates the consent record and invalidates the scopes or downstream flags that depended on it. Confirm with your implementation partner how a withdrawal propagates to applications and APIs that cache tokens or user attributes, because a withdrawn purpose that still appears in a valid token is a gap an assessor will notice. Treat the consent history as append-only so that both the grant and the withdrawal remain provable.
The software does not decide whether consent is valid. The controller is responsible for the consent wording, the purposes listed, the lawful basis chosen for each processing activity and whether consent is the right basis at all. Legal and privacy teams should sign off the exact text and its version identifier before the platform is configured, and the implementation should store that identifier with each record. Ask your partner to show how a new consent text creates a new version, how existing users are re-prompted, and where the records are retained. The EDPB Guidelines 05/2020 on consent are the natural starting point for the legal review, and they describe the conditions a valid consent must meet.
Which open-source platforms fit GDPR-driven customer identity
GDPR does not name a product, but the platform you choose decides how consent records, account security and data location are handled. The three options below differ in licensing, tenant model and how their data is stored, so each card names the decision it forces. Compare them against your consent design, hosting constraints and the obligations your legal team has confirmed.
Keycloak for workforce-style and customer login
Keycloak is Apache-2.0 licensed and supports OpenID Connect, OAuth 2.0 and SAML 2.0, with identity brokering and user federation. Its realm model separates user populations, which helps when customer data from different brands or markets must be kept apart. Check whether consent and preference data will live in user attributes or in a separate store, and confirm how the Operator will be configured for updates. Keycloak 26.8.1 was published on October 13, 2026.
ZITADEL for multi-tenant isolation
ZITADEL organizes tenants as instances with full data isolation, plus organizations and projects inside them. That structure fits services where each customer or market needs its own data boundary and identity provider. Its core is licensed under AGPL-3.0, so if you modify it and offer it to users over a network, you must confirm your obligations to publish those changes with counsel. ZITADEL v4.19.5 was released on October 15, 2026.
Ory Kratos and Hydra as separate services
Ory splits identity management (Kratos) from the OAuth 2.0 and OpenID Connect server (Hydra), both under Apache-2.0. This separation lets you keep personal data in one service and token issuance in another, which can narrow who can reach stored profiles. The cost is more components to deploy, back up and monitor, and a login UI you build or integrate yourself. Both released v26.2.0 on March 20, 2026.
PostgreSQL as the system of record
Keycloak and ZITADEL both store identity data in PostgreSQL, with versions 14 through 18 supported for each. Deletion and export requests, retention limits and backups all operate on this database, so its location and encryption shape your GDPR evidence. Confirm that backups, read replicas and log exports follow the same deletion rules as production data. Ask your partner how restores interact with erasure requests.
Licensing and the modified-service obligation
Licenses decide whether you can change the platform and keep those changes private. Apache-2.0 (Keycloak and Ory) permits modification without publishing your changes, while AGPL-3.0 (ZITADEL core) requires source disclosure to users who interact with a modified version over a network. Pick a platform after your legal team confirms which obligations apply to your custom login pages, consent logic and plugins. Keep this review with your architecture records.
Upgrade cadence and migration
Keycloak plans four minor releases a year and states that breaking changes in minor releases are opt-in, while the Operator documentation recommends manual approval mode for updates. ZITADEL documents migration guides from Keycloak and other systems, including just-in-time migration. Consent records must survive every upgrade and migration with their timestamps and versions intact. Ask any partner to show how that is tested before a production cutover.
Common questions about GDPR and self-hosted customer identity
Does using open source customer identity remove our GDPR obligations?
No. The GDPR applies to the controller regardless of which software runs the login system. Choosing Keycloak, ZITADEL or Ory does not make you compliant. You still need a lawful basis for each processing purpose, records of processing, data subject rights handling, breach notification under Articles 33 and 34, and appropriate technical and organisational measures under Article 32. Open source gives you control over where data sits and how the platform is configured, which helps you meet those duties, but the duties remain yours. Your implementation partner can build and document the controls, and your legal and privacy team still decides what the processing is lawful and proportionate. Confirm with your data protection officer which obligations the platform configuration can evidence and which stay in process documents.
Do we need an Article 42 GDPR certification for our identity platform?
No. The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary and is issued by accredited certification bodies or supervisory authorities for at most three years. An approved certification may be used as one element to demonstrate compliance with Article 25(1) and (2), but it does not reduce the controller's or processor's responsibility. DeployOpen prepares systems, configuration baselines and evidence for assessments, but it does not issue audit reports or certifications. Ask your certification body or supervisory authority which mechanisms they recognize, and plan evidence collection (configuration exports, access logs, consent records and change history) so that any assessor can review it.
How is data minimization set by default during customer registration?
Article 25(2) requires that, by default, only the personal data necessary for each specific purpose is processed. In practice, the registration form and the identity schema should collect the minimum attributes needed to create and secure the account, with optional attributes requested later only when a feature needs them. Engineers set this through the user profile definition, required fields, disabled unused attributes and scoped client mappings so that tokens carry only the claims each application needs. Review storage periods and default accessibility for administrators and support staff as well. Test the default registration flow against a written data inventory, and document the reasoning for every attribute, because the default is what a regulator will examine first.
How should we handle erasure and export requests for customer accounts?
Erasure and access or portability requests need a documented procedure before go-live. The platform holds identity records, credentials, sessions, consent entries and audit logs, and each store needs its own rule for deletion or retention. Build an export that returns the profile, consent history and linked identities in a structured format, and an erasure job that removes or pseudonymizes personal data across the identity database, backups, downstream applications and logs, respecting any legal retention you must keep. Confirm with your privacy team how long audit logs are kept, and test that a deleted user cannot sign in or be re-created from a backup. Ask any implementation partner to show the runbook and a tested restore procedure.
What happens to consent records after a customer withdraws consent?
Under Article 7(3), withdrawal must be possible at any time and as easy as giving consent, and the controller must still be able to demonstrate the earlier consent under Article 7(1). That means withdrawal should update the current preference and stop the processing, while the record of the original consent, its version, timestamp and wording is kept as evidence for the period you need it. The design question is where those records live and who can change them. Store consent events append-only, link them to the text version shown to the user, and expose a withdrawal option in the account profile as prominently as the grant. Confirm with counsel how long withdrawal evidence must be retained.
Does the Digital Omnibus or Omnibus IV change our GDPR planning now?
Not yet. As of October 2026 the GDPR text has not been amended. The Omnibus IV proposal (COM(2025) 501, procedure 2025/0130(COD)) has a text agreed in interinstitutional negotiations on 26 June 2026 and is awaiting Parliament's first-reading vote. The Digital Omnibus proposal (COM(2025) 837, procedure 2025/0360(COD)) is awaiting committee decision. Plan against the current text and build controls that are easy to adjust, such as configurable consent versions, retention settings and documented data inventories. Track both procedures in the European Parliament Legislative Observatory and revisit the design when a text is adopted. Regulation (EU) 2025/2518 on cross-border enforcement procedures applies from 2 April 2027 and should be on the same review list.
Can our own team run GDPR-ready customer identity without a partner?
It depends on the skills and the scope. A team with identity engineering, security operations and privacy expertise can run a self-hosted platform, but GDPR readiness also needs written procedures, tested erasure and export jobs, backup handling and evidence collection. Most organizations choose a fixed-scope implementation with a partner for the initial build and hardening, then keep internal ownership of operations. Ask any partner to define the deliverables in writing before work starts, including configuration baselines, the data inventory, runbooks and the evidence pack. Cost depends on scope, the number of identity sources and integrations, and the ongoing support model, so request a quote from a written scope rather than comparing general estimates.
What appropriate security of customer accounts means under Article 32
Article 32 does not prescribe a fixed set of login controls. It requires a level of security appropriate to the risk, and for a customer identity platform the risks that matter most are account takeover, credential stuffing, and unauthorized access to personal data held in customer profiles. Article 32(2) asks the controller to weigh accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, and access to personal data. For customer accounts, the realistic path to those outcomes is usually a stolen or reused password, a session that outlives its purpose, or an administrator account with more reach than its job requires. Each of these maps to a control you can configure on a self-hosted Keycloak, ZITADEL or Ory deployment.
The controls to evaluate are concrete. Passkeys based on FIDO2 and WebAuthn remove the shared secret that credential stuffing depends on, and ZITADEL documents passkey login with password fallback, which you will need to decide how to retire. MFA for risky logins, brute-force detection and rate limiting on the login and recovery endpoints, and short session and token lifetimes with refresh controls limit what a compromised session can reach. Encryption in transit should be enforced on every hop between browsers, the identity server and the database, and encryption at rest should cover the database and any backups that hold credentials, tokens and profile data. Separate administrator realms or accounts, with their own MFA and audit logging, keep an attacker who reaches a customer account from also reaching the identity configuration. Confirm each of these settings against the version you deploy, because defaults and option names change between releases.
The level you choose has to be justified, not assumed. Write a documented risk assessment that names the account data at stake, the likely attack paths, the impact on individuals, and the controls selected for each risk, with the reasons for any control you decided not to apply. Review it when the threat picture or the product changes, and keep it with the configuration baseline so that a supervisory authority or auditor can trace each setting to a decision. Ask your implementation partner to deliver this assessment as part of the written scope, including which controls are in place at launch and which are planned, since that record is what shows the security measure was chosen deliberately.
How a GDPR-ready CIAM rollout is sequenced
The sequence turns a general wish to comply with GDPR into a configured, tested and documented customer identity platform, where each phase produces evidence the controller can rely on. Work typically starts with the data and the legal decisions, because those set what the software must do.
Inventory customer data and map lawful bases
The controller leads this step with DeployOpen supporting. The team lists every customer attribute the login and registration flows collect, where it is stored, which applications read it, and the lawful basis for each purpose. Consent is only one basis, so the team confirms which processing needs it. The step is done when the controller signs off a data inventory and a purpose register that the configuration work will follow. Ask the controller which records of processing and data protection impact assessment outputs already exist, so this step extends them rather than starting from scratch.
Configure privacy by default settings
DeployOpen configures the self-hosted platform, whether Keycloak, ZITADEL or Ory, so that registration asks only for the fields each purpose needs, optional attributes stay empty until the customer adds them, and profile data is visible only to the roles that need it. The team also sets retention for inactive accounts and restricts administrative views. Verification is a review of the realm or instance settings against the purpose register, with test accounts showing that no unnecessary field is collected or exposed by default. Write the settings into version-controlled configuration so the baseline can be reproduced.
Build consent capture and withdrawal
The team builds consent screens that state the purpose before the customer agrees, record each choice with a timestamp, the wording version shown and the channel used, and store that record where it can be exported. Withdrawal is built with the same weight as giving consent: a customer can withdraw from the account settings page in the same number of steps, and downstream applications receive the change. Testing covers giving, changing and withdrawing consent across each application. The step closes when a sample of records can show who agreed to what, under which text, and when it was withdrawn.
Harden account security and monitoring
DeployOpen hardens the deployment for the risk to customer accounts: TLS on every hop, encrypted database connections, brute force protection, passkeys or multi-factor options offered to customers, and secure administration access. Authentication and administrative events are sent to a logging or monitoring platform so that account takeover and unauthorized access attempts can be detected and investigated. The step is complete when hardening tests pass, alerts fire for simulated suspicious logins, and the team can show the logs that support a breach investigation.
Test privacy and security controls
Before go-live, the team tests the controls it has built against the inventory and the purpose register. Tests cover data minimization in each flow, consent withdrawal propagation, access by administrators and support staff, and export and erasure requests for a test customer. Findings are logged with an owner and a fix date. The step is done when the controller accepts the test results and the open findings are either closed or accepted in writing with a stated reason. Where the scope includes security testing, it can be run as a separate, fixed-scope engagement.
Collect compliance evidence
The team assembles the evidence that the controller and its assessors will ask for: configuration baselines, the data inventory, consent record samples, test reports, hardening results, backup and restore records, and access reviews for administrators. Evidence is stored with dates and the version of each configuration. DeployOpen prepares this material but does not issue audit reports or certifications. Confirm with your legal and audit teams which artifacts they need and in what format before this step starts.
Run a documented review cycle
After go-live, the controller and DeployOpen agree on a review cycle that covers changes to the purpose register, new applications, platform upgrades and security patches, and periodic checks of consent records and access rights. Each review produces a dated record of what changed and who approved it. The step is complete when the review cycle is written into the operating procedures and the first review has been run and recorded. Ask any implementation partner how the review cycle is supported after handover, whether through a retainer or by your own team.
Evidence that supervisory authorities and auditors ask for, and which component produces it
This table maps the records a supervisory authority or auditor typically asks for under GDPR to the platform component that produces each one, and what to confirm with the vendor. Read it as a checklist for the design phase: if a row has no clear producer in your architecture, the evidence will need to be built or sourced elsewhere before an assessment.
| Evidence | Producing component | What to confirm with the vendor or your team |
|---|---|---|
| Records of processing inputs (data categories, purposes, retention per attribute) | Platform user schema and data model, documented by the implementation team (not produced automatically) | Which user attributes are stored, which are optional, and whether retention periods can be set per attribute or per realm or instance |
| Consent records with timestamp, version and wording | Custom consent attributes or a consent service connected to the login flow; Keycloak and ZITADEL do not presume a consent ledger by default | Whether consent events, policy version identifiers and the exact text shown can be stored and queried, and how long they are retained |
| Consent withdrawal logs | Admin and user event logs plus application-side consent updates, depending on how withdrawal is built | That withdrawal produces a logged event that downstream systems can act on, and whether the event can be exported for a supervisory request |
| Configuration baselines exported from the platform | Keycloak realm export or Operator custom resources; ZITADEL configuration held in code, Helm values and Terraform | Export formats, whether secrets are excluded from exports, and how baselines are versioned and compared over time |
| Access reviews of administrators and integrated applications | Admin console role listings, exported through the admin API, with review records kept in the governance tool | Whether role and grant listings can be exported as evidence, and whether a separate identity governance platform is needed for periodic certification |
| Admin audit logs | Keycloak admin events and ZITADEL audit events, forwarded to a SIEM for retention | Event coverage for configuration changes, retention limits in the product, and whether logs are tamper-evident when forwarded |
| Encryption configuration (in transit and at rest) | TLS settings on ingress and the platform, database and backup encryption configured by the operator | Supported TLS versions, cipher configuration, and which layers (database, volumes, backups) you must encrypt yourself |
| Backup and restore records | Database backups for the PostgreSQL or other supported production database, plus tested restore runbooks | Backup frequency, restore test evidence, and whether user data in backups can be located for erasure requests |
| Breach detection records | SIEM correlation of authentication failures, credential stuffing patterns and account takeover signals, with alerts routed to a response process | Which authentication events the platform emits, and whether the SIEM rules and alert history are kept as evidence of detection |
| DPIA inputs (data flows, risks, safeguards) | Architecture diagrams and data flow records maintained by the project team, informed by platform documentation | Which third-party identity providers and brokers receive personal data, and where each is hosted |
What the identity platform alone does not satisfy
A self-hosted CIAM platform handles part of the GDPR picture: login, consent capture and account security. The accountability duties around it, from the lawful basis to breach notification and downstream retention, sit with the controller and processor whatever software they run.
Lawful basis and records of processing
The identity platform records consent, but the controller still has to decide the lawful basis for each processing purpose and document it. Records of processing under the regulation's accountability duties should list the identity store, its log retention and every downstream system that receives customer attributes. Check that the register matches what the platform actually stores, including event logs and backups, not only the fields shown in the admin console.
Data protection impact assessment
A DPIA is required where processing is likely to result in high risk, and customer login with profiling, social login or identity proofing often meets that threshold. The assessment has to be done by the controller for its own design choices, such as which identity providers are federated, where the database runs and who can administer the realm. Keep the DPIA current when login flows or federation partners change.
Processor contracts and international transfers
Any vendor that operates, supports or hosts the identity platform for you acts as a processor and needs a written contract covering instructions, security and subprocessors. Under Chapter V, transfers of customer data to third countries need a valid transfer mechanism, which matters when a federated provider, email service or SMS gateway sits outside the EEA. Ask each vendor where support staff access data from and which subprocessors they use.
Breach notification and incident response
Articles 33 and 34 set the clock and content for notifying the supervisory authority and affected individuals after a personal data breach. Platform logs can show a credential stuffing wave or an administrator change, but the controller must detect it, assess risk and decide on notification within its own process. Test that alerts from the identity platform reach a team able to act, and that the incident playbook covers authentication logs as evidence.
Retention in downstream systems
Erasure in the identity store does not remove copies held by CRM, analytics, data warehouses, support tickets, backups or partner systems that received the account through synchronization. Each downstream system needs its own retention rule and deletion path, and the controller must be able to show that deletion reached them. Confirm which systems receive identity events and how long each keeps them.
Staff training and fines exposure
Administrators, support agents and developers who touch the identity platform need training on data minimization, consent wording and handling of access requests. Article 83 sets administrative fines that apply to controllers and processors regardless of which software they chose. Recent enforcement, including a Swedish fine of approximately EUR 160,000 for insufficient technical measures and a CNIL fine of EUR 500,000 for a health data breach, shows that regulators look at security practice and organizational failings, not only at tools.
How GDPR obligations change for regulated customer data
Health, financial and public-sector customer data carry sector rules on top of the GDPR, so a CIAM design that satisfies Articles 25 and 32 can still fall short once a specific regime applies. In the United States, the HIPAA Security Rule at 45 CFR 164.312 requires unique user identification, audit controls that record and examine activity in systems holding ePHI, person or entity authentication and transmission security. The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to implement multi-factor authentication for any individual accessing an information system, to encrypt customer information in transit and at rest, and to log the activity of authorized users. Organizations operating in both the EU and the US should map each control once and record which regime it serves.
For EU-regulated sectors, the same identity platform usually has to meet national rules as well as the GDPR. Confirm with your supervisory authority, sector regulator and legal counsel which assurance levels, session rules and retention periods apply to your customers, because those answers change the authentication flows, log retention and evidence you need from Keycloak, ZITADEL or Ory. Recent enforcement cases, such as the EDPB's summaries of national fines for insufficient technical measures, show that supervisory authorities examine the security of customer accounts in practice, not only the policy describing it.
The sector pages hold the detail for financial services, healthcare, public sector and SaaS, so this page keeps to the GDPR baseline. Read the financial services and healthcare pages before you finalize authentication and audit design for those customers, and use the EU data sovereignty page for hosting and erasure questions that cut across sectors. Ask each partner to show how one configuration can support the GDPR and the sector regime without duplicated consent or log stores.
How DeployOpen scopes and delivers GDPR-aligned customer identity
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source identity platforms inside your own cloud accounts, data centers or air-gapped networks. For GDPR work, we turn the privacy requirements into a written scope, then build and document the controls that your privacy and security teams will need to review.
How we scope
- We map which customer data the identity platform holds, why each field is needed, and how long each field is kept.
- We agree which consent purposes, withdrawal paths and account recovery flows are in scope before any build work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing, and ongoing support available as a retainer.
How we build
- We configure the chosen platform, such as Keycloak, ZITADEL or Ory, with minimal default attribute sets and documented data flows.
- We set up consent records, withdrawal and erasure handling, and multi-factor or passkey options, then test each path end to end.
- We run security testing of login, registration and account recovery flows, and record the results alongside the configuration.
How we hand over
- We deliver architecture, data flow, configuration and runbook documentation that your data protection and security teams can review.
- We provide evidence packs that show how design choices map to GDPR Article 25 and Article 32 for your own assessors to examine.
- We train your operators on upgrades, backups and access control so that your team can run the platform after handover.
How we support
- We keep the platform current through upgrades, security patches and documented change control under an agreed retainer.
- We run continuous or periodic security testing of customer login flows if your scope includes it.
- We support your privacy and compliance reviews with updated documentation. DeployOpen does not issue audit reports or certifications; independent assessors do.
