As with so much in security, the most important piece of achieving controls around data protection is human: we should ensure that all employees who are dealing with sensitive data understand their responsibilities and the requirements for the protection of said data. An understanding of data and the associated risk ownership in the business is essential for this.
Where is your data right now?
Do you use file sharing? How about pre-production copies of production data?
Ensure that you have a complete understanding of where sensitive data is stored and how it is transmitted and you will understand the scope required for implementation of controls around access to that data. If you have production data stored in non-production systems, then you need to bring those into the scope of your controls framework and may be exposed to clauses in data privacy legislation which require data to only be stored once, for specific processing purposes. Remember that production controls should be applied to production data, wherever it is stored or accessible, this may include management information systems as well.
SAP provide a number of tools to enable you to protect your data, the first of which is incumbent upon your role design, denying access to data for those users whom it is not deemed appropriate. Reporting on the setup of roles and who can access what data is fairly straightforward in standard authorisations, but can be complicated by more complex authorisation solutions, such as structural authorisations in HR.
For example, managers may have access to payroll information to enable MSS functionality through a portal solution, but may not be able to display this information in the backend SAP GUI. Make sure you understand the processes used to access data to avoid spending time and effort on these false-positives.
So, assuming your role design is already limiting access to data appropriately, you may still have concerns around other types of access. For example, confidential data may be extracted from a system and stored offline or on file-shares, how can you work to prevent this?
GRC Access Risk Analysis can help bolster your reporting in this area, permitting the linking of display access to data with the transactions required to misuse that access. A note of caution though – I would recommend any reporting rules set up for monitoring read access should be kept distinct from the rules around segregation of duties, in order to provide clarity of reporting on risks – consider a custom ruleset for specific DP risks.
Read Access Logging allows you to monitor and log read access to data you deem to be sensitive. You can define which data you want to be logged and ensure that monitoring of access can be conducted. The key advantage of RAL is that it should be available to most SAP customers, as long as your BASIS patch-level is up to speed. There is a guide in SAPNote 1969086 to check your compatibility.
UI Logging: While at first glance, this may seem similar to the RAL solution, UI logging provides some additional functionality when dealing with sensitive data, allowing you to see the exact set of data being displayed. Providing reporting cockpits for identification and trace tools of data incidents, it is configurable to determine which users and data logging should be enabled for.
UI Masking: Going further than the UI logging solution, UI masking offers more preventative controls for handling sensitive data. The solution can mask data within the GUI, ensuring that sensitive fields are not displayed. It can be configured to only display data to people with the correct roles defined in the tool, as well as providing audit trails of data requests. Using these tools in conjunction with your role design and increasing organisational awareness of privacy requirements and sensitive data handling, you can help to ensure that your data remains, yours.