Open source identity governance for DORA access management: what the rules ask for
An EU financial entity in scope of DORA has been subject to the Regulation's ICT risk management rules since 17 January 2025. For identity and access, the short answer is that DORA expects a unique identity for every staff and third-party staff member, managed across the full account lifecycle, with access limited to need-to-know, need-to-use and least-privilege principles, withdrawn without undue delay, and reviewed on a fixed cycle. Under Delegated Regulation (EU) 2024/1774, Article 20 covers identity and lifecycle, and Article 21 covers access rights, privileged access, strong authentication and review frequency. midPoint can automate joiner, mover and leaver events and generate the review and change records that show these controls operating, which is the evidence a supervisor will ask to see.
DORA sets no certification scheme, and the Regulation provides no authority-issued attestation for identity controls. Competent authorities supervise compliance using their powers under Article 50, and they will judge your own documented controls and records. DeployOpen prepares systems, controls and evidence for that supervision, but it does not issue audit reports, attestations or certifications, and neither does any open-source vendor. Confirm with your national competent authority and your internal audit function which records they expect in practice, and agree that list before design starts so the midPoint configuration produces it by default.
The decision to make first is scope: which ICT systems and which systems supporting critical or important functions fall under the six-month review interval in Article 21, and which fall under the annual interval. Ask your team to confirm the authoritative HR source, the list of systems holding privileged rights, and where strong authentication is enforced for remote, privileged and publicly accessible assets. Those answers set the connector work, the certification campaign calendar and the evidence retention plan. Treat any figure in this area as something to confirm against the current text of Delegated Regulation (EU) 2024/1774 and your own risk assessment.
How DORA Article 20 and Article 21 requirements map to midPoint configuration
This table compares each DORA Article 20 and Article 21 identity requirement with the midPoint objects, feeds and reviews that normally evidence it. Read each row as a question to answer in your design: what is the control, which midPoint configuration carries it, and what record a supervisor or internal auditor would ask to see. The main takeaway is that midPoint produces the records, but the authoritative source, the role model and the SSO and MFA layer decide whether those records hold up.
| Requirement | midPoint configuration | Evidence to keep |
|---|---|---|
| Unique identity and full account lifecycle (Article 20) | One midPoint user object per person, linked to HR or contractor source records through a reconciled identifier. Projections to each target system created from lifecycle states such as active, suspended and archived. | Identity register with unique IDs, account creation and disable timestamps, and linked accounts per target system |
| Identity records kept after reorganisations or contract end (Article 20) | Retain archived user objects and their assignment history rather than deleting them. Configure retention in line with your record policy and confirm how midPoint audit records are stored and backed up. | Historical assignment and account records for leavers, including contract end dates and reorganisation moves |
| Automated joiner, mover and leaver tools (Article 20) | Inbound HR or contractor feed through a connector such as CSV, database or SCIM, with mappings that drive assignments from job code or unit. Test each mover case, including changes of manager and cost centre. | Feed logs, reconciliation reports and a sample of mover events showing removed and added entitlements |
| Need-to-know and least privilege, with segregation of duties (Article 21) | Business roles built from entitlement bundles, with assignment conditions by job function. SoD rules in midPoint define conflicting role pairs that trigger approval or block assignment. | Role catalogue with owners, SoD rule list, and records of approved exceptions with compensating controls |
| Limits on generic and shared accounts (Article 21) | Mark service and shared accounts as a separate object type with a named owner. Require an accountable person for each account and flag accounts with no linked identity in reconciliation reports. | Inventory of non-personal accounts with owner, purpose and last review date |
| Withdrawal of access without undue delay (Article 21) | Leaver events disable accounts and remove assignments from the HR termination date. Track leavers still holding access through reconciliation and orphan account reports. | Timestamped leaver removals compared with HR end dates, plus exception reports for late removals |
| Access reviews at least yearly, and at least every six months for critical or important functions (Article 21) | Certification campaigns scoped to ICT systems and to systems supporting critical or important functions, with a shorter cadence for the latter. Decisions feed back into midPoint as revocations. | Campaign definitions, reviewer decisions, revocation tickets and completion rates per campaign |
| Need-to-use privileged access (Article 21) | Privileged roles requested through an approval workflow with a defined end date, so grants are time-limited and renewed only on need. Review privileged assignments in their own campaign. | Request and approval records, expiry dates and privileged role review results |
| Strong authentication for remote, privileged and critical access (Article 21) | midPoint does not perform authentication itself. Its own UI can use an external SSO service, while SSO and MFA sit in a separate server such as Keycloak, and target systems must enforce the same policy. | SSO and MFA configuration exports, MFA enrolment reports and proof that privileged targets reject password-only sign-in |
How joiner, mover and leaver automation supports DORA identity records
The starting decision is which system is authoritative for each identity. For staff, that is usually the HR system of record, and for third-party staff it is the contract or vendor management register. midPoint should only create, change or disable accounts from those sources, so Article 20 of Delegated Regulation (EU) 2024/1774 can be met with one traceable origin for each unique identity and user account. Before go-live, document which HR fields drive joiner, mover and leaver events, who owns each source, and what happens when a contractor record has no end date. Confirm with your HR and procurement teams how contractor start and end dates are maintained, because an open-ended contractor record is the most common gap an examiner will find. Where a person is both staff and contractor, decide in writing which record governs their accounts.
DORA asks for automated lifecycle tools where appropriate, which means the entity must decide and record where automation applies rather than leave the choice implicit. A practical split is to automate joiner and leaver events for connected systems such as Active Directory, LDAP and the directly supported SaaS connectors, and to keep manual tickets for legacy or non-connected applications, with midPoint still holding the intended state. For each system, the decision record should state the connector used, the triggering event, the expected turnaround for withdrawing access, and the fallback when a connector fails. Access must be withdrawn without undue delay when no longer needed, so the leaver path needs an alert or task when a disable does not complete.
Records of identity assignments must survive reorganisations and contract end, so retention is a design requirement, not an afterthought. In midPoint, keep the identity object, its historical assignments and the audit trail of provisioning changes, and confirm with your records and legal teams how long each category must be retained under your national and internal rules. Test the design with a sample: take a leaver and a moved employee from the last year and reconstruct every account and entitlement they held, with dates and the approving source. If you cannot do this from midPoint and the connected systems alone, the gap is in the retention or logging design, and it should be closed before the first certification campaign.
Which open source platforms fit DORA identity governance
DORA's access rules in Article 20 and Article 21 of Delegated Regulation (EU) 2024/1774 cover several layers: the lifecycle record, the access decision, the authentication step, the secrets behind privileged access and the logs that show it all happened. No single platform covers every layer, so each card below names one component, what it handles and what your team still has to confirm.
midPoint for lifecycle and reviews
midPoint is the identity governance layer that drives joiner, mover and leaver processing from an authoritative HR source, holds the role model, enforces segregation of duties rules and runs access certification campaigns. It is licensed under the EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum states there is no enterprise edition. midPoint does not act as an SSO or access management server, so you still need a separate authentication layer. Confirm which target connectors your estate needs and whether they are supported or community-grade.
Keycloak for SSO and strong authentication
Keycloak handles workforce single sign-on, OpenID Connect, OAuth 2.0 and SAML 2.0 federation, and multi-factor enrollment policies that DORA's strong authentication requirement expects for remote, privileged and critical-function access. It is licensed under Apache-2.0 and is a CNCF incubating project. Plan an upgrade cadence, since the project ships four minor releases a year, and confirm which database and high availability design your resilience testing has approved.
authentik and ZITADEL as alternatives
authentik and ZITADEL cover similar SSO and MFA ground with different internal designs. authentik's core is MIT licensed, but the authentik/enterprise directory carries a separate enterprise license, so any feature you rely on there needs a licensing review. ZITADEL is licensed under AGPL-3.0 and lists SCIM and passkeys in its README. Neither replaces midPoint's lifecycle and certification functions, and you should verify how each one exports authentication logs for your retention rules.
OpenBao for privileged secrets
OpenBao stores and distributes secrets, certificates and keys, which matters where DORA's privileged access rules meet service accounts and automated credentials. It is licensed under MPL-2.0 and hosted under the OpenSSF. OpenBao does not decide who should hold a privileged role, and it does not record sessions, so pair it with midPoint's approval records and a session recording tool. Confirm how the key custody design meets your ICT third-party and encryption policies.
Wazuh for access logs
Wazuh is an open source XDR and SIEM platform that collects authentication and directory logs from SSO, midPoint and endpoints so you can show who accessed which systems and when. Its core is licensed under GPL-2.0. Wazuh does not generate the access decision or the joiner record, so it supports the review evidence rather than replacing it. Confirm that log retention and integrity controls match the record periods your supervisor expects.
Source systems and HR feeds
Every identity record in midPoint is only as reliable as its authoritative source, usually the HR system or a contractor register. DORA's requirement that identity records survive reorganizations and contract ends depends on this feed being complete and retained. This is not a platform choice but a component decision: check which HR system is the source, how contractors and third-party staff enter it, and who owns the mapping. Ask your implementation partner to document these owners before go-live.
How to sequence an IGA rollout for DORA evidence
The sequence moves from defining which systems matter for DORA to a clean starting population, connected sources and targets, a tested role model and a first review, so each phase leaves evidence that supervisors can follow back to the rules.
Scope critical or important functions and systems
Start by listing the business functions the entity has classified as critical or important, then map the ICT systems that support them, along with remote access paths, privileged accounts and publicly accessible assets. Compliance, risk and application owners sign off the list. The output is a scoped inventory that sets which systems fall under the six-month review cycle in Article 21 and which need strong authentication, so the later phases have a defined boundary to work within.
Clean up accounts and orphaned access
Before go-live, reconcile every account in the in-scope systems against the HR and contractor records, and flag accounts with no owner, generic or shared accounts, and entitlements held by people who have changed role or left. Decide with system owners what to remove, what to re-home and what to document as an exception with a named owner. Article 20 expects a unique identity for each staff and third-party staff member, so the reconciliation report and the exception register should show that every remaining account traces to a person or a documented service owner.
Connect authoritative sources and target connectors
Connect the HR or contractor source of truth to midPoint as the basis for joiner, mover and leaver events, then attach the target connectors for directories and in-scope applications using the ConnId connectors that match each system. Test each connector in a non-production environment, confirm which connectors have supported status and which are community or experimental, and record any gap that needs manual handling. Done means each joiner, mover and leaver event produces the expected change in every target, and the test results are kept as evidence.
Build the role model and segregation of duties rules
Define roles from the entitlements observed in the cleaned data, with business owners approving each role's scope and the rights it grants. Encode segregation of duties rules so that dangerous combinations of rights are blocked or routed for exception approval, and check that privileged access is assigned on a need-to-use basis. The output is an approved role catalogue, a rule set and a record of approvals, which together show the least privilege and segregation of duties design that Article 21 asks for.
Run and evidence the first access certification
Run a first certification campaign on the in-scope systems, routing reviews to managers and system owners through midPoint's access certification features. Reviewers approve, revoke or flag each entitlement, and the platform records the decisions, the reviewer and the timestamp. Revocations are carried out and checked against the target systems. The campaign is complete when every in-scope entitlement has a recorded decision, every revocation is confirmed in the target, and the results are saved as the baseline the next cycle will be compared against.
Set the upgrade path to a long-term support release
Choose the midPoint release line for production and document its support window. The 4.8 Curie long-term support release is supported until 17 October 2028, which gives a fixed horizon for planning upgrades. Confirm the Java and PostgreSQL versions that release requires, and agree a test-and-promote procedure with change management. The output is a written upgrade plan, a tested rollback path and a dated support register, so the team can show supervisors which version is running and when it must change.
What supervisors and auditors ask to see
What records do supervisors expect for identity and access under DORA?
Supervisors expect a unique identity register, a history of lifecycle events, documented role and segregation of duties rules, certification decisions, withdrawal records, privileged access grants and a written information security policy. Article 20 of Delegated Regulation (EU) 2024/1774 requires a unique identity and user account for every staff and third-party staff member, and records of identity assignments kept after reorganisations or contract end. Each record below should be traceable to the component that produced it and kept for the period your own retention policy and supervisory expectations set, which you should confirm with your competent authority.
- Identity register: the midPoint user objects, linked to HR source data and target system accounts.
- Lifecycle event history: midPoint audit records of joiner, mover and leaver events, with timestamps and the triggering source.
- Role and SoD rules: midPoint role definitions and policy rules that block dangerous combinations of rights.
Which system produces the identity register and lifecycle history?
midPoint produces the identity register and lifecycle history, because it holds the reconciled user objects and records each provisioning change it makes. Account data comes from authoritative sources such as HR through midPoint connectors, and midPoint writes the resulting account changes to target systems through the ConnId framework. Your team must confirm that the audit log is forwarded to or retained in a store that meets your retention and integrity requirements, since the audit trail is only useful if it survives platform upgrades and backups.
How do auditors check access reviews and reviewer decisions?
Auditors check that each periodic review covered the right population, was performed by an accountable reviewer and recorded a decision for every entitlement. Article 21 of Delegated Regulation (EU) 2024/1774 requires access rights to be reviewed at least once a year for ICT systems and at least every 6 months for systems supporting critical or important functions. midPoint certification campaigns record the campaign definition, the reviewer identity, each decision and any remediation, as described in the midPoint access certification documentation. Keep the campaign scope and reviewer assignments with the decisions so the population can be re-performed.
What evidence shows that access was withdrawn on time?
Evidence of withdrawal is a timestamped record showing when access was disabled or removed after the need ended. Article 21 requires access to be withdrawn without undue delay when no longer needed, so the timestamp of the leaver event and the timestamp of each downstream account change both matter. midPoint records the leaver processing and the connector actions it triggers. Confirm with your own auditors what interval they consider timely, and check that disabled accounts in target systems match the midPoint record, since a mismatch is a common finding.
What should be recorded for privileged access grants?
Privileged access grants should show who requested the rights, who approved them, the business reason, the period granted and when they were removed. Article 21 requires privileged access to be granted on a need-to-use or ad hoc basis, and strong authentication must apply to privileged access. midPoint access requests and time-bound assignments create these records, but you should confirm how your target systems log privileged sessions, because identity governance records the grant and the audit log of the target system records the use.
Which Article 9 policies must be documented and kept current?
The entity must hold a documented information security policy, a risk-based network and infrastructure management structure, and policies that limit physical and logical access to what approved activities require. Article 9(4)(a) to (c) of Regulation (EU) 2022/2554 sets these requirements, and the access control rules from Article 21 of Delegated Regulation (EU) 2024/1774 should be written into the same policy set. The identity governance design, including role definitions, approval rules and review cadence, should be cross-referenced to these policies with version history, so an examiner can see that the configuration in midPoint follows the approved text.
Can our own team produce this evidence without a partner?
Yes, many entities produce this evidence in-house, but the work depends on skills in identity governance, connector maintenance and audit log management. Cost components are the staff time for role modeling, connector build and testing, reconciliation of existing accounts, operating the platform and preparing evidence packs, plus infrastructure. midPoint itself carries no license fee, according to Evolveum, while Evolveum offers support subscriptions with SLA options that are priced separately and shown on its support page. Ask any implementation partner for a fixed-scope quote that lists which records they will deliver, how they will be retained and who maintains them after go-live.
What tooling alone does not satisfy under DORA
midPoint automates much of the identity lifecycle, but DORA's identity and access rules also depend on decisions, data and records that sit outside any product. The cards below cover the gaps that a midPoint deployment cannot close on its own, and what the entity must own before supervisors review its access controls.
No SSO or OAuth server in midPoint
Evolveum states that midPoint is an identity management system, not an access management or SSO server, and does not implement the server side of OAuth2, OpenID Connect or SAML. Strong authentication for remote, privileged and publicly accessible systems under Article 21 therefore has to be delivered by a separate access layer. Check which product issues tokens for each critical application, and confirm that midPoint's own console authenticates through that layer.
Policy and risk ownership stay with the entity
Article 9 expects a documented information security policy and access limits that match legitimate, approved activities. midPoint can enforce rules that the entity writes, but it cannot decide which roles are need-to-know or which combinations of rights are dangerous. Assign named owners for the access policy, the role catalogue and the segregation of duties rules, and record their approval before the rules are configured.
HR data quality decides lifecycle accuracy
Joiner, mover and leaver automation is only as accurate as the authoritative source feeding it. If HR records show late start dates, missed contract ends or outdated departments, midPoint will provision and withdraw access on the wrong trigger. Before go-live, measure how quickly HR changes reach the identity system, reconcile existing accounts against HR, and agree who corrects mismatched records.
Shared and generic accounts need process controls
Article 21 limits generic and shared accounts so users stay identifiable. midPoint can flag accounts without an owner, but it cannot prove who used a shared service login at a given time. Register every non-personal account with a named owner and a documented purpose, restrict who may check out its credentials, and link each use to a ticket or approval that an auditor can trace.
No tool produces a DORA certificate
DORA sets no certification scheme, and competent authorities supervise compliance using their Article 50 powers. The only authority-issued attestation the Regulation provides for is the one covering a threat-led penetration test under Article 26(7). midPoint produces records that support supervisory review, but no product output counts as certification. Ask the implementation partner to prepare the evidence pack and agree its scope with the entity's compliance and internal audit teams.
What drives the cost of a DORA-ready identity governance build
The first cost decision is what you pay for, because midPoint carries no license fee. Evolveum states that midPoint has no enterprise edition and that every line of its code is published under open source licenses, so the spend sits in services and operations. The main one-time cost is connector and role-modeling work: building the ConnId connectors to your authoritative HR source, Active Directory or LDAP, and the ICT systems that support critical or important functions, then defining the role model and the segregation of duties rules that Article 21 of Delegated Regulation (EU) 2024/1774 expects you to enforce against dangerous combinations of rights. Data cleanup is the second one-time item. Orphaned accounts, shared accounts and entitlements with no owner must be identified and resolved before go-live, because DORA requires each account to be traceable to a unique identity. The effort rises with the number of target systems, the number of legacy directories and the quality of HR data.
Recurring costs cover infrastructure, SSO integration and support. Infrastructure includes the midPoint application nodes, a shared PostgreSQL database on a separate server, load balancing for multi-node deployments and the test environment you need to upgrade safely. If you pair midPoint with Keycloak or another SSO server, the integration and its maintenance are a separate line item, since midPoint does not implement the server side of OAuth2, OpenID Connect or SAML. Evolveum offers Product Support subscriptions with 8x5 next-business-day or 24x7 SLA options, and Platform Subscriptions that add feature development, but the subscriptions page lists no prices. Ask each vendor and implementation partner for a written quote that separates one-time build, annual support, infrastructure hosting, and the cost of upgrades to a long-term support line such as 4.8, which is supported until 17 October 2028. Ask whether each periodic access review and its evidence retention are included in the scope.
How long does a DORA identity governance project take and what does it need from us?
Can we confirm whether DORA applies to our entity type?
Start with Article 2(1) of Regulation (EU) 2022/2554, which lists 20 types of financial entity in points (a) to (t), from credit institutions and payment institutions to insurers, crypto-asset service providers and securitisation repositories. Find your entity type in that list, then check with your national competent authority or your legal counsel how your licence maps to it. If you are an essential or important entity under NIS2, Article 1(2) also makes DORA a sector-specific act for that purpose. Confirm this before scoping, because it decides which Article 21 deadlines and evidence expectations apply to you.
What drives the duration of an identity governance project?
Duration follows scope and data quality more than tooling. The main drivers are the number of target systems that need connectors, how many HR or contractor sources feed identities, how clean existing accounts and groups are, and how many approval and certification flows you need on day one. A project limited to a few core systems with a clean HR feed is shorter than one covering the whole estate with legacy directories. DeployOpen agrees timelines in writing as part of a fixed-scope engagement, so ask for a phased plan that separates the first access certification from full automation.
What does our team need to supply before implementation starts?
Three inputs gate the work. First, authoritative HR and contractor sources with reliable joiner, mover and leaver events, since Article 20 expects a unique identity for every staff and third-party staff member. Second, named system owners for each target application who can confirm roles, entitlements and who approves access. Third, a signed-off access control policy that defines need-to-know, least privilege, segregation of duties and review cadence. Missing any of these usually moves the timeline, so agree on owners and sign-off dates in the scope document.
How much effort does the cost of a DORA identity project come from?
Most of the cost is people time, not licences. midPoint is published under the European Union Public License 1.2 or later and Evolveum states it has no enterprise edition, so the license line is zero, but connector configuration, role modeling, data cleanup, testing, infrastructure and support still need budget. One-time costs cover design, connectors, migration of existing access and the first certification campaign. Recurring costs cover platform operations, patching, connector maintenance and periodic reviews. Ask any partner for a quote that separates these components and names who performs each task.
Can our internal team run a DORA identity governance project alone?
A capable internal team can run it alone if it has engineers who know midPoint, the target systems and the identity sources, plus enough time for design, testing and evidence work. Many teams instead split the work: they own policy, system owners and reviews, while an implementation partner handles connectors, role design and hardening. Consider how many people can cover the platform long term, since midPoint's long-term support release 4.8 (Curie) is supported until 17 October 2028, and upgrades need planned capacity. DeployOpen plans, implements, integrates, documents and supports self-hosted open source platforms inside your own infrastructure, so you can choose which parts to hand over.
Which records should we expect supervisors to ask for?
Supervisors expect evidence that the access control rules operate, not only that they exist. Prepare a unique identity register covering staff and third-party staff, records of identity assignments kept after reorganisations or contract end, approval history for privileged and remote access, withdrawal records for leavers, and the outputs of periodic access reviews. Article 21 sets the review frequency: at least once a year for ICT systems and at least every 6 months for systems supporting critical or important functions. Confirm with your competent authority which format and retention period it expects.
What should we check in the implementation plan before signing?
Check that the plan lists each target system, its connector type and owner, the joiner, mover and leaver rules, the access request and approval flow, and the review cadence mapped to Article 21. Ask how orphaned accounts are cleaned up before go-live, how segregation of duties conflicts are detected and resolved, and how strong authentication is enforced for remote and privileged access through your single sign-on platform. Also confirm who performs upgrades, how backups and restore tests are scheduled, and what handover documentation you receive. A written scope with these items gives you a basis for comparing partners.
Does DORA itself certify our identity governance setup?
No. DORA sets no certification scheme, and competent authorities supervise compliance using the powers in Article 50. The only authority-issued attestation the Regulation provides for is the attestation that a threat-led penetration test met the requirements under Article 26(7). DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports or attestations. Plan your evidence so a supervisor or auditor can re-perform the controls from the records you keep.
How DeployOpen scopes, delivers and supports DORA identity governance
This sequence turns DORA identity and access obligations into a written scope, a midPoint deployment inside your own infrastructure, and a set of controls and evidence your team and independent assessors can review. Each step ends with a named output so you know when it is complete.
Map DORA access obligations to your estate
Your compliance lead, IAM owner and DeployOpen's solution architect start by reading Articles 20 and 21 of Delegated Regulation (EU) 2024/1774 against your ICT systems inventory. The team identifies which systems support critical or important functions, which carry privileged access, which are publicly accessible, and where remote or emergency access applies. The step closes with a requirements register that assigns each obligation to a system owner and marks the review cadence, at least yearly for ICT systems and at least every six months for critical or important functions. You confirm the register with your supervisor's expectations before design begins.
Agree a fixed scope in writing
DeployOpen issues a written scope that names the authoritative sources (HR, contractor registries, directories), the target systems and connectors, the joiner, mover and leaver rules, the certification campaigns and the evidence each control will produce. Deliverables, acceptance criteria and the responsibilities of your staff are listed in the same document. Most engagements are fixed-scope, so changes go through a written change request. The step is complete when your CISO or IAM owner signs the scope and the quote follows from it. Ask for the quote to itemize connector work, role modeling, data cleanup, infrastructure, documentation and support separately.
Deploy midPoint inside your infrastructure
DeployOpen installs midPoint in the cloud accounts, data centers or air-gapped network you designate, so identity data and the audit trail stay under your control. The build follows midPoint's system requirements, including a supported Java version, PostgreSQL on a separate database server, and a sticky load balancer with shared database if you run multiple nodes. Your platform team keeps administrative credentials, backup targets and hardening standards. The step closes with a documented baseline environment, tested backups and a restore test that your operations team has witnessed.
Integrate sources, connectors and roles
DeployOpen configures the ConnId connectors agreed in scope, such as LDAP, Active Directory, Microsoft Entra ID or SCIM targets, and models roles from existing entitlements. Before go-live, orphaned and excess accounts are reconciled and either assigned an owner or removed through an approved change. Segregation of duties rules are written against dangerous combinations of rights identified in the scope. The step is complete when each in-scope source reconciles with a documented exception list and a signed role catalogue, which becomes the reference for later reviews.
Configure lifecycle, requests and certifications
DeployOpen implements joiner, mover and leaver workflows, access request approvals and periodic certification campaigns in midPoint according to the written scope. Withdrawal of access when it is no longer needed is tested with sample leavers and movers, and privileged access is set up on a need-to-use or ad hoc basis where the scope requires it. Reviewers, approval routes and escalation paths are documented. The step closes with test records showing each lifecycle event, its approval and its effective date, verified by your IAM owner.
Prepare controls and evidence packs
DeployOpen compiles the control descriptions, configuration records, run logs, certification decisions and identity assignment records that map to the DORA requirements in scope, organized so that your internal audit function or an independent assessor can re-perform the tests. DeployOpen prepares this evidence but does not issue audit reports, attestations or certifications, since DORA sets no certification scheme and independent auditors and supervisors make the assessment. The step is complete when your compliance team confirms the evidence index covers every in-scope obligation.
Hand over runbooks and train operators
DeployOpen delivers runbooks for provisioning incidents, connector failures, certification cycles, backup and restore, and emergency access handling. Your operators and identity administrators are trained on the running system, and the handover is recorded against the scope. Ask the partner which knowledge transfer sessions are included in the fixed scope and which are optional. The step closes when your team runs a supervised certification cycle without vendor intervention.
Support, upgrade and retest on a retainer
After handover, ongoing support, upgrades and continuous testing are available as retainers, which fit midPoint's release cycle and its long-term support branches. Upgrades are planned against the support dates published by Evolveum, and each release is tested in a non-production environment before it reaches the live system. Your team decides whether the retainer covers monitoring, scheduled certification support or periodic access control testing. The step is complete when the upgrade plan, retainer scope and review calendar are signed and the evidence pack is refreshed after each change.
