Automated SoD Remediation: From Risk Detection to Resolution

A White Paper by Meylan Technologies & Consulting

Executive Summary

Segregation of Duties (SoD) remediation remains one of the most resource-intensive activities in enterprise risk management. Organizations that invest in detecting access conflicts often struggle with the next step: actually resolving them. A typical first-time risk analysis might reveal 10,000 to 50,000 SoD violations across a production SAP system. At a manual review rate of approximately 15-20 conflicts per day, full remediation represents months or even years of dedicated effort.

MTC Skopos addresses this bottleneck with a built-in remediation engine that generates specific, actionable resolution plans. The engine works through four phases of escalating intervention, always trying the least disruptive fix first. It uses actual system usage data to distinguish between access that matters and access that simply exists, and it validates every recommendation through simulation before presenting it for approval.

On a representative production dataset of 847 users with 12,340 SoD conflicts, the engine resolved 73.1% of conflicts automatically in under five minutes, producing a step-by-step remediation plan ready for implementation.

This white paper explains the technical approach, the business rationale, and the practical outcomes for organizations looking to move beyond risk detection into risk resolution.

The Remediation Gap

The Problem Every GRC Team Faces

Most access risk analysis tools do a reasonable job of detecting SoD conflicts. They can tell you that User JSMITH has both vendor creation and payment processing capabilities, creating a Procure-to-Pay conflict. What they rarely tell you is what to do about it.

The typical remediation workflow looks like this:

1. Run an SoD analysis and receive a list of thousands of conflicts
2. Export the results to a spreadsheet
3. For each conflict, manually investigate which roles contribute to the issue
4. Determine whether the user actually needs the conflicting access
5. Propose a change (remove a role, modify a role, or accept the risk)
6. Verify the proposed change would not break legitimate access for the user or others sharing the same role
7. Re-run the analysis to confirm the conflict is resolved and no new conflicts were introduced

Steps 3 through 7 are repeated for every conflict. Each iteration requires cross-referencing role assignments, composite role structures, authorization objects, usage logs, and organizational context. For a system with complex role hierarchies and thousands of users, this process can take months of a skilled consultant's time.

Why Manual Remediation Falls Short

Manual remediation suffers from several structural limitations:

Scale. The number of conflicts overwhelms the capacity for individual review. An organization with 2,000 SAP users might have 15,000 SoD violations. Even with prioritization, the backlog grows faster than it can be worked through, especially as new user provisioning continues in parallel.

Interdependence. Resolving one conflict can create others. Removing a role from a user may shift their authorization path in ways that trigger different conflicts. Without simulating the full impact of every change, remediation becomes a sequence of fixes and regressions.

Collateral impact. Roles are shared across users. Modifying a role to fix a conflict for one user may remove legitimate access for twenty others. Manual analysis often lacks the visibility to assess this collateral damage systematically.

Inconsistency. Different analysts make different judgment calls. Without a structured approach, the remediation plan depends on who did the analysis and what assumptions they made about usage patterns.

The MTC Skopos Approach

Design Principles

The MTC Skopos remediation engine was built around three principles:

1. Least disruption first. Always try the smallest possible change before escalating to structural modifications. Removing an unused role assignment is preferable to splitting a role. Splitting a role is preferable to redesigning the authorization concept.

2. Usage-driven decisions. Every recommendation is grounded in actual system usage data. The engine distinguishes between access that is actively used and access that merely exists. Unused access is the low-hanging fruit: it represents risk without business value.

3. Validated before proposed. Every recommendation can be simulated to confirm it achieves the intended risk reduction without introducing new conflicts or breaking legitimate access.

The Four-Phase Algorithm

The engine works through four phases, stopping as soon as each individual risk is resolved:

Phase 1: Remove Single Role Assignments

The engine begins with the least disruptive action: removing directly assigned single roles from individual users. For each user with SoD conflicts, it identifies single roles that contribute to the conflict and scores them based on two factors:

• Risk contribution: How many risky actions does the role provide? Higher counts make the role a more attractive candidate for removal.
• Usage overlap: Are all of the user's actively used actions from this role also available through another assigned role? If yes, the role can be safely removed without any business impact.

