midPoint for SOX user access reviews

How midPoint supports SOX user access reviews, and what it leaves to you

midPoint can run the campaign, decision and remediation mechanics of a SOX user access review, while management still decides scope, reviewers and the ICFR conclusion. Its access certification feature lets your team define a campaign that names the objects to certify, the check to perform, who decides and the deadline. When the campaign closes, the recorded decisions move into a remediation step, which is where revoked access is removed from the target system. Management remains accountable for which financially relevant systems are in scope, who reviews them, and whether the control operated effectively enough to support the evaluation under Section 404 of the Sarbanes-Oxley Act.

The parts midPoint helps with are the mechanical ones an audit team tests: building the review population from identity data it holds, routing certification items to reviewers, recording each decision with the reviewer and timestamp, and applying the outcome through connectors. Those records form the evidence an auditor samples, including the campaign definition, reviewer assignments, decisions and remediation results. Before you rely on it, check in the Evolveum connector catalog whether the connector for each in-scope system supports the removal actions your revocation process needs, and confirm the support status of that connector for your midPoint version.

Several decisions stay with your organization. Scope is a risk judgment about which applications, roles and entitlements affect financial reporting. SEC Release 33-8810 says management evaluates only the IT general controls needed for the proper and consistent operation of other controls that address financial reporting risks, so campaign scope should trace back to that mapping. Reviewer selection and review criteria are also management decisions. AS 2201 asks whether the person performing a control has the necessary authority and competence, so reviewers need documented accountability for the systems they approve. The ICFR conclusion, and any evaluation of deficiencies, belongs to management.

The external auditor tests the control under AS 2201 and assesses IT risks under AS 2110, including privileges beyond job duties that break segregation of duties and access that persists after a person leaves. midPoint does not issue an audit report or attestation, and it does not decide whether the control is effective. Ask your auditor which populations, periods and samples they will test, whether they expect reports generated by the system, and how they want reviewer sign-off evidenced. Agree that evidence list in writing before the first campaign runs.

Confirm your filer status with counsel or your audit committee, since the auditor attestation under Section 404(b) depends on it. Also bring midPoint itself into scope. Administrative access to the platform, its logs, its configuration changes and its database access are IT general control areas the auditor may test in their own right. Decide who owns those controls before the review cycle starts, so the campaign evidence is not the only record of how access was approved and changed.

Which SOX access review requirements midPoint maps to, and how

This table maps five SOX access review requirements to what midPoint campaigns, reviewers, decisions, remediation and connector deprovisioning provide, along with the configuration each one needs. Read each row as a contribution to the control: midPoint produces records and enforces decisions, while management and the external auditor determine whether the control is effective. The main takeaway is that configuration choices made before the first campaign determine what evidence exists when the auditor tests it.

Requirement	What midPoint provides	Configuration needed
SOX 404 and Rule 13a-15(c) management assessment	Campaigns produce recorded reviewer decisions and remediation records that management can use as assessment evidence.	Define the review as a documented control with an owner, frequency, scope and expected outcome.
Release 33-8810: access to programs and data	Campaigns can cover accounts and role assignments on in-scope financially relevant systems reached through connectors.	Connector coverage for each in-scope system, a current system inventory and agreed object scope for each campaign.
AS 2110 B4: segregation of duties	Reviewers see each user's assigned roles and entitlements, which supports review of conflicting access. Conflict detection depends on configured rules.	Agree a segregation-of-duties rule set with the control owner and confirm how your midPoint version enforces it.
AS 2110 B4: access that persists after termination	Lifecycle changes from the HR source and certification remediation can remove access through connector deprovisioning.	HR feed mapping for leavers, tested connector removal actions and a periodic check for accounts left on target systems.
AS 2201 paragraph 44: control operation and performer authority	Campaign records show who decided, when and on what basis, which supports testing of each reviewer's authority.	Reviewer assignment tied to documented system ownership, approved delegation rules and a stated competence basis for reviewers.
COSO 2013 Principle 11: general control activities over technology	Configurable campaign, approval and remediation steps can be documented as technology-based general controls.	A control narrative linking campaigns, decisions and remediation to Principle 11 and to the team that operates them.

