When you’re facing an unhappy auditor, GRC requirements can seem arbitrary and unfair, however, they’re actually some of the most carefully designed, systematic rules. GRC controls — Segregation of Duties (SoD) in particular — are there to protect your business, as well as your investors and customers. SoD and other access control measures are what stop bad actors from defrauding your company and covering their tracks. They are what prevent sloppy processes from exposing you to unnecessary risks and liabilities.
SAP GRC is really just another necessity of modern business, like encryption or security monitoring — and like those controls, it can be baked in and largely automated so that it doesn’t get in the way of doing business. Your system can check literally every task your employees do in SAP, without creating extra work.
Unfortunately, SAP GRC is designed around the way users traditionally perform tasks through SAP GUI. With SAP Fiori, there’s a danger of false negatives around SoD conflicts. Here’s how to ensure your SAP Fiori solution for access control doesn’t miss SoD issues.
SAP Fiori Changes How SAP Access Control Works
In SAP GUI users perform tasks via transactions. Users can either select a particular transaction via the menu, or enter the transaction code as a shortcut. SAP GRC checks transactions against a list of SoD conflicts. This helps protect against fraud by catching combinations of actions that could enable fraud.
For example, if a user is allowed to create a vendor and pay a vendor, that user could abuse that power to create a fictitious vendor, which they could use to funnel money out of the company. It also helps reduce accuracy risks by catching situations that shortcut needed checks — for example, by preventing managers from signing off on their own work.
Automatically detecting these SoD conflicts allows companies to either remedy them, or put in mitigating controls when directly remedying them isn’t possible.
SAP Fiori, on the other hand, doesn’t use transactions — it uses service authorizations. The user may be doing the exact same tasks, like creating a vendor, but because it doesn’t create transaction start authorizations, most SAP GRC solutions aren’t actually able to watch for SoD conflicts.
Manual SAP Fiori SoD Remediation
To screen accurately for SoD conflicts, your SAP GRC solution needs to be checking both transaction start authorizations (which it already does) and service authorizations (which it probably doesn’t).
However, service authorizations output hash values — character codes that correspond to services. It’s possible to add these codes to your rulebook, creating an ad-hoc SAP Fiori solution for access control, but it will be challenging.
Hash values are potentially system-specific, which can make them extremely difficult to connect to services. Additionally, manually recreating a complex set of SAP GUI checks in Fiori can introduce dangerous errors or inconsistencies, which makes maintaining GRC more complicated going forward.
ControlPanelGRC — a True SAP Fiori Solution for Access Control
ControlpanelGRC is the first SAP GRC solution that works across both Fiori and SAP GUI. Rather than painstakingly rebuilding your SAP SoD rules in Fiori, you can plug in a single solution that works across your entire landscape.
Instead of worrying about false negatives, inconsistent security rules, or complex maintenance you can depend on your SAP Access Control Suite to continually protect your business and address your compliance needs.