Access certification campaigns that close at 100% completion and still produce audit findings. The structural reason why.

A quarterly access review closes on schedule. Every item is certified. Completion rate: 100%.

Then the auditor asks three follow-up questions.

What information did the reviewer have when they made each decision? Which of the certified items carried an active SoD conflict at the time of review? For the access marked for revocation, when was it removed from the connected system?

In most organizations, these questions cannot be answered from the certification record. The completion is documented. The evidence that the review was meaningful is not.

This is the most consistent pattern in access certification audit findings: not the absence of a review program, but a program designed to produce completion rather than evidence.

Completion and evidence are not the same thing

A completed review proves the activity happened. It does not prove the activity was informed, that conflicts were surfaced, or that findings were acted on.

Under SOX ITGC and COBIT access control frameworks, a user access review is tested on operating effectiveness, not completion rate. Operating effectiveness means reviewers had the information to make a real decision, decisions resulted in action where action was required, and the complete record can be produced without manual reconstruction.

A completed spreadsheet fails all three tests.

The process problem that produces rubber stamps

The gap between completion and evidence is structural, not behavioral. It is produced consistently when reviewers are handed the wrong inputs.

A typical certification workflow gives a reviewer a list of technical role names, a binary certify or revoke option, and a deadline. No information about what the access permits in business language. No visibility into SoD conflicts. No account history. No indication of whether the user's role has changed since the access was granted.

Under those conditions, certifying the list is the rational response. The reviewer cannot make a meaningful decision without meaningful information. When the process withholds that information, the review produces a sign-off. The completion rate looks identical to a genuine review. The evidentiary value is entirely different.

This is also the mechanism that produces the specific finding most commonly cited in access review audits: a reviewer who approved access creating a significant SoD conflict, because the conflict was invisible in the review workflow.

What changes a review into evidence

Five things must be present for a completed review to qualify as evidence that a control operated.

Context at decision time, meaning reviewers see entitlement purpose, risk classification, SoD conflicts, recent usage, and what changed since the last review, not just a role name. A governed decision record, meaning decisions exist in a workflow system that captures who decided, when, and what the outcome was. Remediation tracked to completion, meaning revocation decisions are routed to an owner and the system confirms removal with a timestamp. Documented exceptions, meaning retained access with a risk flag carries a rationale, a compensating control, and a review date in the governance record. And an exportable trail, meaning the complete campaign record can be produced for an auditor without manual reconstruction from multiple systems.

None of these require more effort from reviewers. They require a process designed to produce evidence as a byproduct of normal operation, rather than a process designed to produce completion.

The architectural distinction that matters

Organizations that get this right do not have more disciplined reviewers or more thorough compliance teams. They have processes designed so that evidence is inseparable from the operation.

Context surfaces automatically because the system retrieves it at review time. Decisions are captured in a governed workflow because that is where reviewers work. Remediation is tracked because revocation actions move through the same system that recorded the decision. The exportable trail exists because the system records every event as it occurs.

The completion rate and the evidence rate are the same number in a well-designed process. In a poorly designed one, the completion rate is high and the evidence rate is effectively zero.

The access certification program that produces a clean completion record and fails the follow-up questions is not a control. It is a ritual that documents itself. The distinction is design.

What evidence gaps are compliance and IAM teams finding most consistently in access certification programs right now? The experiences of teams working through this would be worth hearing.
https://www.openiam.com/soluti....ons/access-governanc

Design vs. Operating Effectiveness: Why SoD Programs Pass on Paper and Fail Under Testing

Segregation of duties programs rarely fail because the rules are wrong. They fail because nothing enforced them. In control-testing terms, the distinction is between design effectiveness — are the right conflicts defined, and would the control mitigate the risk if it operated? — and operating effectiveness: did the control actually operate throughout the period, and can the organization prove it? A well-researched rule catalog can pass the first test outright and contribute nothing to the second. That gap, between a control as described and a control as operated, is where most SoD findings originate.

Key Takeaways

Design effectiveness asks whether the rules are right; operating effectiveness asks whether they ran — and left a record.

Most SoD findings are operating failures: sound rules with no enforcement point, no remediation path, and no evidence.

Testers sample three evidence classes — prevention decisions, remediation closures, and documented exceptions.

A documented rule set with no operating control proves awareness without action — a worse audit position than it appears.



What is the difference between design and operating effectiveness in SoD?

Design effectiveness is evaluated by inspection. A tester reads the rule set and asks whether the defined conflicts reflect real risk: does the catalog capture the combinations that would let one person both commit and conceal an error or fraud? Sound logic, sensible coverage, reasonable risk ranking — design passes.

SoD operating effectiveness is evaluated by sampling. The tester selects transactions from the period and asks what the control did with each: an access request that would have created a conflict — was it evaluated and blocked, and where is the record? A violation identified in existing access — who owned it, and when was it closed? An accepted conflict — where is the rationale, the compensating control, the review date? Design is about the quality of the rules. Operation is about the existence of the record.