Only roles where full usage coverage exists through alternative assignments are removed. If the user would lose access to something they actively use, the role is passed to subsequent phases.

Phase 2: Remove Composite Role Assignments

The same logic applies to composite roles. The engine evaluates whether a user's active usage from a composite role is fully covered by other role assignments. Composite roles are scored and processed in order of highest risk reduction with lowest business impact.

Phase 3: Remove Single Roles from Composite Roles

When role assignments cannot be removed at the user level, the engine examines role structures. For each composite role that could not be removed in Phase 2, it evaluates the member single roles and determines whether a specific single role can be removed from the composite.

A single role qualifies for removal from a composite when:

• Its usage across all users assigned to the composite falls below the configured threshold (low execution count AND last execution older than the configured period), OR
• All users who actively use actions from that single role have alternative access through other roles

Because this change affects every user assigned to the composite role, the engine calculates collateral impact before proceeding.

Phase 4: Remove Actions from Roles

When role-level changes are insufficient, the engine modifies permissions within roles. This phase handles both directly assigned single roles and single roles nested within composites.

For roles using SAP's master/derived architecture, the engine operates on the master role while tracking which derived role triggered the analysis.

Three outcomes are possible for each risky action:

Clean removal: If no user across the entire role hierarchy actively uses the action, it is removed from the role. No splitting required.

Role splitting: If some users actively use the action but they represent a small percentage of total role assignments (configurable, default 50%), the engine generates a role split. The action is removed from the original role, a new single role containing only that action is created, and the new role is assigned to users who were actively using it.

Manual review: If active users exceed the collateral impact threshold, no automatic recommendation is generated. The conflict is flagged for human review.

The Role of Usage Data

Usage data is the foundation that makes automated remediation possible. Without knowing who actually uses what, any remediation recommendation is a guess.

MTC Skopos supports two complementary sources of usage data:

• Transaction execution logs (SM20/STAD): Records of which transactions were executed, by whom, and how often
• Change document logs (CDHDR): Records of actual business object modifications, providing evidence of meaningful activity beyond simply opening a transaction

The engine classifies access into two categories:

• Unused: The action has not been executed within the configured period (default: 180 days) or falls below the minimum execution count threshold
• Active: The action meets or exceeds the usage thresholds, indicating the user relies on this access for their work

This classification drives every decision the engine makes. Unused access can be removed with confidence. Active access requires alternative coverage or manual judgment.

Configuration and Flexibility

Different organizations have different risk appetites and business contexts. The remediation engine exposes several configurable parameters:

These parameters allow organizations to tune the engine's behavior to their specific context. A conservative organization preparing for an audit might set a shorter usage period and lower collateral threshold. An organization prioritizing rapid risk reduction might accept higher collateral thresholds.

Validation Through Simulation

Generating recommendations is one thing. Trusting them is another.

The MTC Skopos remediation engine integrates with the platform's simulation capability to validate every recommendation before implementation. The validation workflow operates as follows:

1. The engine generates the full remediation plan
2. All proposed changes are translated into simulation criteria
3. A "what-if" analysis runs against the current authorization state with the proposed modifications applied
4. The simulation confirms that targeted risks are eliminated
5. The simulation verifies that no new risks are introduced
6. The simulation checks that no active access is broken for any user

Only after this validation step is the plan presented for review. If a recommendation would create unintended consequences, it is caught before it reaches a decision-maker.

This approach converts the review process from "analyze whether this change is safe" to "approve a change that has already been validated."

Real-World Results

The following results were achieved on an anonymized production dataset:

Starting environment:

• 847 active users across 312 single roles and 89 composite roles
• 12,340 SoD conflicts identified in the initial analysis
• 6 months of usage data (transaction execution + change documents)

Engine execution time: 4 minutes 12 seconds

Results by phase:

The remaining 3,326 conflicts (26.9%) were flagged for manual review. The majority involved heavily used transactions where the collateral impact threshold was exceeded, exactly the type of decision that requires human judgment and business context.

Post-simulation validation confirmed zero new risks introduced and no active access disrupted for any user.

Business Impact

Time and Cost Reduction

