cancel
Showing results for 
Search instead for 
Did you mean: 

GRC AC 10 ruleset can be referred as SOD matrix

Former Member
0 Kudos

I would like to know is it necessary to have the SOD matrix for maintaining SAP Security in the organization. We have the GRC implemented and we perform the SOD with the help of conflicting reports obtained from GRC. But we do not have any specific SOD matrix maintaned as a process.

Now Auditors are requesting for the SOD to be developed for Business. So my query is, will GRC AC ruleset can be regarded as the SOD matrix or is it necessary to have a seperate.

Thanks.

Accepted Solutions (0)

Answers (2)

Answers (2)

koehntopp
Product and Topic Expert
Product and Topic Expert
0 Kudos

Sameer,

what the auditors are looking for is a business explanation on _why_ you have your rule set built the way you have.

In GRC terms, that is usually the Risk definition, i.e. which two (or more) business functions should not be in the hand of one person in order to implement your company's SoD rules ('rules' meaning the business reason why more than one person should be required to complete a certain business process).

In my view that also includes the definition of risk ownership, suitable mitigations and the attached change management process.

The function definition then is the technical implementation of this, which should also have a change management process of its own to make sure the functions represent the current state of your ERP system as it is implemented (customizing).

The rules are the technical result of the two steps above, generated by the GRC AC software, and should not be relevant at all for the auditors.

Frank.

Former Member
0 Kudos

I agree with Frank's take on the question. in reality the onus of proper housekeeping of the Risk definitions is on the Business (and not the GRC Admin team) and it is justification that Auditors are after rather than a Technical file.

Former Member
0 Kudos

Hello,

I presume the auditors require a Business document (i.e. not just a technical dump from the system) stating the content of the rule set, and importantly documenting the decisions behind recognising the risks within the business. Your Internal Controls team "in theory" should be taking care of this.

However, if no document exists, at least get your technical rule set documented on paper/file (like how any technical solution is documented via a Design/config Document etc).

As to how the business develops this Business document, is up to you (i.e. a text based Design document detailing all the definitions etc and justifications etc etc and embedded matrices etc).

I am sure your auditors may be able to guide you on the type of business documents they accept

All the best.

kevin_tucholke1
Contributor
0 Kudos

To add to what Harinam stated above:

SoD is really based up on task.  Usually when I hear SoD Matrix, the usual thought is down to the ACTION level. 

Depending upon the requirement of the request you have, you could download the Risk List with in AC10, that will show you the RISK ID/Description then the Functions that make up that risk.

For example,

1)  Risk F018 Open closed periods and inappropriately post entries - this contains functions (business tasks) GL01 - Post Journal Entry and FI06 - Maintain Posting Periods.  This can be exported from the Rule Setup Work center and selecting Access Risks under Access Rule Maintenance.

2)  If the request needs to do deepter than that (Action Level), you can utilze the Access Rule Detail Report (under Generated Rules), filter the report on Permission Object S_TCODE, then you will have the acutal actions that would make up the matrix. 

The former of these two should be sufficient as a business level document, the latter will be quite huge and unruly as there are over 58 actions to post a journal entry and 5 actions to Maintain Posting Periods.  The number of combinations would then be 290 (58 x 5).  and that would be for just one of the risks and would increase you have any custom action codes.  I say this as it seems that if you can post a journal entry, why does it matter which of the 58 actions you use to do that, in the end it is still the same effect on the back end tables.

In short, you should be able to utilize SAP Access Control to help build your information.

Thanks,

Kevin Tucholke