Open source identity governance for SOX ITGC access controls

Approval evidence comes from the approval history attached to each access request in midPoint, which should record who requested the access, who approved or rejected it, when they decided, and what was granted. Auditors use it to test that privileged or financially significant access is approved by someone with the authority to approve it before provisioning runs. They pull a sample of requests and match each grant to an approved decision with an earlier timestamp. If approvals happen in a ticketing tool, the auditor needs a clear link between that ticket and the midPoint request. Confirm with your auditor which approval artifacts they accept, how long they must be retained, and whether they expect an export or a screen capture. Confirm the exact fields your midPoint version records.

Auditors compare the termination date in the authoritative HR source with the time each in-scope account was disabled or removed. In midPoint, the evidence is the provisioning and reconciliation history for each user, showing the status change and the resulting operation on each target system, with timestamps. A gap between HR termination and deprovisioning is an exception the auditor documents. The test population should come from HR terminations in the period, not only from accounts midPoint already processed, because leavers who were never processed would otherwise be missed. Confirm with your auditor the timeliness threshold they will apply, which target systems are in scope, and how they want orphaned accounts reported. Also confirm that the HR feed is retained, since the start of the clock depends on it.

Completeness evidence is the campaign record showing the population at launch: every user and entitlement in scope, the reviewer assigned to each item, each decision, and the items that expired without a response. In midPoint, certification campaign reports and their stage history provide this, and decisions are kept with reviewer identity and time. Auditors usually test completeness by comparing the campaign population with an independent extract from the target system taken on the same date. Any difference should be explained through reconciliation or documented as an exception. Confirm with your auditor the review period, the number of campaigns they will sample, and the detail they expect, including whether revoked access must show its actual removal in the target system. Confirm that the extract method can be repeated exactly.

Segregation of duties evidence has two parts: the rule set that defines conflicting access, and the output of running that rule set against current assignments. In midPoint, conflicts are modeled as rules, and the report of matches shows which identities hold combinations the rules forbid. Each detected conflict should show either a remediation or an approved exception with a named approver, a reason and an expiry date. Auditors test that the rule set was reviewed and that the scan ran at the dates they test. Confirm whether your rules are built into midPoint policy, implemented as custom reports, or both. Confirm with your auditor which system roles they consider conflicting, because SEC guidance leaves relevance to each company's facts and circumstances, and confirm where the exception register is kept.

Auditors look for evidence that changes to roles, policies, connectors and approval workflows were authorized and recorded. midPoint records object changes in its audit log, which should identify who made each change, when, and the before and after values where the version captures them. Those records should be exported to write-once or centrally controlled storage so administrators cannot alter them. Each change should link to an approved change ticket, and the sample should include changes to role definitions that grant financially significant access. Confirm with your auditor the period they will test. Confirm in your environment whether the audit log captures the fields they need and how long records stay in the system before export. Review who holds administrator access to midPoint, since that group can alter configuration.

Population completeness is the step auditors check before they sample. The population must include every account with access to an in-scope financial system, taken directly from the target system, and it must reconcile to midPoint's view of the same accounts. Reconciliation reports list accounts that exist only in the target system, often called orphans, and accounts midPoint manages that are missing from the target. Auditors commonly ask how the extract was generated, when, by whom, and whether its query filters were approved. Keep the query, its parameters and the output together with a timestamp so the auditor can re-run it. Confirm with your auditor which systems and account types are in scope, including service and shared accounts, and whether they will accept a system-generated report as the population.

Auditors test operating effectiveness under PCAOB Auditing Standard No. 5 (now AS 2201) by combining inquiry of personnel, observation of operations, inspection of documentation and re-performance of the control. For these controls, inquiry covers how approvers and reviewers are chosen, observation covers a live provisioning or certification run, inspection covers the approval, review and change records described above, and re-performance means the auditor repeats a sample of decisions from the evidence. DeployOpen prepares the controls, reports and evidence for that testing. It does not issue audit reports, attestations or certifications. Before go-live, confirm with your auditor the sample sizes, retention period, export format, and whether they will treat midPoint reports as system-generated information they must validate. Agree the re-performance steps in writing before the first test period.

midPoint itself has no license fee, and Evolveum states that it has no enterprise edition: every line of midPoint code is published under open source licenses. The cost of a SOX access control program is therefore the work around the software: connector development and testing, role modeling, data cleanup, infrastructure, support and the implementation itself. Ask any partner to separate these lines in a quote so you can see who is paid for each piece. Evolveum offers Product Support and Platform Subscriptions as optional recurring services, and those are priced separately from any implementation work.

One-time costs usually include the initial implementation: connector setup for each financially significant system, role design, cleanup of orphaned and excess accounts before go-live, testing and the first certification campaign. Recurring costs include the hosting and database infrastructure, patching and upgrades, periodic reviews of connectors and roles as systems change, and any support subscription you choose. Ask the quote to state which items recur, how often each recurring item is billed or performed, and who keeps the environment running after handover.

The main drivers are the number of financially significant systems that need a connector, whether each connector is supported, community or custom, how many roles must be modeled from existing access, and how messy the starting data is. Other factors include the number of source systems for HR data, the number of approvers and review owners, and how many segregation of duties rules the auditor expects. Organizations with clean HR records, a small set of well-documented applications and an agreed role catalog usually have a smaller scope than those with many legacy applications and undocumented entitlements.

Before work begins, the client should provide an authoritative HR source with reliable joiner, mover and leaver events, a list of in-scope financially significant systems with named application owners, and access to the entitlement data for each system. Management must also agree on the control design with the external auditor, including what evidence the auditor will re-perform and who signs off on certification results. Internal audit and the auditor should be involved early, because a design the auditor rejects late in the project costs more to fix than one agreed at the start.

Yes, a capable internal team can implement midPoint, since the software is open source and the documentation is public. The effort lies less in installation than in the skills needed for connector configuration, role modeling, reconciliation of existing accounts, and documenting controls in a form an auditor can test. Midpoint runs on Linux in a virtual machine or from Docker images, uses PostgreSQL as its repository database, and needs Java 21 or 25 depending on version. Ask yourself whether your team has these skills, whether it can support the environment through upgrades and whether it can staff the work alongside existing responsibilities.

Ask for a written scope that lists each in-scope system, each connector and its support status, the role model deliverables, the cleanup approach, and the certification campaigns to be configured. The quote should state the deliverables for the control evidence, the testing approach, the acceptance criteria and the responsibilities of the client. Request separate line items for implementation, infrastructure setup, any support or subscription and any post-go-live work. Also ask how changes to scope are priced and what happens if the auditor requests additional evidence after the design is agreed. DeployOpen agrees scope, deliverables and timelines in writing before work starts.

The duration depends on the number of in-scope systems, the quality of HR and entitlement data, the number of roles to design, and how quickly the auditor and application owners respond. No timeline is published here for a generic implementation, so ask any partner to show a schedule tied to your system list and milestones. A useful plan includes an early discovery phase, a pilot with one or two systems, a first certification campaign and an auditor walkthrough before the control period you need to evidence. Timelines should follow from the written scope rather than from a generic estimate.

The SEC estimated in its 2020 release on accelerated filer definitions (Release 34-88365) that an issuer newly exempt from the Section 404(b) auditor attestation would save about $210,000 per year on average, made up of roughly $110,000 in audit fees and $100,000 in other costs. This is a regulatory estimate for a specific group of issuers, not a promise about your organization. Whether automation lowers your audit or internal costs depends on your filer status, your existing controls and what the auditor is willing to rely on. Confirm your filer status and auditor expectations before you build a business case.