SoD Analyzer Tools for SAP

SoD Management Has Two Phases

Segregation of Duties is a lifecycle, not a purchase. The phases have very different tooling requirements and very different costs.

Figure 1 · The SoD management lifecycle and the capability requirement at each phase

Phase 1 · Risk Identification. 

Adopt a ruleset of conflicting function pairs, analyze users and roles against it at transaction and authorization-object level, and produce a ranked, owned conflict inventory. The requirement here is an analysis engine and a ruleset. Nothing more. The detection logic is a set of joins across authorization tables evaluated against a conflict matrix, and nothing about it is proprietary.

Phase 2 · Risk Addressal. 

Every conflict requires one of two decisions.

• Remediate - redesign the role, split the function, remove or org-restrict the access. A one-time cost. Once the conflict leaves the role it stops consuming attention.
• Mitigate - accept the conflict against a compensating control with a named owner, a monitoring frequency, and retained evidence. A perpetual cost, operated and evidenced every period, indefinitely.

Phase 3 · Sustained Control. 

Preventive checks at the point of provisioning, periodic access review campaigns, and ruleset maintenance as the transaction and app inventory changes.

Two points follow. Phase 1 findings determine the Phase 2 scope, and the Phase 2 scope determines what Phase 3 requires, so completing the assessment before selecting a tool produces a better-specified requirement. And because mitigation carries a permanent evidence obligation where remediation does not, the remediate-or-mitigate decision warrants deliberate governance regardless of which tooling model an organization adopts.

What ZSecTools Does

The application runs outside the SAP stack as a local browser application with its own database, connecting over RFC. Nothing is transported into the landscape, which means no add-on, no Basis change window, and no upgrade regression exposure.

Functionally it covers connection management for multiple SAP systems, extraction of the authorization tables and user usage statistics the tool depends on, a library of prebuilt security quality reports, batch RFC execution for mass user and role maintenance, and SoD analysis at user or role level against a selectable ruleset with CSV export of results.

Two design choices carry disproportionate value. The rule matrix import layout follows a documented industry format, so a ruleset held in spreadsheet form, including one supplied by an external auditor or a prior assessment, can be mapped in rather than rebuilt. And extracted tables can be exported and re-imported as flat files, which permits a fully offline analysis workflow where a live connection to production is not permitted.

What ZSecTools Does Not Do

It supplies no ruleset content. It supplies a container and a layout. Building conflict definitions across the core process cycles at transaction and object level is a specialist effort measured in weeks, and it recurs as the estate changes. This is the real cost of any SoD capability, free or licensed.

The engine is uncertified. The maintainer states directly that results should be treated as indicative rather than authoritative and that critical findings must be validated before being relied upon for compliance or audit purposes. That disclosure is a mark of the author’s integrity and it is also a hard constraint.

There is no mitigation register, no workflow, and no evidence trail. Findings export to CSV. Everything in Phase 2 mitigation and Phase 3 is manual.

It is early. A single maintainer, no tagged releases, a short commit history, and documented gaps in the interface and settings handling. Adopters should fork to an internal repository and accept internal code ownership.

It moves authorization data outside SAP. The tool requires an RFC service user with broad table-read capability and holds a copy of the authorization model and usage statistics in an external database. Both points require documented risk acceptance, and the pilot belongs in a sandbox rather than production.

Expert Recommendation

Complete Phase 1 before buying anything. An organization that cannot state its conflict count, name the owner of that number, and say which conflicts will be remediated rather than mitigated is still in risk identification. At this stage the gating activities are ruleset curation and business engagement rather than software capability. Free tooling is adequate to produce the inventory, and the requirement for anything further is best specified from the findings.

Treat the ruleset as the asset and the tool as disposable. Rulesets outlive tools. Curate one, own it, keep it in a portable format, and assign a named maintainer with an annual review date. Any analysis engine can then be swapped without loss.

Remediate by default and mitigate by exception. Every mitigation is a permanent operating commitment carrying an owner, a frequency, and period evidence. Organizations that default to mitigation accumulate registers that become difficult to sustain manually, and a large mitigation population is a legitimate and well-understood reason to license register and evidence capability.

Recognize what licensed capability provides. Platforms in this category supply maintained rule content, mitigation and evidence management, provisioning integration, review campaign machinery, and a support relationship with defined accountability. These are substantive capabilities and they are the reason the category exists. The question for any organization is which of them its current phase requires, not whether they carry value.

Validate before relying. Test a meaningful sample of findings against an independent method before any result reaches management or an auditor. This applies to uncertified tooling without exception, and the conclusion belongs to the organization rather than to the tool.

References:

SAP Community blog - https://community.sap.com/t5/technology-blog-posts-by-members/automating-sap-security-tasks-and-sod-analysis-with-zsectools-open-source/ba-p/14443450

Closing Perspective

Detection is the most tractable part of Segregation of Duties. The harder parts are maintaining a risk library that survives an S/4HANA transition, producing evidence that withstands audit testing, and carrying accountability for the conclusion. Licensed platforms exist because those things are genuinely difficult and genuinely valuable, and the useful distinction is therefore not free against paid but requirement against capability.

The sequence matters more than the product. Establish the requirement, complete risk identification, decide remediation against mitigation on the evidence, then acquire the specific capability the remaining phases call for. Organizations that work in that order specify better, spend proportionately, and are not left holding capability that arrived ahead of the need for it.