What SOC 2 logical access controls ask of identity governance
If you are a SaaS or service organization preparing for a SOC 2 Type 1 or Type 2 examination, identity governance serves two common criteria in particular: CC6.2, which covers registering and authorizing users before credentials are issued and removing those credentials once access is no longer authorized, and CC6.3, which covers granting, changing and removing access based on roles, responsibilities or system design, with least privilege and segregation of duties in view. The auditor does not take your word for either. They select a population of users and access changes from system records, then sample from it and trace each sample back to an approval, a role assignment or a removal. Your identity governance design should therefore produce records that can be pulled as complete populations, not reconstructed from memory or email.
DeployOpen prepares the controls and the evidence, but it does not issue the SOC 2 report. That opinion comes from an independent CPA firm. In this design, midPoint is the identity governance and administration layer: it holds the joiner, mover and leaver logic, the requests and approvals, and the history of assignments and removals, and it pushes accounts to target systems through connectors. It is not your single sign-on server. midPoint does not implement the server side of OAuth 2.0, OpenID Connect or SAML, so authentication for your applications sits in a separate SSO product such as Keycloak, and the two must be integrated so that a removal in midPoint actually ends sessions and credentials in the systems that matter. Confirm with your auditor early which systems are in scope, because each in-scope system needs a path from midPoint to its account store.
Mapping CC6.2 and CC6.3 to identity governance configuration
This table maps each identity-related SOC 2 requirement under CC6.2 and CC6.3 to what the function must do and how to configure midPoint to produce it. Read each row as a control to design, then check the evidence column against what your auditor will ask to see. The main takeaway is that the approval, removal and review settings you configure in midPoint are the records the auditor will sample, so they must be designed before the first examination period begins.
| Requirement | What the function must do | How to configure midPoint |
|---|---|---|
| CC6.2: Register and authorize users before credentials issue | Record who requested each account or entitlement, who approved it and when, before any credential is issued or access is granted. | Use request and approval workflows for joiners and access requests so no account is created until the approver decision is stored. Restrict direct assignment to administrators and log exceptions. |
| CC6.2: Remove credentials when access ends | Disable or remove credentials once access is no longer authorized, including leavers, contractors whose term has ended and transferred staff. | Drive leaver rules from the authoritative HR source through a connector, then disable accounts in each target system through its connector. Confirm the target-side disable succeeded and keep the task result as evidence. |
| CC6.2: Review the appropriateness of credentials | Periodically confirm that existing accounts and credentials still match a valid business need, and act on the findings. | Run certification campaigns over accounts and entitlements in scope, route decisions to managers or system owners, and record the outcome and remediation of each revoked item. |
| CC6.3: Grant, change and remove access by role | Grant, modify and withdraw access to systems and data based on defined roles, responsibilities or system design. | Build a role model with business roles that bundle application roles. Assign roles through policy from job attributes, and recompute assignments automatically when a mover event changes those attributes. |
| CC6.3: Least privilege and segregation of duties | Limit each role to the access it needs and prevent combinations of access that one person should not hold. | Define segregation of duties rules that flag conflicting role pairs at request time and in certifications. Document each exception with an approver and an expiry date where the business allows one. |
| CC6.3: Review roles and access rules | Review the role definitions, assignment rules and access structures themselves, not only individual accounts, and record the changes made. | Schedule role and rule reviews as certification campaigns targeting role owners. Keep change history for role definitions and assignment policies so the state of the model can be shown for any past date. |
Which open-source platforms fit SOC 2 identity governance
SOC 2 logical access controls depend on two records: who was authorized to hold access, and what they can actually reach. The platforms below split those jobs, with a governance layer that holds the access record and authentication layers that enforce sign-in, plus a secrets store for the credentials that sit outside human accounts.
midPoint as the governance record
midPoint is the identity governance and administration layer that records approvals, role assignments and removals across connected systems. Its repository is licensed under EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum states there is no enterprise edition. The 4.8 Curie long-term support release is supported until October 17, 2028, which matters for an audit period. Check which connectors your target systems need, since some are community or experimental in status.
Keycloak as the SSO layer
Keycloak handles authentication and token issuance over OpenID Connect, OAuth 2.0 and SAML 2.0, and federates LDAP and Active Directory users. It is licensed under Apache-2.0 and is a Cloud Native Computing Foundation incubating project. Confirm which database and high availability design you will run, because the supported designs require a synchronously replicated database. Plan upgrades deliberately, since the Operator documentation recommends manual approval mode.
authentik as an SSO alternative
authentik is licensed under MIT except the authentik/enterprise directory, which carries a separate enterprise license. Teams that want a lighter administration model and a permissive core license can evaluate it against Keycloak. Confirm which features your auditors expect, such as access review logs and session records, sit in the MIT core rather than the enterprise directory. Verify the license terms for the exact modules you deploy before you commit.
ZITADEL as an SSO alternative
ZITADEL is an identity and access management platform licensed under AGPL-3.0. Its README lists SSO, MFA, passkeys, OpenID Connect certification, SAML 2.0, SCIM and multi-tenancy. The AGPL-3.0 license has network copyleft obligations that legal teams should review before offering it to customers or running it as a shared service. Confirm the SCIM support fits your provisioning pattern with midPoint.
OpenBao for secrets beside access records
Service accounts, API keys, database credentials and certificates are access too, and SOC 2 testers ask how they are issued and retired. OpenBao manages, stores and distributes secrets, certificates and keys under MPL-2.0 and is hosted under the OpenSSF. Keep its issuance and revocation logs alongside midPoint records so each non-human credential has an owner and a removal trail. Infisical, licensed under MIT except its ee directories, is an alternative to evaluate against the same requirements.
Configuring the system boundary the auditor will describe
The system description is the first document an auditor reads, and management writes it against the AICPA 2018 description criteria before any testing begins. For identity governance, the boundary must name every system that can grant, change or remove access to in-scope systems: the authoritative HR source that triggers joiner, mover and leaver events, the midPoint instance and its database, each target connector, and the login path that users take into the application. If a system is outside the boundary, it should still be listed as a carve-out with the reason, because auditors test what management says is in scope. Confirm with the HR team which system is the source of truth for employment status and whether contractors enter through a separate feed.
Each target needs a connector decision before the boundary is final. midPoint documents LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID through the Graph API and SCIM2 connectors, and its connector catalog marks other connectors as supported, community or experimental. A community or experimental connector can still be in scope, but the system description and your control design should say so and name the owner who maintains it. Ask the implementation partner for a written list of target systems with the connector name, its published status, the version tested and the account types it manages, including database accounts that are created outside the directory.
Keycloak is the login path only if the description says so, and midPoint is not that server. Evolveum states that midPoint does not implement the server side of OAuth2, OpenID Connect or SAML, so the description should show Keycloak issuing authentication for applications while midPoint holds the account and entitlement record. For production, midPoint recommends Java 21 for version 4.10 and older and Java 25 for 4.11 and later, runs against PostgreSQL on a separate database server, and in multi-node deployments sits behind a sticky HTTP load balancer with a shared central database. Record the exact midPoint and Java versions, since the auditor will test the environment as described during the period.
Evidence auditors ask for and which component produces it
This table maps the evidence an auditor typically requests for CC6.2 and CC6.3 testing to the component that produces it and what the team should export and retain. The auditor performs the testing; the table shows where the population, samples and decisions come from. Read each row as a question the auditor will ask and confirm the exact sample design with your auditor before the examination period starts.
| Evidence item | What the auditor tests | Producing component | What to export and retain |
|---|---|---|---|
| Account and entitlement population at period start and end | Completeness of the population used for sampling, and whether accounts outside the system of record exist | midPoint repository and connector reconciliation reports against target systems | Dated population extracts per target system, reconciliation output, and the query or report definition used |
| Provisioning and approval record for a sampled grant | That access was requested, approved by an authorized owner and granted before use (CC6.2, CC6.3) | midPoint request and approval workflow, with the audit trail of the granted assignment | Request record, approver identity, approval timestamp, assignment history and the target system change log |
| Removal record with dates for sampled leavers | That access was removed in a timely way after termination or role change, and no credentials remained usable | midPoint lifecycle state changes driven by the authoritative HR source, plus target system disable or delete events | HR termination event, midPoint status change with timestamp, and target system confirmation for each sampled account |
| Role definitions and change history | That roles reflect approved job functions, least privilege and segregation of duties, and that changes were approved | midPoint role and policy objects with versioned change records | Role catalog with owners, approval records for role changes, and exports of role membership at each review point |
| Periodic access review decisions and reviewer identity | That reviews occurred at the defined cadence, reviewers were appropriate, and removals were actioned | midPoint certification campaigns and their decision records | Campaign definition, reviewer list, decisions, remediation tickets and evidence that revoked access was removed |
| SSO and MFA authentication logs | That access to in-scope systems required authentication and MFA where the control requires it, and that failed and privileged logins are logged | Keycloak event logs and admin events, forwarded to the central log platform | Login, MFA and admin event exports for the period, retention settings, and log integrity controls as configured |
What identity governance tooling alone does not satisfy
Does a midPoint deployment alone satisfy SOC 2 logical access criteria?
No. midPoint can provision, record and report access, but SOC 2 is an examination of the whole control environment, so the tool only supports the controls around it. The auditor also looks for written policies, a named review owner, HR termination discipline, management's written assertions and a system description that matches what runs in production. Tooling produces records; the organization still has to define, operate and evidence the controls that use them.
What written policies and procedures does a SOC 2 auditor expect for access?
The organization needs written policies that state who may request access, who approves it, how roles are defined, how access changes are made and how credentials are removed. The procedures should describe the steps midPoint performs and the manual steps that remain, such as approving exceptions. Auditors compare what the document says with what the system does, so a policy that describes an unconfigured workflow will generate a finding. Confirm the exact wording and scope of these documents with your auditor before fieldwork begins.
Who owns access reviews and how often must they run?
A named owner must be accountable for each review, along with a documented cadence and a defined method for handling exceptions. The cadence is the organization's decision, based on its risk assessment and its commitments to customers, and it should be written down and then followed. Auditors test whether reviews happened as scheduled, whether reviewers had the right information and whether removals followed the decisions. A campaign that runs in midPoint but has no assigned owner will not satisfy this expectation.
Why do HR termination notices matter for midPoint leaver automation?
Automated removal is only as timely as the event that triggers it. If HR records a termination late, or contractors and vendors are never entered in the authoritative source, midPoint will not remove their access on time, however well the connectors are configured. CC6.2 expects credentials to be removed once access is no longer authorized, so the organization needs HR and contractor sponsor procedures that set a clear deadline for entering terminations. Ask your team to measure the gap between the effective date and the record date during testing.
What must management provide in writing alongside midPoint records?
Management provides a written description of the system and makes representations to the service auditor about its design and operation. Under the AICPA's 2018 description criteria, that description must cover the services, the infrastructure, the software, the people, the procedures and the data that support the system. An auditor relies on it as the baseline for testing, so any mismatch between the description and midPoint's actual configuration becomes an exception. Engineering and compliance should review the description together.
Which application roles live outside midPoint and still need control?
Many SaaS tools, internal applications and databases keep their own role tables, local accounts and admin flags that midPoint never sees. These entitlements fall into the population an auditor samples, so the organization must either bring them under midPoint through a connector or document a separate, equally rigorous review. Ask your engineers to inventory local accounts, shared administrator accounts and service accounts before the period starts. Connector coverage should be confirmed in your own environment, not assumed from the catalog.
How long must access evidence be kept for the examination period?
Evidence must be retained and available for the whole examination period, including provisioning approvals, review decisions, removal records and exports used as populations. Type 2 reports cover an operating period, so records from the start of that period must still be retrievable at the end. Plan retention in the midPoint database, log storage and ticketing system, and confirm the required period and format with your auditor. Gaps in retention often surface as missing samples rather than as failed controls.
Sequencing the work before the examination window
The sequence turns an unmanaged set of accounts into a defined population, a role model and a first review cycle that the examination period can test. Each step produces a record that the next step depends on, so the order matters more than the pace.
Scope the systems and the population
Agree with the auditor which systems, applications and infrastructure fall inside the system description, and which identity sources and target systems grant access to them. The client's IT and security leads list every account store and every application with local users, and name an owner for each. The step is done when the in-scope population is written down, signed off by the control owner and recorded as the baseline the examination will reference.
Clean up orphaned and excess accounts
Before midPoint takes over provisioning, compare accounts in each target system with people in the authoritative HR source. Accounts with no matching worker, accounts belonging to leavers, and shared or service accounts without an owner are flagged. The client decides whether each one is disabled, reassigned or kept with a documented exception. The step is done when every remaining account maps to a person or a named owner, and the cleanup log is saved as evidence.
Model roles from existing access
Map the entitlements people hold today to candidate roles, starting with the groups and permissions that cluster across teams. Business owners confirm which roles are valid, who may request them and who approves them, and the team records the rules that assign roles from HR attributes. Exceptions that cannot fit a role stay as explicit, time-limited assignments. The step is done when the role catalog, its owners and its assignment rules are approved and stored in midPoint, ready to support the CC6.3 role-based access design.
Connect the authoritative source and targets
Connect the HR system as the authoritative source for joiners, movers and leavers, then connect each target system through the ConnId connectors that match it. Test each connector in a non-production copy before any live write, and confirm that create, update and disable operations produce the expected results. The step is done when the connector test records show that a sample hire, transfer and departure each reached every target as designed, and the access request and approval flows are working.
Run a first certification campaign
Launch a baseline access review in which each manager or application owner certifies the access of their population against the approved roles. The client's reviewers decide keep, change or revoke for each entitlement, and the IGA team applies the revocations through midPoint. The step is done when the campaign closes with a completed decision record for every item, the revocations are confirmed in target systems, and the campaign report is retained as the first review evidence for the examination.
Operate the controls through the examination period
Run provisioning, removal, access requests and periodic certifications on the cadence the control design states, and keep the records each one creates. The client's control owner reviews exceptions, role changes and midPoint configuration changes through change management. The DeployOpen team supports patching, upgrades and connector maintenance under agreed terms. The step is done when the auditor can select any sample from the population and trace it to an approval, a request, a change and a removal record without manual reconstruction.
How much work does a SOC 2 identity governance implementation take?
What drives the cost of a SOC 2 identity governance implementation with midPoint?
The cost comes from people and work, not from a midPoint license, because Evolveum states that midPoint has no enterprise edition and every line of its code is open source. The main cost components are connector work for each system that holds access, role modeling, cleanup of existing accounts and entitlements, infrastructure to run midPoint and its PostgreSQL database, and ongoing support. Connector count and the number of applications with unclear ownership usually move the total the most. Evolveum sells Product Support and Platform Subscriptions, and its public support page lists no prices, so ask Evolveum for current terms directly. Ask any implementation partner for a quote that lists each component separately and states what is one-time and what recurs.
How long does it take to be audit-ready for a SOC 2 Type 1 or Type 2 report?
The answer depends on whether you need a Type 1 or a Type 2 report, and the criteria do not set a duration for either. A Type 1 report covers the system description and the design of controls as of one date, so the identity controls must be designed, configured and in place before that date. A Type 2 report adds an opinion on operating effectiveness over a period, so the provisioning, removal and review controls must run for the whole observation window and leave records throughout it. Confirm the observation period and the auditor's sample expectations with your SOC 2 auditor before you set the project plan, and ask any partner to tie milestones to that period.
What does our team need to provide before an identity governance project starts?
The project depends on three groups of input that only your organization can supply. HR data is the authoritative source for joiners, movers and leavers, so you need a named owner, a data extract or feed, and agreed rules for employment status changes. Application owners must confirm which roles, entitlements and groups exist in each target system and who approves access to them. Approvers, usually managers and data owners, must agree on who signs off on requests and certification reviews. Without these people available and decisions made in writing, connector and role work will stall, so agree on named contacts and a decision timeline in the written scope.
Can an internal team implement midPoint for SOC 2 without an outside partner?
An internal team can do it if it has people with midPoint, Java and PostgreSQL skills, connector experience for each target system, and time to model roles and clean up existing access. Evolveum publishes system requirements, a connector catalog and release schedules, and Java and PostgreSQL versions are listed in its documentation, so the skills are learnable. The risks are usually a small team carrying the project on top of daily duties, undocumented application access, and a long gap between go-live and the first evidence the auditor will test. Decide early whether your team will own operations after go-live, and compare that choice against a written partner scope before committing.
Does midPoint alone make an organization SOC 2 compliant?
No. midPoint is a tool that can produce access records, but SOC 2 is an examination of your whole system, its controls and their operation, and a CPA firm issues the report. Common criteria CC6.2 and CC6.3 concern registering and authorizing users, removing access and assigning access by role with least privilege and segregation of duties, and those controls also depend on policies, approval practices, reviews and the people who run them. Management also prepares the system description and must make written representations to the auditor. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications, so the auditor's conclusion is independent of any implementation work.
How do we get an accurate quote for a SOC 2 identity governance implementation?
Ask for a quote built from a written scope, because DeployOpen does not publish a price list and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Prepare a list of authoritative sources, each target system with its owner and connector need, the number of identities in scope, your role model status, and the SOC 2 report type and period you are targeting. Ask the provider to separate one-time implementation work from recurring support, upgrades and testing, which DeployOpen offers as retainers. Compare any quote against the scope it covers, not against the headline total.
What should a SOC 2 identity governance scope include before work starts?
A useful scope names the systems and connectors in scope, the joiner, mover and leaver rules, the access request and approval flows, the certification campaigns and their cadence, and the evidence each control will produce. It should also say how orphaned accounts will be cleaned up before go-live, which midPoint version and database will be deployed, and who operates the platform afterward. Ask for the scope to state which SOC 2 criteria it supports, and confirm with your auditor that the planned evidence matches what they will sample. Anything not written into the scope is a candidate for change requests later, so review the boundary carefully.
Primary sources for the criteria and the platform
Start with the criteria themselves. The AICPA 2017 Trust Services Criteria, in the version with revised points of focus published in 2022, define what an auditor tests under CC6.2 and CC6.3. Read CC6.2 and CC6.3 alongside their points of focus, and remember that the points of focus are characteristics that help you design and evaluate controls, not separate requirements. The AICPA's own SOC 2 pages, linked from the AICPA SOC 2 overview, explain how a Type 1 report (design as of a date) differs from a Type 2 report (operating effectiveness over a period). Confirm with your auditor which version of the criteria and the description criteria they will apply to your engagement before you map any control to them.
Next, confirm what the platform can and cannot evidence. midPoint is an identity governance and administration system, and Evolveum states that it does not implement the server side of OAuth2, OpenID Connect or SAML. Your CC6.2 registration and authorization records will therefore come from midPoint only for the parts it manages, while credential issuance and sign-in may sit in an SSO server. Review the midPoint repository and the midPoint releases page to choose a long-term support line that your audit period will not outlast, and check the support end dates there before you commit. Note that 4.8 is the long-term support release with support until 17 October 2028.
Finally, size the hosting before the audit population is pulled. The midPoint system requirements set out the supported Java versions for each release line, the PostgreSQL repository database (ideally on a separate server), and the multi-node pattern with a sticky load balancer and shared database. Ask your implementation partner to document the chosen Java and PostgreSQL versions, the node count and the backup and restore procedure in the system description, because an auditor will compare those statements with what runs in production during the period.
How DeployOpen scopes and delivers SOC 2 access controls
The sequence turns SOC 2 access expectations for CC6.2 and CC6.3 into a written scope, a midPoint and Keycloak build inside the client's environment, and an evidence set the client's auditor can test, with DeployOpen preparing that evidence but not issuing any audit report.
Agree a fixed scope in writing
DeployOpen and the client agree in writing which systems, user populations, authoritative sources and SOC 2 categories are in scope, and which parts of CC6.2 and CC6.3 the platform will support. The client's SOC 2 auditor should review the draft scope early, because the auditor decides what evidence is sufficient. The step is done when the signed scope lists in-scope applications, identity sources, deliverables and exclusions, and the client confirms the system description boundary it will give the auditor.
Map controls to identity processes and evidence
Together, the client's control owners and DeployOpen map each CC6.2 and CC6.3 point of focus to a concrete process: who requests access, who approves it, how credentials are issued, how changes and removals happen, and which role model governs access. Each control gets a named owner, a frequency the client sets, and a list of records midPoint or Keycloak must hold. The output is a control matrix that the client's management can compare with its own system description before any build starts.
Build midPoint and Keycloak in the client's infrastructure
DeployOpen installs midPoint for lifecycle and access governance and Keycloak for authentication and single sign-on, inside the client's cloud accounts, data centers or private network. Work covers PostgreSQL, the midPoint connectors for the agreed target systems, role definitions, approval flows and the Keycloak realm and client configuration. The step closes when test joiner, mover and leaver cases run end to end in a non-production environment and the results are recorded.
Clean up the population before go-live
Before production, DeployOpen reconciles accounts in each target system against the authoritative source, flags orphaned accounts and excess entitlements, and agrees with the client which accounts are removed, re-linked or formally justified. This matters because CC6.2 expects credentials to be removed when access is no longer authorized, and an auditor will sample from the full population. The step closes with a reconciliation report signed off by the client's system owners.
Define and test the evidence export procedures
DeployOpen documents how the client exports the population of users and entitlements, the request and approval records, role assignments, certification decisions and removal events from midPoint and Keycloak, and how exports are hashed, stored and retained. The client's auditor should be able to re-run the export and get the same result. The step closes when a test export is reproduced by someone other than the person who built it and the procedure is handed over as a runbook.
Run a pre-examination readiness review
Before the examination window, DeployOpen and the client review the control matrix, the evidence exports and a sample of recent joiner, mover and leaver events against the agreed control descriptions. Gaps are logged with owners and fixed or accepted by management. DeployOpen prepares this evidence and does not issue audit reports, attestations or certifications, and the independent service auditor decides what it accepts. The step closes with a written readiness summary and a gap register.
Provide optional retainer support for upgrades
After handover, the client may keep DeployOpen on a retainer for upgrades, monitoring, connector maintenance and evidence refreshes. Keycloak's project plans four minor releases a year, and its Operator documentation strongly recommends manual approval mode for operator updates, so upgrade planning and testing need a defined owner. midPoint's 4.8 Curie release is supported until October 17, 2028, which shapes when the client plans its next upgrade. The retainer scope, service levels and fees are set in a separate written agreement, and the step closes when the client has an upgrade calendar and a named support contact.
