Customer identity (CIAM) requirements checklist: how to use it
Before you compare Keycloak, ZITADEL or Ory, or send an RFP to a partner, you need a written list of what customer identity must do for your organization. This checklist gives you that list. It covers functional needs such as registration, consent, social and passkey login, B2B tenants with their own identity providers, branding per brand or tenant, and account recovery. It also covers security controls, integrations with your applications and APIs, day-two operations such as upgrades and availability targets, and the compliance evidence your regulators or auditors will ask for. The requirements are platform-neutral, so they stay useful whichever open-source product you later select or whether you build, partner or buy a managed service.
Work through the checklist in five groups: functional, security, integration, operations and compliance. Give every requirement a named owner, a plain-language acceptance test and a verification method, such as a load test report, a configuration review, a recovery drill or a sample export of consent records. A requirement without an owner tends to be deferred, and one without a test cannot be shown to a partner, an assessor or your own risk committee. For peak login volumes and availability targets, record the numbers your business owners approve rather than estimates from a vendor, and mark any figure you have not yet validated so it is confirmed before procurement.
The checklist becomes sharper once you fix the audience types it must serve. Consumer identity, B2B tenant identity and mixed models carry different answers on tenancy, branding, provisioning and recovery, so decide early whether each requirement applies to end customers, to the organizations that buy from you, or to both. Once that decision is made, the functional and integration sections can be filled in with specifics, and the sector-specific pages in this group explain how financial services, healthcare, SaaS and public sector requirements typically diverge from the baseline.
Customer identity (CIAM) requirements to verify
This table lists the functional CIAM requirements a platform must meet, why each matters to the business, and a concrete test the buyer can run before signing. Use it as an acceptance checklist during a proof of concept, and treat any requirement a candidate cannot demonstrate in a working flow as an open risk.
| Requirement | Why it matters | How to verify it |
|---|---|---|
| Registration and consent flows | Consent records must show what a customer agreed to, when, and under which policy version. Gaps here create problems during privacy reviews and audits. | Run a live registration with a test user through each consent path, then export the stored consent record and confirm the policy version and timestamp are present. |
| Social login | Customers expect to sign in with providers they already use, but each provider adds its own account-linking and data-sharing questions. | Connect one social provider in a test realm, sign in as a new user, and confirm the account links correctly to an existing email-based account without creating a duplicate. |
| Passkey login with password fallback | Passkeys reduce phishing exposure, but customers still need a recovery path while adoption grows. Fallback rules decide how much account takeover risk remains. | Enroll a passkey on two browsers and one mobile device, sign in with each, then disable the passkey and confirm the password path still works and is logged. |
| B2B tenants with their own identity providers | Each business customer may require its own SAML or OIDC provider, and one customer's configuration must never affect another's users. | Onboard a test tenant from a sample SAML or OIDC provider, sign in as a user from that tenant, and confirm a user from a second tenant cannot reach the first tenant's applications. |
| Branding per brand or tenant | Login pages carry brand trust. Mismatched themes or domains can enable phishing lookalikes and generate support tickets. | Apply two distinct themes to two test tenants or brands, load each login page on its own domain, and check that logos, text and error messages change without code edits. |
| Account recovery | Recovery is the most common route for account takeover. The flow must verify identity without creating a help desk bottleneck. | Trigger recovery for a test account using each offered method, including loss of the passkey device, and record the verification steps and audit events produced. |
| Privacy rights: access and export | Customers can request a copy of their data, and the request must return complete and accurate records within the timeframe set by the applicable regulation. | Submit an export request for one test user, then compare the output against the admin console and database to confirm profile, consent, role and session data are all included. |
| Privacy rights: erasure | Erasure must remove or irreversibly anonymize personal data across the identity store, logs and connected systems, while keeping records that law requires. | Erase one test user, then search the identity store, admin events and connected application records to confirm personal data is removed or anonymized as documented. |
| APIs and SDKs | Application teams need stable interfaces for registration, profile updates and session checks. Unstable APIs force rework on every upgrade. | Build a small test application against the documented API or SDK, complete a sign-in and profile update, and confirm the same calls work after a minor version upgrade in a staging environment. |
How to size expected users and peak logins before you choose a platform
This sequence turns scattered traffic history and business plans into a documented set of user counts and login peaks. Those figures decide the database, cluster and licensing shape you need, so they should be agreed before any platform is shortlisted.
Define what counts as a user
Agree with product and legal teams which records count as registered users, which as active users and which as identities that only exist for B2B tenants or test accounts. Include guest checkouts, dormant accounts and accounts pending verification in the definitions, because each category affects storage and sizing differently. Done when the definitions are written down and each brand or tenant uses the same terms.
Pull registered user totals by brand
Ask the current identity or customer database owner for total registered accounts, split by brand, region and account type, with the date of each extract. Where accounts sit in several systems, such as a legacy login service and a CRM, record which system is the source of truth and how duplicates are matched. Done when you have one reconciled total per brand and a note of any known gaps.
Measure daily and monthly active users
Pull daily and monthly active user counts from product analytics or authentication logs for a representative period that includes normal and seasonal months. Separate users who signed in from users who only opened the app without authenticating, since only sign-ins load the identity platform. Done when you have a trend line for daily and monthly active users and a stated definition of an active session.
Identify login peaks and their triggers
Work with marketing, operations and product owners to list known peak events, such as campaign launches, payroll days, market open, statement release dates, renewal deadlines and outage recovery. For each event, record the expected logins per minute and how long the surge lasts, using historical peaks from analytics where they exist. Done when every peak has a named trigger, an owner and a source for its estimate.
Estimate failed login and recovery rates
Extract failed password attempts, lockouts, password reset requests and one-time code requests from support tickets, the help desk queue and existing authentication logs. These figures often multiply load during an incident, because retries and reset emails arrive together. Done when you have failure and recovery rates per peak type and an explicit assumption for how they rise during an outage.
Model the peak against the growth plan
Combine the historical peaks with the growth targets in the business plan and any planned passkey, social or partner onboarding changes that alter the login mix. Show the peak as a sustained rate and a short burst, and add a scenario for a major campaign that the team has not run before. Done when the model shows base, expected and stress cases, each with stated inputs.
Document assumptions and obtain sign-off
Write each assumption, its source, its date and its owner in one sizing record, and flag the figures that are estimates rather than measurements. Ask finance to confirm the commercial assumptions that affect licensing or any per-user vendor pricing, and ask product to confirm the growth and event assumptions. Done when finance and product have signed the record and it is versioned for later review.
Hand the sizing record to platform decisions
Share the signed record with the architecture and procurement teams, who use it to size database capacity, cluster nodes, availability zones and the expected cost of running the platform or buying a hosted service. Confirm with any shortlisted vendor or implementation partner which of these inputs their sizing method needs, and ask how they will test the stated peaks. Done when each platform option is evaluated against the same documented numbers.
Security requirements every CIAM platform must meet
Customer identity sits in front of accounts, payments and health or financial records, so its security controls are usually the first thing auditors and regulators ask about. The cards below turn those expectations into concrete decisions you can write into an RFP and test during evaluation.
Authentication strength and fallback
Decide which factors are mandatory for which actions: password plus one-time code for low-risk logins, and passkeys for higher-risk actions such as changing contact details or moving money. Passkeys based on FIDO2 and WebAuthn are supported by ZITADEL, and Keycloak can be configured for them, but confirm the exact flow you need in a proof of concept. Specify how password fallback is handled during the transition and who can switch it off. The FTC Safeguards Rule 16 CFR 314.4 requires multi-factor authentication for individuals accessing information systems, so the MFA design must be written down, not assumed.
Session and token lifetimes
Set idle timeouts, absolute session limits, access token lifetimes and refresh token rotation as explicit values per client type. Browser apps, mobile apps and machine clients need different settings, and a single global default often over-trusts one of them. Ask the vendor or implementation partner to show where each lifetime is configured, how refresh tokens are revoked on password change or device loss, and how sessions are ended across all relying applications when a user signs out or an account is locked.
Brute-force and account takeover defenses
Require rate limits on login, password reset and one-time code endpoints, plus lockout or step-up rules that trigger on repeated failures from new devices or locations. Account takeover usually succeeds through credential stuffing, SIM swap or recovery abuse, so the design should cover all three paths, not only the password form. Confirm which of these controls the platform provides natively, which need a web application firewall or bot protection in front of it, and which must be built in your own code.
Encryption in transit and at rest
Require TLS for every browser, API, federation and database connection, with certificate management and cipher policy defined by you. Encrypt the identity database, backups and any secrets used for signing keys or client credentials at rest. The FTC Safeguards Rule 16 CFR 314.4 asks covered financial institutions to encrypt customer information in transit and at rest, and the HIPAA Security Rule 45 CFR 164.312 covers transmission security for ePHI. Ask where signing keys are stored and who can export them.
Administrator access and audit logging
Limit who can change realms, tenants, clients, identity providers and authentication flows, and require named administrator accounts with MFA. Every administrative change and every authentication event should be logged with a unique user identifier so investigations can reconstruct what happened. The HIPAA Security Rule 45 CFR 164.312 requires unique user identification and audit controls for systems holding ePHI, and the FTC Safeguards Rule 16 CFR 314.4 requires logging of authorized user activity. Confirm log retention, export to your SIEM, and tamper protection with the vendor.
Secure defaults on upgrade
Upgrades can reset or weaken settings, so record your hardened baseline and test it against every new release before production. Check whether a minor release changes default behavior and whether the change is opt-in. For Keycloak, the project states that breaking changes in a minor release are opt-in, but the Operator documentation recommends manual approval mode for operator updates to avoid unintended upgrades. Ask your partner how baseline checks run after each upgrade and who signs off on exceptions.
Which requirements change by customer type
Consumer login is usually judged on conversion, recovery and scale. Registration and sign-in must work for a very large, uneven population of people on many devices, and the requirements that gain weight are the ones that shape the first five minutes of the customer relationship. Expected peak logins, social and passkey options and account recovery tend to dominate the discussion, while B2B provider onboarding usually drops out of scope.
- Peak login behavior: Ask for the expected peak hour, campaign spikes and the share of logins that happen on mobile. Use these to size the load test, not a single average.
- Social and passkey options: Decide which social providers are required by market and whether passkeys are offered at sign-up, after sign-in or both. Plan password fallback for the transition period.
- Account recovery without a help desk: Define self-service recovery paths, such as device-bound recovery or verified email and phone, and what happens when a customer loses every factor.
- Consent and preference capture: Decide which consent events must be recorded, how withdrawal works, and who can read the record during an audit.
- Bot and abuse controls: Specify rate limits, bot protection and step-up triggers for credential stuffing.
Before sizing, confirm with marketing and product owners which markets and languages are in scope, and confirm with the security team which login risk signals must trigger extra verification.
In B2B multi-tenant login, each customer organization typically brings its own identity provider, and the platform acts as a broker that routes each tenant to the correct provider. The requirements that gain weight are tenant isolation, provider onboarding and the administrative model that lets a customer manage its own users. Scale per tenant matters less than correctness, isolation and the speed at which a new tenant can go live.
- Tenant model: Decide whether each customer gets a separate instance, an organization inside a shared instance, or a realm, and document what data and configuration each model isolates.
- Provider onboarding: Define who submits provider metadata, how it is validated and how a tenant's own administrators can change it without platform staff.
- Directory provisioning: Confirm which customers need SCIM provisioning or directory federation, and how deprovisioning is tested when a customer leaves.
- Per-tenant branding: Specify which login screens, emails and domains each tenant can customize, and which elements the platform keeps fixed.
- Tenant-level audit: Decide which sign-in and administrative events each customer can see, and how records are retained for that customer.
Before designing, confirm with sales and customer success how many tenants are expected in the first year, which identity providers dominate the pipeline, and whether any customer requires a dedicated deployment for contractual or regulatory reasons.
A mixed estate runs several consumer brands, or a mix of consumer and B2B properties, on one identity platform. The main design question is how much to share and how much to separate. Shared login reduces cost and simplifies support, but brand isolation, separate legal entities and separate data rules can all push the design toward separation. The requirements that gain weight are branding, data boundaries and governance across brands.
- Brand isolation: Decide whether each brand needs its own realm, instance, domain, login theme and client configuration, and whether a customer can move between brands with one account.
- Shared versus separate user stores: Confirm which brands may share a user base and which must keep records apart because of contracts, regulation or acquisition history.
- Central governance: Define who approves a new brand, who owns shared policies such as password rules and MFA, and how brand teams request changes.
- Cross-brand reporting: Specify which login metrics roll up to a group view and which stay within each brand.
- Upgrade coordination: Agree how a shared platform upgrade is scheduled so that no brand is disrupted by another brand's release calendar.
Before choosing a design, confirm with legal and brand owners which data may be shared across brands and whether any brand is planned for sale or divestment, because that decision strongly affects the tenant model.
How Keycloak, ZITADEL and Ory differ on tenancy and identity providers
Keycloak, ZITADEL and Ory cover much of the same ground on the checklist, but they reach it differently, and the differences matter most for B2B tenancy and per-customer identity providers. Keycloak is an open source identity and access management server licensed under Apache 2.0 and is a Cloud Native Computing Foundation incubating project. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, identity brokering and user federation, and its current release is 26.8.1. For production, its supported databases include PostgreSQL (14 to 18), MariaDB, MySQL, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and Azure SQL. Its high availability designs need a synchronously replicated database, so the reader should confirm the database platform and replication model early. The Keycloak Operator, installed through Operator Lifecycle Manager, is the usual route to Kubernetes, and the operator documentation recommends manual approval mode for updates.
ZITADEL is licensed under AGPL-3.0 for its core, while its APIs, SDKs, proto definitions, documentation, Helm charts and Terraform configurations stay under Apache 2.0. Its tenancy model is the most explicit of the three: instances are virtual tenants with full data isolation, organizations inside an instance hold projects and users, and each customer organization can federate login with its own identity provider over OIDC or SAML, LDAP, or another provider. It also supports passkeys based on FIDO2 and WebAuthn with password fallback, and a SCIM v2 interface for provisioning from customer directories. Self-hosted ZITADEL uses PostgreSQL 14 through 18. If your team modifies ZITADEL, review the AGPL obligations with counsel before you ship changes to users over a network.
Ory Kratos (identity and user management) and Ory Hydra (OAuth 2.0 and OpenID Connect server) are licensed under Apache-2.0, and both released v26.2.0 on March 20, 2026. Ory is a composable option: Kratos handles registration, login and recovery flows while Hydra issues tokens, so tenancy, branding and provisioning often need more custom build work than in the other two platforms. Whichever platform you choose, the capabilities in this section must be confirmed in a proof of concept against your own tenant model, including per-organization identity providers, passkey enrollment and SCIM behavior, rather than taken from documentation alone.
Integration requirements: directories, APIs, SDKs and data stores
A CIAM platform is only as useful as its connections to applications, customer directories, provisioning feeds and the database that holds customer records. The cards below list the integration decisions to settle before selecting Keycloak, ZITADEL or Ory, and what to verify in a pilot rather than assume from documentation.
Upstream and downstream protocols
List every application that will trust the identity platform and the protocol each one speaks. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, and ZITADEL implements OpenID Connect, OAuth 2.0 and SAML 2.0, but Ory splits these roles between Kratos for user management and Hydra for OAuth 2.0 and OpenID Connect. Confirm which token formats, signing algorithms and SAML bindings your relying parties accept, and test each one in a pilot with a real application.
User provisioning with SCIM
If customer organizations or enterprise tenants will push user changes, confirm which SCIM version each platform implements and which resources it accepts. ZITADEL provides a SCIM v2 service provider interface. For Keycloak and Ory, confirm whether SCIM is provided natively, through an extension or through custom integration. Ask who owns deprovisioning when a customer's directory removes a user, and test that disabling an account also ends active sessions.
Directory federation with LDAP and Active Directory
Many customers and workforce tenants hold identities in LDAP or Active Directory. Keycloak supports LDAP and Active Directory user federation, and ZITADEL can federate LDAP and OpenLDAP. Confirm the bind account permissions, whether password validation stays in the directory, how group membership maps to roles, and the behavior when the directory is unreachable. Test with a copy of the directory that matches your attribute schema.
Production database requirements
The database choice constrains backup, high availability and upgrade planning. Keycloak lists MariaDB, Microsoft SQL Server, MySQL, Oracle Database, PostgreSQL, EnterpriseDB Advanced, Amazon Aurora PostgreSQL and Azure SQL as supported production databases, and its high availability designs require a synchronously replicated database. Self-hosted ZITADEL uses PostgreSQL, with versions 14 through 18 supported. Confirm the exact version your platform team runs, and whether your managed database service is on the supported list.
SDK and API coverage for your stack
Map the languages, frameworks and mobile platforms your teams build with against the SDKs and client libraries each platform provides. Keycloak exposes an admin REST API and relies largely on standards-based client libraries, while ZITADEL publishes its own APIs and SDKs. Confirm that login pages can be customized for your web and mobile flows, and that custom code for flows such as step-up authentication can be maintained by your engineers after handover.
Migration of existing users and password hashes
Existing customers may hold passwords hashed with an algorithm the new platform does not accept. Ask whether the target supports importing hashes directly, just-in-time migration on first login, or a forced reset, and what each option means for customers who never return. ZITADEL documents migration guides from Auth0, Keycloak and Firebase. Confirm the hash formats your current provider uses and run a migration test with a sample of accounts before committing to a cutover date.
Operational requirements and how to verify them
This table turns operational needs for a customer identity platform into requirements you can define and test before selecting Keycloak, ZITADEL or Ory. Each row names what to decide, what to ask a partner or vendor for, and how to verify it in a test environment before production. Treat any target you cannot yet verify as a gap to close before go-live.
| Requirement | Target to define | How to verify |
|---|---|---|
| Availability target and failure modes | Written availability objective for login and token endpoints, plus the failures you must survive: node loss, zone loss, database failover and identity provider outage | Run failure drills in a test environment that match production topology and record observed behavior against the written objective |
| Cluster and database design | Keycloak supports one cluster spread across availability zones or multi-cluster designs, and both supported designs need a synchronously replicated database. ZITADEL recommends Kubernetes with the official Helm chart for high availability | Confirm the chosen design with the vendor's high availability documentation, then test database failover and cluster node loss under load |
| Supported database and versions | Production database from the vendor's supported list, such as PostgreSQL 14 to 18 for Keycloak and ZITADEL; dev-file databases are for development only | Check the version against the vendor's current database guide and confirm the same engine and version runs in test and production |
| Upgrade cadence and downtime tolerance | Keycloak plans four minor releases a year and says breaking changes in minor releases are opt-in. Define how many releases behind you accept and the maintenance window you can tolerate | Upgrade a copy of production in test first, review the upgrading guide for each release, and time the schema migration on realistic data volumes |
| Operator update policy | Use manual approval mode for operator updates, as the Keycloak Operator documentation strongly recommends, so upgrades never start unplanned | Confirm the approval setting in the cluster configuration and review the change record before each approved upgrade |
| Schema migration method | Automatic startup migration by default, or manual SQL applied by administrators, which the Keycloak upgrading guide suggests for large deployments | Compare both methods in test, keep a reviewed migration script for production and confirm rollback steps with the partner |
| Backup and restore | Define backup frequency, retention, encryption and who can restore. Include realm configuration, client secrets and signing keys, not only the user database | Perform a timed restore into an isolated environment and log the result, then confirm users can log in against the restored system |
| Observability and metrics | Metrics for login success and failure rates, token issuance latency, database connection health and certificate expiry, exposed to your monitoring stack | Confirm the metrics endpoint is enabled in Keycloak with the vendor's metrics guide, alert on thresholds you set, and test each alert once |
| Support hours and escalation | Support coverage hours, severity definitions and escalation path for a login outage, written into the scope or retainer | Ask the partner for the written support terms and run a tabletop exercise for a login outage at the hour you expect the most logins |
| Environments | Separate development, test and production environments with the same version, configuration pattern and identity provider settings, with production data kept out of lower environments | Compare configuration exports between environments, confirm test data is masked or synthetic and check that promotions are logged |
What customer identity (CIAM) requirements cost to define and who must be involved
How long does it take to define CIAM requirements, and what makes it longer?
The duration depends mainly on how many brands, tenants and user populations you serve, and on how many decisions are still open when the work starts. Teams with one consumer login and a single set of rules usually finish faster than teams that must reconcile separate brands, B2B identity providers and several privacy regimes. Ask any partner to state the duration and effort in the written scope, with the assumptions behind it, rather than accepting a generic estimate. Expect longer timelines when your existing user store, password hashes or consent records are undocumented, because those need inventory before any design choice can be made.
Can our own team define CIAM requirements without outside help?
Yes, many internal teams can draft the requirements if they have product, identity engineering and privacy ownership in one place. The harder part is making decisions that bind other teams, such as which login methods are offered, how account recovery works and which data is kept after account deletion. A useful test is whether someone can answer questions about expected peak logins, tenant onboarding and privacy requests without escalating. If not, an outside partner can run the discovery sessions and produce a written requirements document, while your team keeps final decision rights.
Which teams must be involved in CIAM requirements, and what does each one contribute?
Four groups usually need to sign off:
- Security defines authentication assurance, MFA and step-up rules, session limits and monitoring expectations.
- Product and customer experience define registration, consent, passkey and recovery journeys, plus branding per brand or tenant.
- Legal and privacy define consent wording, retention, erasure and export handling, and which jurisdictions apply.
- Platform and operations define availability targets, peak load, upgrade windows and who receives alerts.
For regulated sectors, compliance leads should also review the requirements because they set the evidence the platform must later produce. Named owners and sign-off dates in the requirements document make later quotes easier to compare.
How do the requirements turn into a fixed-scope quote?
A fixed-scope quote follows from a written list of requirements, each tied to a deliverable, such as a configured realm or instance, a federation connection, a theme, a migration run or a test report. Vague requirements force the partner to price risk, so precise statements of user volumes, tenant counts, supported identity providers and integration endpoints produce tighter quotes. Ask the partner to show which requirement maps to which deliverable, which items are excluded, and what changes would reopen the price. DeployOpen plans and implements work under written scope agreed before work starts, and does not publish a price list.
Which CIAM cost components recur after launch?
Most of the one-time cost is design, configuration, migration and testing. The recurring cost is the infrastructure that runs the identity service, including database, compute across availability zones and monitoring, which scales with login volume. Other recurring items are platform upgrades, security patching, on-call support, periodic load and penetration testing, and staff time for onboarding new tenants and identity providers. Keycloak plans four minor releases a year (per the Keycloak blog, October 2024), so budget for regular upgrade work. Ask the partner to separate one-time and recurring line items in the quote, and to state which recurring items are included in a support retainer.
Should a proof of concept happen before the requirements are final?
A short proof of concept is often worthwhile when a requirement depends on untested behavior, such as passkey enrollment on your target devices, a B2B identity provider with unusual attributes, or migrating existing password hashes. Keep it narrow and timeboxed, and record what it proved and what it did not. Do not treat a proof of concept as a substitute for load testing or for the final design. Once the proof of concept confirms or changes an assumption, update the requirements document and then price the implementation against it.
What should we ask a partner to confirm in writing before signing?
Ask the partner to confirm in writing the scope and deliverables, the assumptions behind effort and duration, the platform version and database they will use, and the high availability design they will build. Also request the list of exclusions, who performs testing and how results are delivered, the handover and documentation package, and how upgrades and support are priced after launch. For regulated work, ask which evidence will be produced for compliance assessments and confirm that independent auditors, not the implementation partner, issue any attestation. Request these answers as part of the statement of work so they can be enforced.
How DeployOpen scopes, delivers and supports CIAM selection and implementation
DeployOpen turns a CIAM requirements checklist into a written scope before any build starts, covering user volumes, login flows, tenant onboarding and privacy handling. We plan, implement, customize, integrate, harden, document and support self-hosted open-source identity platforms inside your own cloud accounts, data centers or air-gapped networks.
How we scope
- Workshops map expected users, peak logins and availability targets to the platform design
- Registration, consent, recovery and privacy rights flows are written down as in-scope deliverables
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
How we build
- Candidate platforms such as Keycloak, ZITADEL or Ory are compared against your login, tenant and branding requirements
- Social, passkey and enterprise identity provider connections are configured and tested per tenant or brand
- Load, failover and security tests run against the agreed peak login and availability targets before go-live
How we hand over
- Documentation covers flow configuration, tenant onboarding steps, API and SDK usage and operating runbooks
- Upgrade, backup and restore procedures are written for your own team to run without DeployOpen involvement
- Evidence for privacy rights handling and access controls is packaged for your compliance and audit teams
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover
- Platform upgrades are planned and tested in a non-production environment before they reach customers
- DeployOpen prepares systems and evidence for compliance assessments, while independent auditors issue the reports
