SAP SoD programs that pass certification reviews and still produce audit findings. Here is the structural reason why.

The manufacturing compliance team ran the access certification campaign on schedule. Reviewers completed their attestations. The SAP SoD analysis ran clean. The records were documented.

Then the audit produced a finding.

Not because the SoD program failed to detect a conflict within SAP. Because the auditor's scope extended beyond SAP and the governance program's scope did not.

This pattern appears consistently enough in manufacturing audit findings that it is worth naming directly: most manufacturing SoD programs are configured to cover the right risks inside SAP and are structurally unprepared for the audit that tests what sits around SAP.

The configured scope problem

SAP GRC detects conflicts within the SAP role model. It does this well when rule sets are properly configured, and configuring them well is genuinely difficult work that deserves credit when it is done right.

What SAP GRC does not do is analyse whether the same user who holds a standard SAP Accounts Payable role also holds administrative access to the HR system that feeds salary data into payroll. It does not evaluate Active Directory or Entra ID group memberships that determine what those users can access across the enterprise. It does not govern the contractor whose SAP access was provisioned ad hoc six months ago and whose project ended three months ago.

The configured scope and the actual risk scope diverge in most manufacturing environments. The audit finds the gap between them.

The evidence problem underneath the detection problem

There is a second issue that is less often discussed and more consistently responsible for the finding.

Manufacturing companies have access data. SAP exports, Active Directory logs, HR records, ServiceNow tickets. The data that would answer an auditor's questions exists across many systems.

What most manufacturing companies do not have is audit-ready access evidence: a governance record that connects the access to the risk, the risk to the reviewer, the reviewer to the decision, and the decision to the remediation, in a format that does not require manual reconstruction at the point an auditor asks for it.

When the answer to "why did this user hold this access combination" requires correlating an SAP export, a spreadsheet from the last certification campaign, an email thread, and a ServiceNow ticket, the finding is generated not by the conflict but by the inability to demonstrate what happened after the conflict was identified.

Manufacturing does not have an access-data problem. It has an access-evidence problem.

The five questions that separate a mature program from a documented risk

When a conflict surfaces during an audit, five questions determine whether it becomes a reportable deficiency or a documented exception.

What access did this user hold, and when? Was this access flagged as a risk, at the transaction code level, mapped to a control objective? Who reviewed it, and when? What was decided, whether remediation or accepted risk with a compensating control? What happened after the decision, and is the evidence of that outcome timestamped and retrievable?

A program that can answer all five, across SAP and every connected system, does not eliminate audit findings. It changes what the auditor finds from a governance architecture problem to individual exceptions. That is a fundamentally different conversation to have in the audit room.

What the scope expansion actually requires

Closing the gap requires three disciplines operating simultaneously. Preventive controls that evaluate SoD risk before conflicting access is assigned. Detective controls that scan continuously across all connected systems and not just within SAP on a quarterly schedule. And evidence that connects both disciplines to a single retrievable governance record showing what was found, who reviewed it, what was decided, and what action was taken.

None of these three requires replacing an existing SAP GRC investment. They require extending the governance perimeter beyond the SAP boundary that the existing investment was designed to cover.

The audit was never just SAP. The governance program needs to reflect that.

What is the most common SoD audit finding manufacturing compliance teams are encountering right now? The experiences of teams working through this would be worth hearing.

The Access Review Problem Manufacturing Auditors Are Not Telling You About

Every manufacturing company running under SOX, ISO 27001, or internal risk governance requirements has a formal access review program. Managers receive lists of users and roles. They review them, sign off, and return the completed sheets. The tick box is ticked. The audit cycle closes.

The problem is that most of these access reviews manufacturing compliance teams run are producing compliance theater — the appearance of a control without the substance of one. And auditors are beginning to look more closely.

What a real access review is supposed to do

The purpose of access reviews manufacturing organizations conduct is not to confirm that a list of users exists. It is to confirm that every user's access is still appropriate for their current role — and to produce documented evidence that inappropriate access was identified, acted on, and removed. The user access review manufacturing compliance teams run is the cornerstone of manufacturing access certification programs — and it is failing at scale.

That means reviewers need to see more than role names. They need to see whether a user's combination of roles creates a Segregation of Duties conflict. They need to see whether the user transferred plants six months ago and their access was never updated. They need to see whether the account belongs to a contractor whose engagement ended before the review cycle opened. They need to see the full access profile — SAP roles, directory group memberships, plant application permissions — in a single view.