How a SOX access review campaign runs in midPoint

A midPoint access certification campaign is the unit of evidence for a periodic SOX access review. Before launch, the design team defines the objects to certify, what the reviewer checks, who decides, and by when. For a financially relevant application, the objects are typically the role or resource assignments that grant access to that application, grouped by application owner or business process. Confirm in your version which object types the campaign definition accepts and how it filters scope, because the scope recorded in the campaign is what an auditor will compare with the population you say you reviewed. Write the review period, the reviewer, the close date, and the population into the control description so the configuration and the written control match.

The decision-maker is the most important design choice for the control's authority and competence. AS 2201 paragraph 44 asks whether the person performing a control has the necessary authority and competence, so the reviewer selection needs a documented rationale. Confirm whether midPoint can route each review to an application owner, a line manager, or a designated approver for each target resource, and how a reviewer who has left the organization is reassigned. Also confirm which responses the reviewer can give, whether a justification is required, and how items that no one decides before the close date are handled. Treat undecided items as an exception path with its own sign-off, not as silent approvals.

When the campaign closes, its decisions are carried out in a remediation step. For revocations, the effect depends on the connector to the target system. If the financial application is reached through an Active Directory, LDAP, database or SCIM connector, the removal of access is only as complete as that connector's support for the operation. Test this in a non-production environment with a sample of revocations, and check the target system directly, not only midPoint's view. Confirm whether removal runs immediately at close or in a later task, how failed operations are reported, and how they are rerun. Keep the campaign definition, reviewer decisions, remediation tasks and target-side verification together as one evidence set.

A reviewer's decision can differ from what the remediation step applies. A revoke may not remove access if the same entitlement is granted through a second assignment, a policy or a higher-priority mechanism that midPoint re-applies. A connector failure, or a target that disables an account without deleting its roles, can leave access in place even though the decision and the task both show success. An assignment that changed after the reviewer saw it may also be outside the decision. Plan a reconciliation at period end that compares each revoke decision with the state of the target system, and record any mismatch as a finding. Confirm the exact precedence and re-evaluation rules against the documentation for the version you run.

SOX access review evidence midPoint produces and how to keep it

A SOX access review is only as strong as the record that proves it ran as designed. The cards below cover the evidence categories a midPoint certification campaign can generate, why each one matters to an auditor testing operating effectiveness and authority, and what to confirm about your chosen version and retention practices.

Campaign definition and design

The campaign definition records which objects are certified, what is checked, who decides and the deadline. Auditors read it to confirm the review was designed to cover the financially relevant systems and roles in scope for the control. Keep the exported definition, including its scope filters and reviewer rules, as it stood when the campaign launched. Confirm with your version's documentation how definitions are exported and versioned, since later edits can change what an older campaign appears to have covered.

Scope and population snapshot

The scope record shows which accounts, entitlements and roles were in the population when reviewers were assigned. Auditors compare this population against the system of record to test completeness, because an access review that omits privileged or inherited access does not cover the risk it is meant to address. Retain the population export or report generated at campaign start. Confirm which reports your version produces for membership at a point in time and whether they can be re-run later for testing.

Reviewer assignments and authority

Assignment records show which manager, owner or delegate was made responsible for each review item. Auditors use them to test whether the person performing the review had the authority and competence the control requires, and whether delegations were valid. Capture assignments with their timestamps and any reassignments made during the campaign. Check how your configuration resolves reviewers from organizational data, and confirm that the resolved reviewer for a sampled item can be shown from the records.

Decision records and reviewer identity

Each decision (keep, remove or reduce) should be attributable to a named reviewer at a recorded time, with any comment the reviewer entered. Auditors sample these entries to test that the reviewer actually reviewed the access rather than approving in bulk without evaluation. Retain the decision log alongside the campaign definition so each sampled decision can be traced to its item and assignment. Confirm how your version records bulk actions and whether those actions are distinguishable in the audit trail.

Remediation outcomes and timing

