Open source identity governance for ISO 27001 access controls: what the auditor will ask
If you own the ISMS and you are preparing for certification, the question an assessor will put to you is simple: can you show that every account was created, reviewed and removed under policy? Identity governance is the system that produces that evidence for Annex A controls A.5.16 Identity management, A.5.18 Access rights and A.8.2 Privileged access rights. It does not certify anything. ISO does not certify organizations or tools, and accredited certification bodies assess the ISMS as a whole, including whether the identity processes you describe actually run as written. Your task is to make the tooling and its records fit that assessment.
The 2022 edition moved identity topics into the organizational controls theme of Annex A. A.5.16 asks you to manage the full life cycle of identities so that people and systems can be uniquely identified, and A.5.18 asks that access rights be provisioned, reviewed, modified and removed according to your access control policy. A.8.2 asks that privileged rights be restricted and managed so only authorized users, software components and services hold them. Read the wording of each control in the standard itself, then map each sentence of your own policy to a process and a record. ISO/IEC 27002:2022 gives the implementation guidance behind these controls and is the document most teams use to write their procedures.
Governance output is only as good as its inputs. If the HR system or the directory that feeds midPoint is incomplete or stale, the platform will faithfully automate the wrong access, and the auditor will find it in the first leaver sample. Before you commit to a design, confirm which system is authoritative for each identity type, how a termination or role change reaches that system, and who signs off each review campaign. Ask your implementation partner to show, for a sample of recent joiners, movers and leavers, the request, the approval, the change in the target system and the review decision that followed. Those four records, not the product screenshots, are what the certification body will sample.
Mapping ISO 27001 access controls to identity governance functions
This table compares each ISO/IEC 27001:2022 access control with what the identity governance function must do and how midPoint can be configured to produce that behavior. Read each row as a design checklist: the requirement sets the expectation, the function describes the operating behavior, and the midPoint column names the objects you would configure. The mapping is a readiness aid only, and the review frequency and approval thresholds are set by your own access control policy, not by the standard.
| Requirement | What the function must do | How to configure midPoint |
|---|---|---|
| A.5.16 Identity management (full identity life cycle, unique identification) | Create one identity per person from an authoritative HR source, enforce unique identifiers, and disable or remove identities when employment ends. Cover system and service accounts with a named owner. | Configure an HR source resource as the authoritative feed, use object templates for naming and uniqueness, and set lifecycle states for active, disabled and archived. Use the LDAP, Active Directory or SCIM2 connectors for target systems. |
| A.5.18 Access rights (provisioning, review, modification, removal) | Grant access only through the defined rules in the access control policy, review it at the frequency your policy sets, and remove or adjust it when a role or need changes. | Model access as business roles and application roles, assign them through assignment policies, and run certification campaigns with reviewers from managers or resource owners. Use scheduled reconciliation tasks to detect drift. |
| A.5.18 Removal on change of role (mover) | Recalculate access when a person changes department or job, remove access that no longer fits the new role, and keep a record of the change. | Drive role membership from HR attributes with mappings and conditions, so a change in organizational unit triggers role removal and addition. Confirm in a test environment that the mover path removes entitlements and does not only add them. |
| A.8.2 Privileged access rights (restricted allocation and use) | Limit privileged roles to authorized people, software components and services, require a documented approval before allocation, and review privileged assignments separately from standard access. | Create separate privileged roles with approval workflows in the request interface, set a shorter certification scope for privileged roles, and mark privileged resource accounts. Confirm with your PAM or secrets tooling how session use is controlled. |
| Access request and approval evidence | Keep a traceable record showing who requested access, who approved it, the justification and the date of grant. | Enable approval processes on role assignment and retain case and audit records in the midPoint repository. Confirm retention and export needs with your compliance lead before go-live. |
| Orphaned and excess accounts | Identify accounts with no owner, and entitlements not supported by a current role, before the first review, so that reviewers are not certifying noise. | Run reconciliation against each target resource with correlation rules and review the unmatched accounts report. Assign owners to shared and service accounts before the first campaign. |
Which open source platforms fit this function
ISO 27001 access evidence depends on three jobs: governing identities and access rights, authenticating people to systems, and controlling privileged credentials. The platforms below cover those jobs, and each card names the decision or check that comes before you commit.
midPoint for identity governance
midPoint is the governance layer that holds the joiner, mover and leaver rules, role model, access requests and review campaigns that produce evidence for A.5.16 and A.5.18. Its repository is licensed under EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum states there is no enterprise edition. Confirm which connectors your target systems need, since the integration catalog ranges from supported to experimental. It runs on PostgreSQL as its native repository database, so confirm your database hosting and backup standards early.
Keycloak for single sign-on
Keycloak handles authentication, single sign-on and OpenID Connect or SAML federation, which is the layer that enforces who can sign in and how. It is licensed under Apache-2.0 and is a Cloud Native Computing Foundation incubating project. midPoint does not implement the server side of these protocols, so you will need an SSO server alongside it. Confirm how account states in midPoint flow into Keycloak so a leaver loses sign-in promptly, and plan upgrades for a fast-moving release cadence.
authentik as an alternative
authentik is a self-hosted identity provider that can cover the same SSO role as Keycloak for many workforce scenarios. Its licensing is split: most code is under MIT, but the authentik/enterprise directory carries a separate enterprise license. Check which features your access control design depends on, and confirm whether they sit in the enterprise directory. Ask a partner to test the provisioning and deprovisioning path against your directory before you select it.
ZITADEL as an alternative
ZITADEL is an identity and access management platform under AGPL-3.0 that lists SSO, MFA, passkeys, OpenID Connect certification, SAML 2.0, SCIM and multi-tenancy. Its SCIM support can matter if you want to push account changes to downstream applications. Confirm that AGPL-3.0 obligations fit your distribution model, and verify how its user lifecycle events connect to your governance records, since the auditor will ask where the approval and removal decision was made.
OpenBao for privileged credentials
A.8.2 asks that privileged access rights are restricted and managed, and many of those rights are secrets, certificates and keys held by service accounts. OpenBao is licensed under MPL-2.0 and is hosted under the OpenSSF, and it can manage, store and distribute these credentials. Confirm how privileged accounts are approved in midPoint, then tie their secrets to the same owner and review cycle so no credential outlives the access that justified it.
Vault licensing as a consideration
HashiCorp Vault version 1.15.0 and later is licensed under the Business Source License 1.1 with IBM named as licensor, which is not an OSI-approved open source license. If your policy requires OSI-approved licenses for security controls, Vault may fall outside it even though it is widely deployed. Ask your legal and procurement teams to review the license text before you choose between Vault and OpenBao for the privileged credential layer.
Build, partner or SaaS for ISMS access evidence
An in-house build means the organization's own identity or platform engineers install midPoint, write the connectors, model roles and produce the certification reports. The software itself carries no license fee, since midPoint is published under the EUPL-1.2 with Apache 2.0 as a secondary license and Evolveum states it has no enterprise edition. The cost sits in staff time and skills: Java and PostgreSQL operations, identity data analysis and a team that can keep the deployment current.
- People: Engineers who understand provisioning logic, ConnId connectors and the ISO/IEC 27001:2022 Annex A controls the evidence must support.
- Connectors: Each target system, such as Active Directory, LDAP, Microsoft Entra ID or a SaaS application, needs build, test and change work when its API or schema changes.
- Maintenance: Upgrades follow midPoint's release cycle, so the team must plan against support end dates for each release line.
- Evidence: The team writes and retains the review campaign records, the approvals and the exception logic that an auditor will sample.
- Left to the organization: Incident response on the IGA platform, backup and recovery, and any gap between what the ISMS documents and what midPoint actually enforces.
Before choosing this path, confirm that the team can staff connector work and upgrades for the life of the ISMS, not only the first deployment.
An implementation partner plans, deploys, integrates and documents midPoint inside the client's own infrastructure, while the organization keeps ownership of the data, the systems and the decisions. DeployOpen works this way: fixed-scope engagements are agreed in writing, and ongoing support and upgrades are available as retainers. The organization pays for defined deliverables and, if it chooses, for recurring support, rather than for a per-user license.
- Scope: Connector build for named target systems, role modeling, a defined certification campaign, and the runbooks an auditor will read.
- Recurring cost: Support, upgrades and connector changes, which can be contracted as a retainer or on demand.
- Vendor support option: Evolveum offers Product Support and Platform Subscriptions. Confirm with the partner which subscription, if any, applies to your deployment.
- Knowledge transfer: Ask that the handover includes the configuration, the evidence procedures and the upgrade plan, so the organization can operate without the partner.
- Left to the organization: Accountability for the ISMS, the control decisions and the audit. A partner prepares evidence but does not issue audit reports or certifications.
Ask for the written scope, the named connectors, the deliverables for evidence, and how upgrades will be planned against midPoint's support end dates.
A commercial identity governance product or identity suite bundles lifecycle management, access requests, certifications and reporting, usually under a subscription priced per user or per module. Vendor-managed hosting and prebuilt connectors can shorten early setup, but the organization accepts the vendor's data location, release schedule and feature set. Evidence still has to match the organization's own policies, so the ISMS owner remains accountable for the result.
- Licensing: Recurring subscription fees that scale with identity count or modules. Ask how fees change when headcount, contractors or connected systems grow.
- Connectors: Confirm which target systems are native, which need custom work and who builds them.
- Data residency: Check where identity data is stored and processed, and who can access it, against the organization's own requirements.
- Exit terms: Ask how roles, certification history and audit records can be exported if the contract ends.
- Left to the organization: Policy design, review ownership, decision quality and the proof that the vendor's reports reflect the real access state.
Request the vendor's control evidence and a sample certification report, then test whether an auditor can re-perform the review from those exports.
Evidence auditors ask for and which component produces it
This table lists the records an ISO 27001 auditor typically samples for access controls, what each one shows, and which component produces it. Read each row as a question the auditor will ask and the record that answers it. Auditors sample and re-perform from these records, so the main takeaway is that every row needs a retained, time-stamped source that can be reproduced, not a screenshot assembled after the fact.
| Evidence item | What it shows | Component that produces it |
|---|---|---|
| Joiner approval record | Who requested access, who approved it, and when, tied to the role or entitlement granted | midPoint access request and approval records, retained with the request history |
| HR-to-directory provisioning log | That an account was created from the authoritative HR source and which entitlements followed | midPoint audit records plus ConnId connector logs for each target directory |
| Role definitions and their owners | The approved content of each role, the entitlements it carries and the named business owner | midPoint role objects with owner assignments and change history |
| Certification campaign results | Scope of each review, reviewer identity, each keep or revoke decision and the remediation applied | midPoint certification campaign records and decision history |
| Removal and leaver timestamps | When access was disabled or removed after a role change or departure, and whether the target system confirmed it | midPoint audit records for leaver processing, connector logs confirming target removal |
| Privileged role assignment lists | Which accounts hold administrative or privileged roles at a point in time | midPoint role assignment reports, Keycloak admin events for realm and client administrator changes |
| Privileged role change history | Who granted or revoked privileged rights, when, and under which approval | midPoint audit trail for assignments, Keycloak admin events for administrative changes in the SSO layer |
| Administrator activity in the SSO server | Changes to users, clients, roles and realm settings made through the Keycloak admin console or API | Keycloak admin events, which must be enabled and forwarded to retained log storage (confirm configuration in your environment) |
How the rollout produces evidence from the first campaign
The sequence turns a scoped access policy and a reconciled identity population into a first certification campaign whose decisions, removals and logs form the evidence an ISO 27001 auditor samples. Each step closes with a check the team can show to an auditor.
Confirm scope and the ISMS access policy
The team agrees which systems, user populations and privileged accounts fall inside the ISMS scope, and which topic-specific access control policy governs them. The policy states who approves access, how often access is reviewed and what triggers removal. DeployOpen documents this in writing before configuration starts. Done means the policy and scope statement are approved by the control owner and the in-scope system list is signed off.
Clean up orphaned accounts and reconcile against HR
Before any automation runs, the team pulls account lists from each target system and matches them to the authoritative HR record. Accounts with no owner, shared accounts, and accounts for people who have left are flagged for decision. Owners of unclear accounts are identified with the business. Done means every account in scope has a named owner or a documented disposition, and the reconciliation report is retained as evidence.
Model roles from the existing access
Engineers map current entitlements into a role model that business owners can read, and separate standard roles from privileged functions such as administrator rights on servers, databases or cloud tenants. Privileged roles carry explicit approval rules, which supports the control on privileged access rights. Done means each role has a documented owner, a purpose and an approval path, and the privileged roles are listed separately for review.
Connect authoritative sources and target systems
midPoint is configured with the HR source as the authoritative input for joiners, movers and leavers, and with connectors to the target systems, such as directories and SaaS applications, through the ConnId framework. Each connector is tested in a non-production copy where possible, and its supported status is confirmed against the connector catalog. Done means test provisioning, role change and disablement each produce the expected change in the target system and a log entry in midPoint.
Run the first certification campaign
The first campaign sends each reviewer the list of accounts and entitlements they own, with the role and the last known use where the source provides it. Reviewers approve, revoke or flag each item, and revocations are executed through midPoint rather than by hand. Done means every item in the campaign has a recorded decision, a reviewer identity, a timestamp and a follow-up action for each revocation.
Operate joiner, mover and leaver flows with monitoring
The team switches the HR-driven joiner, mover and leaver flows from test to production, with alerts on failed provisioning, stalled approvals and accounts that fall outside the reconciled population. Operations staff review these alerts on a set cadence defined in the policy. Done means a sample of new joiners, role changes and leavers shows the access required by the role and removal within the policy's timeframe, with logs retained.
Feed the internal audit cycle and certification body
Internal audit samples the campaign records, the reconciliation report, the role documentation and the leaver logs, and raises findings against the policy. Findings feed the next campaign and the change log. Certification bodies audit accredited ISMS certificates under a three-year cycle with at least one audit in every calendar year, so the evidence must already exist before that audit. Done means internal audit has re-performed a sample and the open findings have owners.
What tooling alone does not satisfy
An identity governance platform records and enforces decisions, but it does not make them. The cards below name the gaps that remain after midPoint is running, and the owner who must close each one before an ISO 27001 certification body samples the evidence.
Access control policy and risk decisions
midPoint applies rules, but it cannot decide which roles may exist, which risks are accepted or who may approve privileged access. Those decisions belong to the information security owner and must be written into the topic-specific access control policy that A.5.18 refers to. Check that every rule in midPoint traces to a signed policy clause, with a named approver and a review date. An auditor will ask who approved the rule, not whether the rule runs.
Unreviewed role models
Roles are often built by copying existing access, so a role can carry rights nobody with business authority has ever confirmed. The business role owner and the application owner must sign off each role's entitlements before it drives provisioning. Check for roles with no owner, roles granting more than their description states, and roles unchanged since their first design. Unreviewed roles turn automated provisioning into automated over-provisioning.
Unowned target systems
Every system that accepts an account needs a named owner who answers for its accounts, its entitlements and its removal. Systems reached through a connector are easy to forget once the connector works. Ask the platform owner to confirm, for each connected system, who approves access, who receives review tasks and what happens when that person leaves. A target with no owner is a place where removal on change of role silently fails.
Manual systems without connectors
Some applications have no connector, so access is granted by ticket and removed by hand. These systems fall outside automated joiner, mover and leaver processing, yet they still fall within A.5.16 and A.5.18. The application owner and the identity team should agree a documented manual procedure, with a ticket for each grant and removal and a periodic check against an exported account list. Record every manual system in the scope statement so the gap is visible rather than hidden.
Missing review and decision records
A certification campaign produces evidence only if its reviewers, decisions, justifications and completion dates are kept. The campaign owner must retain the outcome, show that revocations were carried out in the target system and record reviews that were not completed and how they were escalated. Check whether the reviewer list matches the current manager hierarchy and whether overdue reviews were followed up. Missing records are the most common reason an existing control cannot be re-performed.
Certification by a certification body
ISO does not certify organizations, and a DeployOpen implementation does not produce a certificate. An accredited certification body must audit the management system, the scope and the evidence before a certificate is issued. The ISMS owner should confirm the certification body is accredited, agree the audit scope in advance and plan for the cycle of audits that follows. Treat the implementation as readiness work for that audit, not as the audit itself.
How long and how much effort does ISO 27001 access identity governance take?
What drives the effort and cost of ISO 27001 identity governance?
The main drivers are the number of target systems, the number of connectors those systems need, how clean the source data is, and how much role cleanup is required before go-live. Each target system adds connector configuration, testing and reconciliation work. Each messy role model adds analysis and sign-off with application owners. Because midPoint is open source with no license fee, the spend is mostly people time and infrastructure: connector and role-modeling work, data cleanup, hosting, and ongoing support. Ask a partner to break the quote into these components and to state which items are one-time and which recur, such as upgrades and support retainers.
Can our internal team implement ISO 27001 access governance alone?
A capable internal team can do it, but the question is capacity and skills, not licensing. The work combines Java-based platform administration, PostgreSQL operations, connector configuration against Active Directory, LDAP or SaaS APIs, and role design with business owners. midPoint runs on Linux in a virtual machine or from Docker images, and multi-node deployments need a sticky load balancer and a shared database, which your operations team must support. Evolveum offers support subscriptions and professional services, so teams often combine internal ownership with external help for connectors and design. Assess your team against each component before deciding.
How long before we can run the first access certification campaign?
The honest answer depends on the scope agreed in writing, and no duration can be given without it. Time to a first campaign is driven by how many authoritative sources and target systems must be connected, how much entitlement data must be reconciled, and whether reviewers and owners are identified before the campaign starts. Ask any implementation partner to show the milestones in the written scope, including connector testing, reconciliation of orphaned accounts and a pilot campaign before the first production review. Confirm the schedule with the partner and with your own change calendar, since freezes and audit dates often set the real constraint.
What do HR and application owners need to provide for provisioning?
HR provides the authoritative joiner, mover and leaver events, and application owners provide the rules for what access each role should hold and who approves exceptions. In practice, HR must maintain accurate employment status and role data, because ISO/IEC 27001 control A.5.16 depends on identities being uniquely managed through their full life cycle. Application owners must confirm which entitlements exist in their systems, which are still needed, and who reviews them. Ask the partner to name the decision-makers, the turnaround expected from each group, and how disagreements about role definitions are escalated and recorded.
Does the 2022 ISO 27001 transition affect an ISMS built on the 2013 edition?
Yes, the control references change, and the transition deadline has already passed. IAF MD 26:2023 required all certifications to ISO/IEC 27001:2013 to expire or be withdrawn by 31 October 2025, so the certified scheme is the 2022 edition. The access controls map as follows: A.9.2.1 User registration and de-registration carries forward into A.5.16, and A.5.18 merges three 2013 controls covering provisioning, review and removal of access rights. Privileged access moves to A.8.2, which traces to A.9.2.3 in the 2013 edition. Update your statement of applicability and evidence index to the new control IDs, and confirm the mapping with your certification body.
How long must access governance evidence be kept for the certification cycle?
The retention period is set by your own policy and your certification body's requirements, not by a figure this page can supply. What is known is that a management system certification cycle lasts three years under ISO/IEC 17021-1, with at least one surveillance or recertification audit in every calendar year. Auditors sample evidence across that cycle, so records such as provisioning approvals, leaver removal tickets, review decisions and the midPoint audit trail must remain retrievable for the whole period. Ask your partner how evidence is archived, how long logs are retained, and how you will demonstrate decisions made in earlier cycles.
Which parts of the identity governance work are one-time and which recur?
Role modeling, connector build-out, data cleanup and the first certification campaign are one-time investments, although role definitions and connectors will need maintenance as systems change. Recurring work includes running periodic access reviews, processing joiners, movers and leavers, applying midPoint upgrades, and keeping database and infrastructure patched. midPoint's long-term support releases give a predictable upgrade path: the 4.8 Curie release is supported until 17 October 2028, while feature releases such as 4.10 have shorter windows. Ask any partner to show which items sit in the initial fixed scope and which belong in a support retainer.
What to ask an implementation partner before signing
Start with how roles will be modeled. Ask the partner to show how they will derive candidate roles from the access that already exists in your directories and target systems, how many roles they expect to build, and who in your organization signs off each role definition. A partner who cannot explain this step is likely to hand you a role catalog that auditors will challenge when they test A.5.18 access rights against the approved policy. Ask which midPoint connectors they have already deployed in production, including LDAP, Active Directory, Microsoft Entra ID and SCIM2, and which systems would need a custom or community connector that they would need to test before go-live.
Next, ask how orphaned and excess accounts will be found and cleaned up before the first provisioning run. The answer should cover reconciliation reports, the owner of each account that has no matching HR record, and the written approval trail for every removal. Ask how reviews will be evidenced: which certification campaigns they will configure, how decisions are recorded in midPoint, how reviewers are reminded and escalated, and what a re-performable export looks like for the auditor testing A.5.16 and A.8.2 privileged access rights. Confirm who owns the privileged role list and how that list is reviewed.
Ask how midPoint will pair with your single sign-on server. Evolveum states that midPoint does not implement the server side of OAuth2, OpenID Connect or SAML, so the partner should name the SSO product, explain how group or role claims reach it, and say who maintains that integration. Finally, ask how long-term support upgrades are planned. The midPoint releases page lists 4.8 as the long-term support release supported until October 17, 2028, so confirm which line the partner will deploy, how they will test upgrades, and how they will handle the Java version each release needs. Make sure the written agreement is fixed-scope, with deliverables, acceptance criteria and timelines agreed in writing before work starts, and that retainers for upgrades and support are priced separately.
How DeployOpen scopes, delivers and supports ISO 27001 identity governance
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including identity governance for ISO 27001 access controls. The work starts with a written scope that defines which controls, systems and evidence the engagement covers, and DeployOpen prepares the access controls and records for assessment without issuing any audit report or certification.
How we scope
- Agree in writing which systems, authoritative sources and target applications midPoint will govern for A.5.16 and A.5.18.
- Map the current joiner, mover and leaver steps, approval routes and review owners before any build begins.
- Confirm with your certification body which evidence records and sampling populations it expects for the access control audit.
How we build
- Configure midPoint connectors, role model and provisioning rules in your own cloud accounts, data centers or air-gapped network.
- Test removal on change of role and leaver scenarios in a non-production environment before cutover.
- Document access review campaigns, privileged access rights assignments and exception handling as operating procedures.
How we hand over
- Deliver configuration documentation, runbooks and test results for each control in the agreed scope.
- Train your identity, security and compliance staff to run review cycles and produce the decision records themselves.
- Provide a clear list of open items, owners and the evidence your team still needs to collect before assessment.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, midPoint upgrades and continuous testing are available as retainers, with terms set in each agreement.
- Confirm the support model, upgrade plan and response terms in the written scope rather than assuming them.