Where paper programs collapse

The typical failure sequence is consistent across industries. An organization invests in building the rule set — workshops, risk analysis, a reviewed and approved catalog — and then stores it. There is no enforcement point between the rules and the access request process, so requests are approved without ever being evaluated against the catalog. There is no scanning cadence, so conflicts in existing access accumulate silently. There is no remediation path, so the conflicts that do surface — usually during audit preparation — land in a report with no owner and no closure mechanism.

When testing begins, the sequence produces a predictable result. The tester asks for the period's prevention decisions: none exist, because no request was ever evaluated. The tester asks for remediation records: a partial list exists in a spreadsheet, with no timestamps and no owner history. The tester asks for exception documentation: the exceptions were discussed in email. Each individual answer is a deficiency; together they establish that the control described in the design documentation did not operate.

There is a second-order problem that makes this worse than having no program at all. The approved rule catalog is proof of awareness. The organization identified the dangerous combinations, documented them, and cannot demonstrate that it acted. In a regulatory examination or a fraud post-mortem, segregation of duties enforcement that exists on paper but not in operation converts the rule set from an asset into an exhibit.

What testers sample — and what has to exist

Operating effectiveness testing for SoD reduces to three evidence classes, each of which can only exist if the corresponding operation ran during the period:

Prevention decisions. Records showing that access requests were evaluated against the rules at the point of request, with conflicting requests blocked and the outcome logged. These records cannot be created retroactively — either the enforcement point existed during the period or it did not.

Remediation closures. For each identified conflict: the routing to a named owner, the action taken, and the closure timestamp. An identified conflict with no closure trail is an open finding, not evidence of a functioning control.

Documented exceptions. For each accepted conflict: the owner, the rationale, the compensating control, and the scheduled review date. Well-documented exceptions strengthen the test result; undocumented ones fail it.

Note what all three have in common: they are byproducts of a process, not documents anyone writes. An organization cannot draft its way to operating effectiveness in the weeks before an audit. The evidence either accumulated during the period or it is absent.

Closing the gap

The remedy is structural rather than documentary. The rule set — ideally a structured SoD rule set expressed in business language and mapped to real entitlements — becomes the input to a governed process: evaluation at the point of access request, detection across existing access, remediation routed and tracked to closure, exceptions captured with rationale and expiry, and every decision recorded in an exportable trail. The distinction between SoD rules vs controls is exactly this: the rules define what the control enforces, and the control generates the evidence that testing will later sample. In practice, that process runs on an access governance platform — because request-time evaluation, tracked remediation, and continuous evidence capture are workflow capabilities, not documentation exercises.

The test most SoD programs face is not whether the rules are good. It is whether anything happened because of them. Design gets a program approved. Operation gets it through the audit.


https://www.openiam.com/blog/s....od-rules-not-a-contr #accessmanagement #identitymanagement #accesscontrol #accessreview #sod #sap #identitygovernance

SAP IDM Is Ending. The Decision Most Manufacturers Are About to Make Will Determine Their Compliance Posture for the Next Decade.


Planning and migration for complex manufacturing environments typically require 18 to 36 months. An organization that begins evaluating options in mid-2026 completes the migration with time to validate the new platform and run at least one audit cycle before the December 2027 mainstream maintenance deadline. An organization that treats this as a 2027 problem makes the decision under deadline pressure, with less time to evaluate alternatives and less capacity to design a governance model rather than execute a migration path.

The organizations that navigate SAP IDM end-of-maintenance well are not those that execute the most efficient migration. They are those that use the forced migration as a forcing function to build the governance model they should have had years ago. The migration timeline is fixed. The governance decision made within it is not.

For a full treatment of the governance capabilities manufacturing companies need from an SAP IDM replacement, including the planning questions, the governance model, and the seven-step framework, visit

https://www.openiam.com/blog/s....ap-idm-replacement-g

Your SAP access review is done. Your auditor is not impressed.

Here is a scenario that plays out more often than most manufacturing security teams want to admit.

The quarterly access review is complete. Managers signed off. The spreadsheet is filed. The GRC team closes the ticket.

Six weeks later, an auditor asks why a plant procurement analyst held the ability to both create a vendor record and approve a purchase order for the better part of two years.

The answer — reconstructed from email threads, SAP exports, and a ticket that was closed without evidence of remediation — takes three days to pull together. It is not convincing.

This is not an SAP problem. It is a governance problem.

The conflict was never the issue

SAP SoD conflicts manufacturing security teams face are well understood. The dangerous SAP role combinations — vendor master plus payment run, production order creation plus confirmation, payroll bank account plus payroll execution — have been documented, debated, and flagged in GRC systems for years.

What manufacturing security teams consistently underestimate is how much work comes after the detection.

An auditor does not want to know that you found a conflict. An auditor wants to know:

