How to use an identity governance requirements checklist
If you must decide whether to build, buy or partner for identity governance and administration, the most useful checklist is one where every requirement can be verified in a demo, a proof of concept or a reference check. Start by ranking requirements by what your regulators and source systems demand, not by what a vendor finds easy to show. Authoritative HR sources, the target systems that hold entitlements, joiner, mover and leaver rules, the role model, access request and approval flows, certification campaigns with their cadence, segregation of duties policies and the audit reports auditors will ask for are the core items. Each one should have an owner, an acceptance test and an example of the evidence it produces.
Use midPoint as the reference platform for the checklist, since it is the open-source IGA platform this group of pages is built around. For each item, ask the candidate to show a working case: a leaver removed from a connected directory, a mover whose entitlements change with a role, a certification decision that can be exported. Confirm the connectors you need in the Evolveum connectors documentation and check their support status, because catalog entries range from supported to community and experimental. Ask which midPoint release the candidate would deploy and how long that release is supported, using the midPoint releases page as the starting point.
Sector requirements differ enough that a general checklist is only a starting point. Financial services, healthcare, public sector and education each add review cycles, record retention and approval rules that change the priority of the items above. The sibling pages for those sectors go deeper on the specific controls, so use this checklist to fix the common core first, then add the sector items your auditors and regulators will test. Record which requirements are one-time setup work, such as source cleanup and role modeling, and which recur, such as campaigns and connector maintenance, because that split drives both the proof of concept scope and the quote you request.
Functional requirements for joiner, mover and leaver and access requests
This table lists the core functional requirements for joiner, mover and leaver processing, role design, access requests and orphaned account handling. Each row states why the requirement matters and how to verify it, usually by replaying a controlled change and tracing the result. Use it to test any implementation partner's proposal before scope is agreed.
| Requirement | Why it matters | How to verify |
|---|---|---|
| Authoritative HR source and identity correlation | Every account must trace back to one person record, or leavers and movers will be missed | Confirm the system of record for employment status, the unique key used to match identities across sources, and how contractors without an HR record are handled |
| Target systems and connectors | Each system that holds access needs a defined connector, owner and read-back method, or provisioning cannot be proven complete | Inventory every target, its connector type (for example LDAP, Active Directory, Entra ID or SCIM2) and whether the connector is supported, community or custom |
| Joiner rules with timing | Access granted before approval or delayed beyond the start date creates audit findings and onboarding gaps | Replay a sample new hire record and confirm which accounts and entitlements appear, in what order, and with which approval reference |
| Mover rules with removal of prior access | Role changes that only add access accumulate excess rights over time | Replay a transfer between two departments and confirm that old role entitlements are removed on the effective date, not only added |
| Leaver rules and deprovisioning timing | Delayed disablement of departed staff is a common finding in access reviews and regulated audits | Replay a termination record and time the disablement across every connected target, including shared and service accounts tied to the person |
| Role model across business, IT and entitlement roles | Without layered roles, reviewers approve raw permissions they cannot interpret | Confirm each business role maps to IT roles and entitlements, with a named owner per role and a sample of roles traced from existing access |
| Access request and approval flows | Requests without recorded approvers and justifications cannot be re-performed by an auditor | Submit a test request, route it through the approval chain and confirm the request, decision and provisioning result are all logged |
| Orphaned account handling | Accounts with no owner or matching person record become unmanaged access that reviews miss | Run a correlation report against each target and confirm the disposition workflow for unmatched accounts before go-live |
| Single sign-on as a separate requirement | midPoint is an identity governance platform, not an SSO or access management server, so login and federation need a separate design | Confirm which product issues tokens for applications, how it is paired with midPoint, and which team owns its configuration |
Which authoritative sources and target systems to inventory first
Inventory the authoritative HR source and every target system before you choose a platform. The platform can only be as accurate as the feeds it reads and the accounts it can write to. Start with a list of each system that creates or changes a person's identity, such as the HR system of record, contractor databases, student or clinical systems where they apply, and every directory that holds accounts (Active Directory, LDAP, Entra ID, and any local or SaaS user stores). For each one, record the owner, the key used to match a person across systems, how often it changes, and whether it can be read and written through an API, a database view or a file export. Then ask two design questions that will shape the rules: how many identities cannot be matched to a single HR record, and which shared, service or generic accounts exist and who answers for them. Each unmatched identity needs a documented decision, and each shared account needs an owner and a rule for how it is provisioned and certified, or it will sit outside every review.
Confirm each target connector individually. midPoint uses the ConnId connector framework, and Evolveum's documented connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID (Graph API), SCIM2 and SCIMv1. Its integration catalog also lists further connectors, and their status ranges from supported to community and experimental. A connector being listed does not mean it covers your version of a target application, your read and write operations, or the entitlement objects you need to review. For each target, write down the objects to manage (accounts, groups, roles, licenses), the operations required (create, update, disable, delete, read entitlements), and the connector status. Then ask each implementation partner which connectors they have deployed in production, against which product versions, and whether they can show a working lab or reference for the exact target. Connectors that exist only in a test environment are a schedule risk, not a capability.
Security requirements the IGA platform must meet
An identity governance platform holds the map of who can access what, so it becomes a high-value target. The requirements below cover the IGA's own security, and they map to the access control, encryption, logging and multi-factor expectations in the FTC Safeguards Rule at 16 CFR 314.4 and the technical safeguards in HIPAA at 45 CFR 164.312.
Protect the admin console and privileged roles
Restrict who can change connectors, role definitions, policies and approval workflows inside midPoint. Keep a short, named list of administrators, separate from everyday approvers, and review that list on the same cadence as application access. Check whether the console sits behind a controlled network path and whether changes to role mappings require a second person to approve them before they take effect. Ask the partner to document which roles can grant themselves access.
Encrypt identity data in transit and at rest
Identity data includes HR attributes, account records, entitlements and connector credentials, so it needs protection on every hop. Confirm that TLS covers the console, the connector traffic to Active Directory, LDAP and SaaS targets, and the link to the PostgreSQL repository. Confirm that database storage encryption and backup encryption are enabled and that the keys are managed outside the IGA host. This is the encryption expectation in the FTC Safeguards Rule at 16 CFR 314.4.
Handle service account and connector credentials
Each connector authenticates to a target system with a service account, and those credentials often hold broad rights such as creating and disabling users. Give each connector its own account with the smallest set of permissions it needs, and store its secret in a vault rather than in configuration files. Set a rotation schedule and confirm that rotating a secret does not require an outage. Ask the partner for a register listing every connector, its account and the rights it holds.
Log every provisioning and approval action
Audit controls must record and let someone examine activity in systems that hold health or financial data, and the FTC Safeguards Rule expects logging of authorized user activity. For each joiner, mover, leaver, request and certification decision, the log should capture who acted, what changed, when, and which approval or policy allowed it. Confirm that logs are forwarded to a separate store that IGA administrators cannot edit, and set a retention period with the compliance owner.
Separate duties for IGA administrators
The people who configure the IGA should not also approve the access it grants to themselves. Define separate roles for configuring connectors, authoring policies, approving requests and running certifications, and block any single administrator from holding more than one of them over the same population. Require a second reviewer for changes to segregation of duties rules. Ask the partner how the platform's own administrator accounts are reviewed and how emergency access is granted and recorded.
Require multi-factor authentication for administrators
Every administrative login to the IGA should require a second factor, and the FTC Safeguards Rule at 16 CFR 314.4 expects multi-factor authentication for any individual accessing an information system. Each administrator should have a unique account, which supports the unique user identification and person authentication expected under HIPAA at 45 CFR 164.312. Confirm whether the SSO server in front of midPoint enforces the factor, and whether break-glass accounts are protected by a separate control.
How certification campaigns and segregation of duties policies get evidenced
The first decision is who certifies what, and that choice drives everything else in the evidence trail. Certification campaigns need a named reviewer for each entitlement, usually the line manager for role membership and the application or data owner for privileged or high-impact access. Define how reviewers are assigned in the platform, including what happens when a manager has left or owns no direct reports, because orphaned reviews are a common gap an auditor will find. Agree with the business owner how often each population is reviewed, how long reviewers have to act, and whether reviews escalate when they lapse. Those cadence settings are a design choice you record in writing before the first campaign runs, and the sector-specific frequency that regulators expect belongs on the sibling pages for each framework.
Revocation is where campaigns usually fail. Confirm that a decision to remove access in a campaign generates a provisioning action against the target system, not just a status change in the identity platform, and that the platform reports whether the removal succeeded. Keep the decisions themselves as records: reviewer identity, timestamp, the access item reviewed, the decision, the justification where one is required, and the outcome of the revocation. Ask the implementation partner to demonstrate how a single decision can be traced from campaign to target system change, because that trace is what an assessor re-performs.
Segregation of duties is a policy the platform must evaluate, not a spreadsheet kept beside it. Before configuration, work with the business owner to define the conflicting entitlement pairs, such as the ability to create a vendor and the ability to approve its payment, and document the reason each pair conflicts. The platform should check these rules when an access request is submitted, which is the preventive control, and again when roles or entitlements change, which catches conflicts created by movers or by a new connector. Ask the partner which SoD rules are enforced at request time, which are detected after the fact, and how exceptions are approved and expire, because an exception without an end date is a finding waiting to happen.
Integration requirements with HR, directories, SSO and ticketing
An identity governance design is only as accurate as the systems feeding it and the systems it provisions into. The cards below cover the integrations that most often decide whether joiner, mover and leaver rules work on day one, and they flag where SSO is a separate layer that must be named in the design.
Authoritative HR feed and change events
Identify the system of record for employment status, manager, department and job code, then decide how changes reach midPoint: a scheduled file or extract, a database view, or an API feed. Joiner, mover and leaver rules depend on the timing and reliability of these events, so ask how late, corrected or back-dated HR changes are handled and whether terminations are visible within the same business day. Confirm the feed format and ownership with HR and the HR system vendor in your own environment.
Directory and target system connectors
List every directory and application that receives accounts, including Active Directory, LDAP and any SaaS targets, and confirm which ConnId connectors your partner has deployed against each one. midPoint documents connectors for LDAP, Active Directory, CSV, DatabaseTable, Microsoft Entra ID through the Graph API and SCIM2, but many line-of-business applications will need a custom or community connector. Ask who maintains each connector after go-live.
SSO server paired with midPoint
midPoint is an identity management system, not an access management or SSO server. It does not implement the server side of OAuth2, OpenID Connect or SAML, so the design must name the SSO server, for example Keycloak, and state how the two pair: which system holds credentials, which pushes group or role membership, and which applications authenticate through the SSO server. Confirm the protocol, claim mapping and session behavior with both teams before build starts.
Ticketing handoff for manual fulfillment
Some entitlements will remain manual, such as access to legacy systems without an API or hardware-linked permissions. Define how midPoint creates a ticket in your service desk, what fields it carries, who approves completion, and how the ticket closes back into the identity record. Ask whether the fulfillment outcome is recorded against the original request so auditors can trace requested, approved and granted access end to end.
SIEM and log forwarding of provisioning events
Decide which provisioning, approval, certification and failed-connector events leave midPoint, where they are stored, and how long they are retained. Security monitoring and audit both rely on these records, so confirm the log format, the transport and the retention owner with your SIEM team. Test that a leaver's account disablement generates an event the security team can see.
Secrets and certificate stores for connector credentials
Connectors authenticate to directories and target systems with service accounts, and those credentials should not sit in configuration files. Identify the secrets store that will hold connector passwords and client secrets, such as OpenBao or Infisical, plus the certificate authority behind any mutual TLS connections. Ask who rotates these credentials, how often, and how a rotation failure is detected before provisioning stops.
Operational requirements and how to verify them
This table lists the operational requirements a midPoint deployment must meet, the platform facts that bound them, and what to verify before committing. Read each row as a check to run against your own design and the release page on the day you decide. The main takeaway is that Java, PostgreSQL and release support dates change over time, so confirm them at decision time rather than relying on this page.
| Requirement | What to verify | Evidence to request |
|---|---|---|
| Hosting model | Linux virtual machines or Docker images in your own cloud account, data center or air-gapped network, with patching owned by your team or partner | Architecture diagram, image source and patch procedure, and the named owner for each host |
| Java runtime | midPoint recommends Java 25 for 4.11 and later (Java 21 supported); 4.10 and older recommend Java 21 (Java 17 supported) | Runtime version pinned in build and deployment records, with a documented upgrade path |
| PostgreSQL repository | PostgreSQL is the native repository database, ideally on a separate database server from the application nodes | Database server version, separation of duties for DBA and application teams, and tested failover |
| Multi-node design | Sticky HTTP load balancer, shared central database, cache invalidation between nodes over HTTPS and Quartz for distributed task scheduling | Load balancer session configuration, node list, and a test showing scheduled tasks run once across nodes |
| Backup and restore | Database and configuration backups restored into a separate environment on a schedule, with the restored state checked against live data | Dated restore test records, recovery time observed, and who signed off the result |
| Release and support planning | Check the midPoint releases page on your decision date: 4.8 Curie is long-term support until 17 October 2028, 4.10 Braille is supported until 26 November 2027, and 4.9 support ends 18 October 2026 | Written upgrade policy naming the target release line, test environment plan and change approval record |
| Monitoring | Track node health, task execution, connector errors and database health, with alerts routed to the identity operations team | Dashboard screenshots, alert rules and the escalation runbook for failed provisioning runs |
What do buyers ask before hiring help for identity governance?
What drives the cost of an identity governance implementation with midPoint?
The main cost drivers are the number of source and target systems, the work to model roles from existing access, the cleanup of data before go-live, the infrastructure the platform runs on, and ongoing support. midPoint itself carries no license fee, and Evolveum states that midPoint has no enterprise edition, so the spend goes to people and infrastructure. Connector count matters most because each system needs its own connector configuration, mapping and testing. Role modeling effort rises with the number of applications and the messiness of current access. Ask every partner for a quote built from a written scope that lists each connector, each role family, the data cleanup assumptions and the support terms. Evolveum lists no prices for its subscriptions, so the quote has to come from the scope itself.
Which identity governance costs are one-time and which recur?
One-time costs usually include scoping, source and target analysis, connector build and testing, role design, data cleanup, initial certification setup and migration of existing access records. Recurring costs include infrastructure for production, database operations, backups, upgrades and patching, support subscriptions, and the time of the people who run access requests and review campaigns. Upgrades recur because midPoint publishes feature releases and long-term support releases on fixed support windows, so each upgrade cycle needs regression testing against your connectors. Ask the partner to separate the one-time project fee from the annual run cost, and to state which items are included in each.
How long does an identity governance rollout take?
The duration depends mainly on how many authoritative HR sources and target systems are in scope, how clean the existing accounts are, and how many roles must be designed and approved. A rollout that connects one HR source to a few directories takes a very different path from one that reconciles several directories and dozens of applications. No general timeline is reliable without the inventory, so ask for a written scope with phases, dependencies and go-live criteria before accepting any date. Fixed-scope engagements agree deliverables and timelines in writing before work starts, and that document is the right place to check the plan. Be cautious about any proposal that quotes a duration before reviewing your source and target list.
What does the client team have to provide for an identity governance project?
The work needs three client roles to be named early. HR data owners confirm the authoritative source for joiners, movers and leavers, including employment status codes and effective dates. Application owners confirm which accounts and entitlements exist in each target system, who approves access to it, and how it is removed. Reviewers, usually managers and system owners, must be available for certification campaigns and must accept the decisions they make. Security and compliance leads should also agree the policies for segregation of duties and the evidence they will need. Without these people the design stalls, so ask a partner to list the named roles and time commitments in the scope.
Can our own engineers run midPoint, and where does that break down?
A capable platform team can run midPoint in-house, and the open source license places no restriction on doing so, since every line of code is published under open source licenses. The difficulty lies in the surrounding discipline. midPoint runs on Java with PostgreSQL as its native repository, multi-node deployments need a sticky load balancer, a shared database and distributed task scheduling, and connectors need ongoing maintenance as target systems change. Teams usually struggle with role modeling, reconciling existing access, writing review workflows that auditors accept, and planning long-term support upgrades. Decide early which parts your team owns and which parts a partner delivers, and write that split into the scope.
What do Evolveum support subscriptions cover compared with a partner?
Evolveum's Product Support subscriptions cover resolving product bugs, with an 8x5 next-business-day or 24x7 SLA, while its Platform Subscriptions add feature development and roadmap influence. These subscriptions are provided by the software vendor and concern the midPoint product itself. A partner covers the work around the product: planning and scoping the deployment in your environment, designing the role model, building and testing connectors for your systems, cleaning source data, configuring certification campaigns and evidence, hardening, backup and documentation, and ongoing upgrades under a retainer. Confirm the SLA terms in the Evolveum listing directly, and ask the partner which of these items sit in its written scope.
Does midPoint have an enterprise edition that changes the cost?
No. Evolveum states that midPoint has no enterprise edition and that every line of midPoint code is published under open source licenses, so the project describes itself as open source rather than open core. The repository is licensed under the European Union Public License 1.2 or later with Apache 2.0 as a secondary license. Evolveum funds development through subscriptions, training and professional services, so the license is not where the cost sits. Ask any partner to confirm which components they would add that are not open source, such as their own tooling or proprietary connectors, and to name the license terms for each in the quote.
Questions that separate IGA platforms and implementation partners
Use the answers to a short list of questions to separate partners that have run midPoint in production from those that have only read its documentation. Start with role modeling from existing access: ask how the partner derived roles from the entitlements that already exist in Active Directory, LDAP and target applications, how many roles came out of that analysis, and how exceptions were handled. A partner who can explain the mining method, the sign-off by business owners, and the rules for roles that cover only a few people has done this work. A partner who starts from a generic role catalog has not.
Next, ask which connectors are in production, which are running in a test environment, and which are community or experimental. midPoint documents connectors for LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID, SCIM2 and SCIMv1, and an wider catalog with varying support status, so the partner should name each target system, the connector version it runs, and the owner who has accepted it. Ask how orphaned accounts were found and cleaned up before go-live, including who decided which accounts to disable, and request the reconciliation report from the last migration. Certification evidence needs the same scrutiny: ask how campaign decisions, reviewer identities, timestamps and remediation actions are stored, how long they are retained, and how an auditor would re-run a sample. Request a sample evidence package from a previous engagement, with personal data removed, instead of accepting a verbal description.
Finally, ask how midPoint is paired with the SSO server, since midPoint is an identity management system and does not act as an OAuth, OpenID Connect or SAML server, so the partner must define which system authenticates users and which one provisions accounts. For upgrades, ask which midPoint long-term support release the design targets, when its support ends, and how the partner tests and schedules moves to the next release. Confirm the current support dates on the midPoint releases page and ask for written references to deployed systems that you can call.
How DeployOpen scopes and delivers identity governance selection and implementation
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 an identity governance requirements checklist, that means turning your HR sources, target systems, role model and review rules into a written scope before any build starts.
How we scope
- Inventory authoritative HR sources, target systems and their owners before agreeing any connector work.
- Document joiner, mover and leaver rules, role model assumptions and approval paths as a written scope.
- Agree certification campaign cadence, segregation of duties policies and required audit reports in the fixed-scope document.
How we build
- Configure midPoint connectors and provisioning rules against the agreed source and target systems in a non-production environment.
- Test joiner, mover and leaver scenarios, access request flows and certification campaigns with your named reviewers.
- Clean up orphaned accounts and validate role mappings before any production cutover, with results recorded for review.
How we hand over
- Deliver configuration, connector documentation, runbooks and test evidence as written artifacts your team keeps.
- Train administrators on campaign setup, approval handling and report generation so your staff can operate the platform.
- Record which controls and evidence your auditors can examine, and state clearly that independent auditors make the assessments.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after go-live, scoped separately in writing.
- Plan midPoint version upgrades and long-term support timing with your change process and maintenance windows.
- Confirm with your team which support tier, response terms and connector coverage you need before signing a quote.