When a campaign closes, decisions to remove access are carried out in a remediation step. The evidence auditors test here is whether revoked access was actually removed, and how long it remained after the reviewer's decision. Retain the remediation results, the time each removal was applied and any failures or manual follow-ups. Confirm how remediation behaves when a connector to a target system fails, because a removal recorded as decided but not applied is an exception the auditor will ask you to explain.

Retention under your records policy

Evolveum's documentation describes how campaigns are defined and carried out, but the retention period for campaign definitions and outputs is a decision for your organization. Set retention in line with your SOX record-keeping obligations and your legal hold process, and cover the audit logs and reports that show the campaign history. Store exports in a location that is independent of the running midPoint instance, so records survive upgrades or rebuilds. Confirm with your auditors which artifacts they expect and in what format before the first campaign closes.

Which financially relevant systems to put in scope first

Start with management's own ICFR judgment, not with the list of applications IT happens to run. SEC Release 33-8810 states that the IT general control aspects relevant to an ICFR evaluation vary with each company's facts and circumstances, and no SEC rule or PCAOB standard publishes a fixed catalog of them. In practice, the first deliverable is a written scoping memo that links each in-scope financial reporting control to the systems that produce, store, approve or change the data behind it. Management should only evaluate the IT general controls needed for those controls to operate properly and consistently, so systems that affect only operational efficiency can stay out of the first campaign, provided the decision and its rationale are documented.

For each system on that list, trace three access populations separately. Application access covers the business and approver roles that post journals, approve payments or change master data. Database access covers the accounts with direct read or write rights to the underlying tables, which often bypass application controls entirely. Privileged accounts cover administrators, service accounts and break-glass identities. PCAOB AS 2110 cites IT personnel holding privileges beyond their duties as an IT risk to internal control over financial reporting, so privileged and database identities should not be left out of scope because they are harder to model. Ask each system owner to name the native role or group that grants each of these three populations, and record where that role is assigned in the source system.

Connector support status in the midPoint catalog then determines what midPoint can do with each system. The Evolveum connector documentation lists connectors whose status runs from supported to community and experimental, and that status affects how confidently you can rely on automated reads, certifications and deprovisioning for the system. A system with a supported connector can usually have its entitlements imported and its certification decisions carried out automatically. A system with a community or experimental connector, or no connector, may need a manual remediation step, a scripted connector or a compensating review, and the auditor will ask how that step is evidenced.

Confirm each connector's status against the Evolveum catalog before the scoping memo is signed, and record the version you intend to run, because status can change between releases. Also confirm whether the connector covers the specific resource type you need, such as a particular database engine or an ERP module, rather than only the general product family. Where a connector does not cover a system, decide early whether to exclude it from automated certification, add a documented manual review, or defer the system to a later campaign. Each of these options changes the evidence an auditor will test, so the choice belongs in the scoping memo, not in the campaign configuration.

Setting up midPoint for SOX user access reviews, step by step

This sequence takes a team from agreeing which financially relevant systems are in scope to running a first production certification cycle whose records an external auditor can test. Each step names its owner and the output that closes it, so the review produces evidence that the control operates as designed.