A spreadsheet cannot show any of that. It shows role names. And role names, without context, are not reviewable in any meaningful sense.

The reviewer problem is a design problem

Access review failures manufacturing compliance teams encounter consistently trace back to the same root cause: reviewers are being asked to make decisions without the information needed to make them well.

A production manager reviewing a list of SAP role identifiers — technical strings like "MM_BUYER_SENIOR" or "FI_AP_CLERK" — cannot determine from the name alone whether the combination creates fraud risk. Most managers do what any rational person would do when asked to approve something they do not understand: they approve it. Not because they are careless, but because the review process has given them no basis for doing otherwise.

This is the rubber-stamp problem, and it is endemic to spreadsheet access reviews manufacturing environments rely on. The SAP access review spreadsheet is the most common artifact manufacturing IAM teams produce — and the least useful one for proving that a meaningful review took place. The solution is not to train managers harder. It is to design reviews that present access with the context that makes a meaningful decision possible — the business function of the role, the SoD conflicts it creates with other access the user holds, the user's current HR status, and the lifecycle history behind the access.

Why manufacturing makes this harder

Access reviews manufacturing organizations in other industries run are already difficult. Manufacturing amplifies every weakness.

Multi-plant operations mean users change roles, move between facilities, and take on temporary responsibilities constantly. A quarterly review cycle catches a fraction of these changes. The access that becomes inappropriate in January may not be reviewed until Q3 — six months of exposure that a well-designed review program would catch in real time through event-triggered reviews connected to HR lifecycle events.

Contractor populations are large, transient, and frequently mismanaged. Manufacturing plants operate with significant non-employee workforces whose access grants often outlast their engagements. Spreadsheet reviews treat contractors as rows in a list, with no mechanism for triggered review at contract end or automatic expiration when no sponsor confirms the access is still needed.

SAP environments in manufacturing are deep and cross-functional. The risk does not live at the role level — it lives at the authorization-object level, in cross-functional combinations that span procurement, finance, production, and quality management. A spreadsheet that lists role names cannot surface this risk. A reviewer who cannot see it cannot act on it.

And manufacturing audit scope has expanded. Auditors now test access governance across SAP, Active Directory, ServiceNow, HR systems, and plant applications. Access reviews manufacturing compliance programs produce need to cover all of these in a single evidence trail. Spreadsheet reviews run system by system, producing disconnected artifacts that require manual reconstruction when an examiner asks for the full picture.

What audit-ready access reviews actually require

The alternative is not a better spreadsheet. It is a governed access review process manufacturing compliance programs can actually defend — built around four principles that spreadsheets cannot support.

Context at the point of decision. Reviewers see access presented with the information needed to evaluate it — what the role does, what conflict it creates, what the user's current HR status is, and whether the access has been reviewed before.

Event-driven triggers. Automated access reviews manufacturing organizations implement catch risk in real time. Access reviews manufacturing compliance programs run on schedules miss lifecycle events. The right program triggers reviews when something changes — a plant transfer, a role change, a termination, a contractor expiration — not just when the calendar says it is time.

Remediation tracking. When a reviewer marks access for revocation, the system tracks that action to completion. A timestamp confirms when access was removed. An auditor who asks whether access was revoked has a record, not a verbal assurance.

Unified audit evidence. Every decision — approve, revoke, accept risk, document compensating control — is retained in a single governed record. Manufacturing compliance access reviews that produce this kind of trail give compliance teams something they can stand behind. Access recertification manufacturing programs built on this model satisfy the examiner's question — not just the tick box. User access certification SAP manufacturing teams need to run must produce this chain of evidence or it will not hold up when tested.

Manufacturing companies that build access reviews around these principles produce something a spreadsheet-based program never can: a defensible record that an auditor can examine and a compliance team can stand behind.

The access review problem in manufacturing is not that companies are skipping reviews. It is that most reviews are not designed to find what they are supposed to find — and are not producing the evidence that proves what was done when they did.

For a detailed breakdown of why access review failures manufacturing teams experience are structural rather than accidental — and what a meaningful access review process looks like in practice — the full analysis is here: Why Spreadsheet Access Reviews Fail Manufacturing Teams.
https://www.openiam.com/blog/s....preadsheet-access-re

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