Who reviewed it?
When?
What did they decide?
Was the access removed, or was a compensating control documented?
Where is the evidence?

A spreadsheet that was reviewed, approved, and filed tells you none of those things clearly. It tells you a list existed and someone ticked boxes. That is not audit evidence. That is audit theater.

The real gap is the evidence trail

The ten most dangerous SAP access conflicts in manufacturing are not secrets. What is less visible is the gap between detecting them and proving — to an external examiner, months later — that the right people reviewed them and the right actions were taken.

That gap is where audit findings are born.

It is also where the conversation about SAP access governance needs to go. Not just: do we have SAP SoD rules manufacturing teams can rely on? But: when a conflict is found, does our process produce a defensible, timestamped record of what happened next? The full SAP access risk manufacturing environments carry goes well beyond what a GRC scan captures. And they build SAP access control manufacturing programs around structured governance records, not closed tickets and archived spreadsheets.

What this looks like in practice

The manufacturers who handle this well share a few things in common. They validate SAP Segregation of Duties violations at the access request stage — before access is assigned, not after. They connect their HR lifecycle to their SAP environment, so role changes and terminations actually trigger access reviews. And they build SAP access control in manufacturing around structured governance records, not closed tickets and archived spreadsheets.

The result is not just better audit outcomes. It is a program that can answer the auditor's question in minutes, not days.

If you are working through SAP access risk in a manufacturing environment — or preparing for an audit that will go beyond SAP — the full breakdown of the ten most dangerous SAP SoD conflicts, and what the right governance response looks like for each, is worth reading:

The 10 Most Dangerous SAP Access Conflicts in Manufacturing →

https://www.openiam.com/blog/d....angerous-sap-access-

What has your experience been with SAP access reviews under audit pressure? Happy to discuss in the comments.

The SAP IDM Replacement Decision Most Mid-Market Organizations Are Getting Wrong


The evaluation starts. Three options get compared: SAP GRC for HANA 2026, a large enterprise IGA vendor, and potentially a purpose-built mid-market platform. The comparison framework focuses on SAP coverage, brand recognition, and cost. The enterprise IGA vendor has the most comprehensive capability set. SAP GRC is the familiar path. The mid-market platform is underweighted because it is less well-known.

The decision gets made. Then eighteen months later the compliance team starts asking why the governance posture looks the same as it did under SAP IDM — or why the implementation is still not complete.

The framework is the problem.

What the evaluation is missing

The standard comparison of SAP IDM replacement options focuses on capabilities. The comparison that produces the right decision focuses on three things the capability comparison misses.

The first is prerequisites. SAP GRC for HANA 2026 requires SAP HANA database and S/4HANA Foundation as prerequisites. Organizations on non-HANA databases face an additional database migration before upgrading to GRC 2026. That is not one migration, it is two sequential migrations. The timeline implication is significant and is frequently not surfaced until after the evaluation is complete.

The second is team fit. Enterprise IGA platforms are designed for organizations with dedicated IAM teams and 12 to 18 month implementation budgets. For a mid-market organization without a dedicated IAM function, the capability set is comprehensive and the implementation complexity frequently exceeds the team's capacity to operationalize it. A capable platform that is underutilized because the implementation exceeded the team's bandwidth is not a compliance success.

The third is governance scope. SAP IDM governed the SAP boundary. SAP GRC for HANA 2026 governs the SAP boundary. An evaluation that starts from SAP IDM parity will select a replacement that replicates the existing governance scope. Organizations that also run Microsoft 365, ServiceNow, Salesforce, and Workday alongside SAP have a governance gap that extends beyond the SAP boundary. The migration is the right moment to close that gap, not to replicate it.

What SAP IDM actually left ungoverned

SAP IDM provisioned access based on roles. It did not detect whether the combination of roles a user holds creates a Segregation of Duties violation. It did not govern access to any system outside SAP. It produced no cross-system access visibility and generated no SoD detection capability. Organizations that have been running SAP IDM for a decade have been running a governance architecture that was never designed to catch the conflicts auditors most commonly cite.

The migration from SAP IDM is an upgrade opportunity. Evaluations that frame the decision as replacing like-for-like are leaving that opportunity on the table.

The timeline math

SAP IDM mainstream maintenance ends December 31, 2027. A purpose-built mid-market replacement deploys in 6 to 12 weeks. Evaluation and procurement typically adds 4 to 8 weeks. An organization starting its evaluation now completes the migration in early 2027, with a full audit cycle on the new platform before the deadline.

An organization that treats this as a 2027 problem completes the migration under pressure, at or after the deadline, without audit runway.

The difference in outcome is significant. The difference in effort to avoid it is starting the evaluation in 2026 rather than 2027.

What path are organizations currently running SAP IDM leaning toward, and what is driving the decision? The experiences of teams mid-evaluation would be worth hearing.

Tap on the link below to know more:
https://www.openiam.com/soluti....ons/sap-compliance/s