Agree the ICFR-relevant system list
Finance, internal audit and IT agree which applications, databases and infrastructure components support financial reporting and therefore need access reviews. Record the list with the business owner, the financial process each system supports, and the privileged roles that sit on top of it, including database and operating system accounts that can change financial data. Ask internal audit to confirm the scope against the company's own risk assessment. Done when the signed list is stored with the control documentation and every system on it has a named owner.
Confirm connector support for each system
For each system on the agreed list, check the Evolveum connector catalog for its support status, ranging from supported to community or experimental. Where a system has only a community or experimental connector, decide with internal audit whether that is acceptable, or plan a custom connector or a manual certification path with documented evidence. Confirm read access for account and entitlement data, since a review is only as complete as the data it certifies. Done when each system has a recorded connector, its status, and a documented decision for any gap.
Model the access to be certified
Decide what midPoint certifies for each system: assignments of roles, direct entitlements, or both. Map the midPoint roles and resources to the business access that auditors will ask about, and confirm that account data pulled from target systems matches what the application shows users. Identify accounts that midPoint does not manage, such as shared or service accounts, and state how they are handled. Done when a written access model shows each certified object type and a sample reconciliation confirms that the data matches the source systems.
Define reviewers and their authority
Set who decides on each access item. Typically this is the application owner or the manager of the person holding the access, with a defined fallback reviewer for absences. Document each reviewer's authority, meaning which access they are permitted to approve, and confirm that no reviewer certifies their own access. Configure the reviewer assignments in midPoint and check them against the organization's approval matrix. Done when the reviewer list is approved by the control owner and a test campaign shows each item routed to the expected person.
Configure campaign scope, questions and deadlines
Build the certification campaign definition: the objects in scope, the review questions reviewers answer, the recurrence, and the closing date for decisions. Write the question text so a reviewer knows what they are approving, and record the reason for each decision option. Set the campaign's stages and deadlines according to the review cadence agreed with internal audit. Done when the campaign definition is exported and version-controlled, and the control narrative describes the same scope, frequency and deadline the campaign uses.
Set remediation behavior for revoked access
Decide what happens when a reviewer revokes access. midPoint carries out decisions in a remediation step after the campaign closes, so define whether revoked assignments are removed automatically, routed to a ticket for manual removal, or both. Specify the time between closing a campaign and removing access, and how removals are confirmed in each target system. Test that a revoked entitlement disappears from the target system and that the removal is logged. Done when a test revocation is traced end to end from the reviewer's decision to the target system record.
Run a pilot campaign
Run a campaign on one or two low-risk systems before the first full cycle. Involve the reviewers in the pilot, collect their feedback on question clarity and routing, and reconcile the results against the source system exports. Record any missing reviewers, unreconciled accounts or failed remediations, and fix them before the production scope is expanded. Keep the pilot records, because they show the control was tested before it was relied on. Done when the pilot findings are closed and the control owner signs off the production configuration.
Agree the evidence package with the external auditor
Before the first production cycle, agree with the external auditor which records they will test: the campaign definitions, the completion reports with reviewer decisions and timestamps, the reconciliation of the reviewed population to source systems, the remediation logs, and the approval of the scope. Confirm the sample sizes and retention period with the auditor, since DeployOpen prepares this evidence but does not issue audit conclusions. Done when the auditor has confirmed the evidence list in writing and each item has a named owner who can produce it on request.

What midPoint does not cover in a SOX access review

midPoint runs the access certification workflow and records its decisions, but the ICFR conclusion, the scoping of relevant systems and the independence of reviewers stay with your organization and its auditors. The cards below list the boundaries to settle before the first campaign so that the evidence you produce matches what the auditor will test.

No ICFR assessment or auditor opinion

midPoint does not produce an ICFR assessment, an auditor opinion or an attestation under Section 404 of the Sarbanes-Oxley Act. Management evaluates internal control over financial reporting and external auditors form their own conclusions. Treat midPoint campaign records as one input to management's evaluation, and confirm with your auditor which records they will accept and in what format.

Relevant system scoping stays with you

midPoint cannot decide which systems are relevant to ICFR. Management selects those systems from its financial reporting risks, including applications that initiate, process or record transactions and the databases and operating systems beneath them. Document that scoping decision before building campaigns, because a campaign only certifies the objects you have loaded and assigned to it.

Program changes and computer operations

SEC guidance names program development, program changes and computer operations as IT general control areas that management may need to evaluate. midPoint certifies who holds access to systems and data, but it does not control code promotion, change approval in a source control or ticketing system, or batch job monitoring. Those controls need their own owners and evidence, which an access review does not replace.

Reviewer competence and segregation of duties

An access review is only as reliable as the person making each decision. midPoint does not verify that a reviewer understands the application, holds the authority to approve the access, or is independent of the person who uses it. Set reviewer assignments deliberately, prevent people from certifying their own access, and confirm the reviewer criteria with your auditor, since PCAOB AS 2201 tests whether the person performing a control has the necessary authority and competence.

Server side of OAuth2, OIDC and SAML

Evolveum states that 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 applications that need those protocols for sign-in require a separate identity provider. Its own user interface can authenticate against external SSO services, which is a different matter from issuing tokens to your applications.

