Why is it a strategic move to have a document that describes how the SAP security was addressed in the company?

When is it needed? What is it needed for? Why do it? How do you maintain it?

What is the SAP Security Guideline Document?

It is the document that describes which decisions were taken by the company on SAP Security matters. It can be written during the project or later.

Usually it is divided in various sections that document all things security, for example:

• SAP Users management
• SAP profiling management (Authorization roles, profiles, authorizations, critical authorization objects), change management
• Approval workflows management
• Naming convention of objects (Users, Roles, Custom objects)
• ABAP developments security
• Communication Security (i.e. Cryptography, Single Sign On etc.)
• SAP Instance Profiles management related to SAP security
• Update policies of the systems and SAP patching

It doesn't need to be an ad hoc document called SAP Security Guideline or similar names. It can also be inserted in a general company security document.

Often there are many SAP specifics and it's generally better to create a specific document that describes its aspects in detail.

Is it always possible to create it?

Under many aspects yes, but sometimes it may not be possible. What do I mean with this?

Some SAP Security Configuration aspects can activated and managed at any time. Meanwhile, for example, the naming convention for user IDs or the authorization roles might not be as "documentable".

If in my system there is no single rule for the naming convention of roles or users (but there is one for custom authorization objects and transactions), it might be very hard or even useless to document what is present in the system.

Why is it important to have this document?

Having a document that describes the authorization model defined and its rules becomes a point of importance in this area (also called SAP Security Baseline)

It can be useful also for what concerns the GDPR in terms of accountability of the system.

Think about the following situations:

• You externalize a project realization, which also contains authorizations management. What should the provider do and not do?
  • It's unthinkable to make a handover verbally, it's likely that some concepts or information are lost or not completely understood. A document might help in this matter.
  • The management of these aspects can be carried forward by different people in the company. Having a document helps being aligned on a shared point of reference for the company (and so avoid having to count on people's memory)
  • What's been said above can be also applied to new colleagues. Important: the document should not be a manual, but more like a mix of rules and best practices on how you should behave when facing certain activities/problems/thematic.
  • Each time a new system is released, it is needed for it to follow the company rules and guidelines in terms of SAP security.

For it tu be usable, the document needs to be updated often. Normally, however, few changes are needed after the first definition of the document.

Blog post originally translated from: https://www.aglea.com/blog/sap-security-guidelines