cancel
Showing results for 
Search instead for 
Did you mean: 

Risk SO20: Function SD04 - Sales Document Release and Function SD05 – Sales Order Processing

0 Kudos

Dear Friends, We recently updated our rule-set and we are now trying to re-mediate the SoD's for TCodes conflicting with themselves especially VA02 to start with.

We have roles which are in conflict within themselves ( Risk SO20: Function SD04 - Sales Document Release and Function SD05 – Sales Order Processing )

  • With transaction code VA02 (Change Sales Order) conflicts are in - between two function SD04 (Sales Document Release) and SD05 (Sales Order Processing). Primarily because of two reasons: -
  • In V_VBAK_AAT (Sales Document: Authorization for Sales Document Types),
  • ACTVT43 (Release) from function SD04 (Sales Document Release) is in conflict with ACTVT 24,24,C1 and C3 from function SD05 (Sales Order Processing).

Or

  • ACTVT43 (Release) from function SD04 (Sales Document Release) is in conflict with AUART (Sales Document Type’s) from function SD05(Sales Order Processing).

Technically we have these options: -

  • Option 1: - Uncheck 43 in the security role VIA PFCG – Which cannot be done.
  • Option 2: - Uncheck 24,25,C1,C3 in the security role VIA PFCG – Which cannot be done.
  • Option 3: - Uncheck Sales Document Type in the security role VAI PFCG – Which cannot be done.
  • Option 4: - Remove VA02 from the security role VIA PFCG – Which cannot be done.
  • Option 5: - In - Activate ACTVT 43 from SD04 at Permission Level in GRC rule set.
  • Option 6: - In - Activate ACTVT 24,25,C1,C3 from SD04 at Permission Level in GRC rule set.
  • Option 7: - In - Activate conflicting Sales Document Types [ in AUART ] from SD05 at Permission Level in GRC rule set.
  • Option 8: - Apply mitigation control as suggested in SNOTE: - 1600667 for SD04 and SD05 conflicts.

Could you please advice your suggested option [ 5,6,7,8 ] which should be considered and selected.

Will it be Option 5 or Option 6 or Option 7 or Option 8.

Thanks

Raj

Accepted Solutions (0)

Answers (1)

Answers (1)

alessandr0
Active Contributor
0 Kudos

Raj,

if you have a risk and that risk is validated in your business, you cannot just change the risk definition to falsely "remediate" your violations. In case a violation exist, then you have to either remediate the violations by changing your roles, or to find an alternative to mitigate the violations. In any case, however, you definitely don't want to change the risk definitions without proper approval from your business. Please note that once you must be SOX compliant, all these changes must be approved, tested and validated.

There are a few documents out there that are worth reading:

https://blogs.sap.com/2014/08/21/remediating-access-control-sod-risks/

https://blogs.sap.com/2014/09/01/sod-management-process/

https://blogs.sap.com/2014/07/15/internal-controls-a-step-towards-strong-controls/

Hope this helps.

Regards, Alessandro