Connector coverage by support status

midPoint reads and provisions accounts through ConnId connectors, but coverage varies by target system. The Evolveum connector catalog lists each connector with a status ranging from supported to community and experimental. Before scoping a campaign, confirm the support status of every financially relevant system, and document how access for any system without a supported connector will be reviewed and removed.

Keeping review controls stable across midPoint release changes

Plan every midPoint upgrade against the release calendar before the change window is booked. A new version can change how access certification campaigns behave and how their decisions and remediation records are presented, and an auditor testing a SOX user access review will examine the evidence from the review period, not the version you intended to run. The dates that matter for this decision are these: midPoint 4.8 is a long-term support release supported until 17 October 2028, midPoint 4.10 is supported until 26 November 2027, and midPoint 4.9 support ends on 18 October 2026. midPoint 4.11 is planned for 21 October 2026. A deployment on 4.9 therefore needs its move to a supported line scheduled well ahead of that October 2026 date.

Check the platform prerequisites in the same change plan. midPoint recommends Java 25 for version 4.11 and later, with Java 21 supported, and Java 21 for 4.10 and older, with Java 17 supported. It uses PostgreSQL as its native repository database and recommends running that database on a separate server. A runtime change can alter behavior in the same way a midPoint change can, so upgrade the JVM and the database together in a staging copy that mirrors the production configuration. Confirm the exact PostgreSQL versions accepted by the target release on the system requirements page at the time of the change, and do not rely on version lists from older internal notes.

After any upgrade, revalidate the campaign evidence before the next review cycle closes. Run a representative campaign in staging against the financially relevant systems in scope, then compare the results with the last production campaign for the same population. Compare the objects selected, the reviewers assigned, the decisions recorded, the deadlines applied and the remediation actions taken when the campaign closes. Keep the before and after exports, the release notes reviewed and the sign-off from the control owner. Where a difference cannot be explained, record it as a finding for the control owner and do not accept the new output silently.

Decide the governance rules before the first upgrade is needed. Name who approves a change to campaign definitions, reviewer assignments and remediation settings, and state how a version change is classified: planned, emergency or security-driven. Ask Evolveum or your implementation partner to confirm which configuration elements and report formats changed between your current release and the target, and keep that answer in the control file. Plan for an upgrade forced by a security fix outside the normal calendar, and confirm that a database backup taken before the change can be restored in a tested rollback. Record the 4.9 end-of-support date in the risk register so the move does not become urgent during an audit period.

Questions buyers ask before hiring help with SOX access reviews in midPoint

What drives the cost of a SOX access review project in midPoint?

The main drivers are the number of systems in scope, the connector status of each one, and how much HR and approval design the campaigns need.

Who pays for what: the client usually pays for its own system owners, reviewers, finance staff and auditor time. A partner's fee typically covers planning, connector work, campaign configuration, testing and evidence design.

Evidence requirements and the number of review cycles also add effort, because each cycle repeats campaign setup, reviewer follow-up and remediation checks. DeployOpen does not publish a price list. A quote follows from a written scope, so ask that it list the systems, connectors, cycles, evidence outputs and what the client must supply.

Can our own team run SOX access reviews in midPoint without a partner?

Yes, it is possible, but it depends on the skills and capacity you can staff.

midPoint is open source, and Evolveum states that it has no enterprise edition, so there is no separate edition to buy. Your team would need to operate Java, PostgreSQL and the connectors, design HR-driven lifecycle and approvals, and build campaigns that the auditor will accept.

Evolveum sells Product Support subscriptions for resolving product bugs, with 8x5 next-business-day or 24x7 SLA options, and Platform Subscriptions that add feature development. Those are vendor services, not SOX evidence. Confirm with your external auditor which evidence they expect before you decide who builds it.

How long does it take to reach the first audited access review cycle?

Agree the timeline with your external auditor before you commit to a date, because the auditor sets the test period and the evidence they accept.

No duration is fixed here. The length depends on the systems in scope, connector readiness, HR data quality and how many approval paths need redesign.