The most immediate impact is on the time required to produce a remediation plan. What traditionally takes weeks or months of consultant analysis, cross-referencing role assignments, usage data, and organizational context, is completed in minutes.

For a consulting engagement, this changes the economics fundamentally. The technical analysis that previously consumed the bulk of a project budget becomes a fraction of it. The same budget can instead be allocated to activities that require human expertise:

• Working with business process owners to validate findings
• Evaluating whether specific risks should be remediated or mitigated
• Designing and documenting mitigating controls
• Training internal teams on sustainable access governance

Iterative Analysis

When generating a remediation plan takes minutes instead of weeks, iterative approaches become practical. Organizations can run multiple scenarios and compare outcomes:

• "What if we remediate only critical risks?"
• "What if we exclude the Finance department from Phase 3 and 4 changes?"
• "What is the impact of lowering the usage period from 180 to 90 days?"

Each scenario produces a complete, validated remediation plan. Decision-makers can compare options rather than committing to a single path.

Audit Readiness

The remediation plan provides auditable documentation: a clear record of what was analyzed, which changes were recommended, why each recommendation was generated, and what simulation confirmed. This documentation supports both internal audit committees and external regulatory reviews.

Reduced Risk of Regression

Manual remediation frequently introduces regressions, fixing one conflict while inadvertently creating another. The simulation-based validation built into MTC Skopos catches these cascading effects before implementation, reducing the cycle of fix-test-revert that plagues manual approaches.

AI-Augmented Remediation

Beyond the built-in algorithm, MTC Skopos supports AI-assisted remediation through its Model Context Protocol (MCP) server. This integration allows AI assistants to access pre-computed analysis results and have informed conversations about remediation strategy.

With MCP, teams can ask natural-language questions grounded in their actual system data:

• "Which Finance risks affect the most users?"
• "If I remove transaction ME21N from role Z_MM_PURCHASING, who is affected?"
• "Explain our Procure-to-Pay risks in terms a CFO would understand"
• "What alternative roles could replace Z_FI_AP for users who only need display access?"

The AI does not replace the remediation engine. It provides an additional interface for exploring results, communicating findings to stakeholders, and generating documentation in business language. The analytical engine remains the source of truth; the AI makes that truth more accessible.

How It Compares

Implementation

The remediation engine is a built-in capability of MTC Skopos. No additional modules, licenses, or infrastructure are required. Organizations already using MTC Skopos for risk analysis can run remediation immediately.

For new implementations, the typical path is:

1. Data extraction: Export user, role, and usage data from SAP (via RFC or ABAP extraction programs) or any ERP via CSV
2. Ruleset configuration: Define or adapt the SoD and critical access rules for your organization
3. Risk analysis: Run the initial SoD analysis to establish the baseline conflict inventory
4. Remediation: Configure thresholds and execute the remediation engine
5. Validation: Review the simulation results and approve the remediation plan
6. Implementation: Execute the approved changes in your SAP system

The entire process from data extraction to a validated remediation plan can be completed in days, not months.

Conclusion

SoD remediation does not need to be a multi-month manual effort. The MTC Skopos remediation engine demonstrates that the bulk of straightforward conflicts, those involving unused access, redundant role assignments, and low-impact role modifications, can be resolved automatically with the right combination of algorithmic rigor and usage data.

The 73% automated resolution rate observed in production environments is not an aspirational target. It reflects the reality that most SoD conflicts stem from accumulated access that is no longer needed. The engine identifies this unused access, proposes its removal, validates the proposal through simulation, and presents a ready-to-implement plan.

The remaining conflicts, those involving actively used access where remediation would affect business operations, are correctly escalated for human review. The goal is not to eliminate human judgment but to focus it where it matters.

For organizations facing audit pressure, regulatory requirements, or simply the desire to reduce their access risk exposure, automated remediation transforms the timeline from months to days and the cost from significant consulting engagements to a tool-assisted process that internal teams can manage independently.

For more information about MTC Skopos and to schedule a demonstration, contact us at info@meylan-tc.com or visit mtcskopos.com.

Meylan Technologies & Consulting Sarl -- Geneva, Switzerland