Plan backward from the test period: connector and campaign build, a dry run with reviewers, then the live campaign, remediation and evidence collection. Ask any partner for a written schedule that shows dependencies on system owners, reviewers and the auditor's walkthrough dates.

What does our team have to provide for a SOX access review?

Expect a defined time commitment from several groups, both during design and in every cycle.

System owners confirm which accounts and roles exist and why they are needed.
Reviewers decide whether each access is kept or revoked, by the deadline.
Finance leads agree which systems are financially relevant to the control environment.
HR supplies joiner, mover and leaver data that drives lifecycle changes.
IT provides service accounts for connectors and network access to target systems.
Internal audit and external auditors set test criteria and attend walkthroughs.

Identify named owners for each group at the start, because delays in reviewer or owner response are a common cause of slipped cycles.

What does a fixed-scope quote for midPoint access reviews include?

A fixed-scope quote should state the scope, systems, connectors, campaign definitions, deliverables, timelines, responsibilities, assumptions, exclusions and acceptance criteria.

DeployOpen agrees scope, deliverables and timelines in writing before work starts. Ask the quote to separate one-time build work from recurring activity, such as later review cycles or ongoing support.

Ongoing support, upgrades and continuous testing are available as retainers, so they should not be assumed to sit inside the initial scope. Ask how the quote handles a change in systems or cycles, and what triggers a new estimate.

Which systems should a first midPoint SOX access review include?

Start with the systems that management and your auditors agree are financially relevant to internal control over financial reporting.

SEC Release 33-8810 explains that the relevant IT general control aspects vary with each company's facts and circumstances, so there is no universal list.

Then check connector status in the Evolveum catalog. Supported connectors reduce build risk, while community or experimental connectors need a test plan and an owner. For any system without a suitable connector, decide between a custom connector, a manual review step or a change in scope, and record that decision for the auditor.

What evidence does an auditor test in a SOX access review?

Auditors test whether the review control operates as designed and whether the person performing it has the authority and competence to do so.

PCAOB AS 2201 describes this operating effectiveness test. Evidence usually includes the campaign definition, the population of accesses in scope, reviewer assignments, decisions with timestamps, remediation records and the follow-up on exceptions.

Confirm with your auditor how many samples they will draw, which reviewers must be independent of the access they approve, and how they want campaign configuration changes documented during the period.

How does midPoint carry out revoked access after a review?

A midPoint campaign defines which objects to certify, what to check, who decides and by when. When the campaign closes, the decisions are carried out in a remediation step.

For engineers, the key check is that the removal reaches the target system, not only the midPoint repository. Test a sample of revocations in each connected system, and review task logs for failed provisioning actions.

Also confirm how your configuration treats reviewers who do not respond before the deadline, and document that rule, because auditors will ask how open decisions were closed.

How DeployOpen scopes, configures and documents SOX access review controls

DeployOpen plans, builds and documents midPoint access certification campaigns for the financially relevant systems in scope for your SOX IT general control testing, inside your own infrastructure. The work is agreed as a fixed scope in writing, and the evidence it produces is designed around what your auditors will test.

How we scope

Written scope names the financially relevant systems, applications and accounts that each certification campaign will cover.
We confirm with your control owners who decides each review, the review frequency and the deadline for decisions.
Scope records which midPoint release and Java and PostgreSQL versions your deployment will run, checked against the current release page.

How we build

We configure certification definitions, reviewers and remediation steps in midPoint and test them in a non-production environment first.
Connectors to each target system are tested so that revoked access is removed where the system can actually enforce it.
Test campaigns run with your control owners before go-live, and we record the results of each test run for the control file.

How we hand over

You receive written documentation of campaign design, reviewer assignments, decision rules and the remediation procedure.
The evidence set covers campaign exports, decision records, remediation logs and change history that auditors commonly sample.
Runbooks explain how to start a campaign, handle reviewer escalations and reproduce a past campaign for an auditor's request.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Upgrades to midPoint and connectors are planned as their own change, with the control evidence re-tested afterwards.
Confirm with Evolveum which support subscription level fits your recovery and response needs before the platform goes live.