Global privacy laws
As of October 2023, there have been around 20 revised privacy laws which have been enacted throughout the globe:
- GDPR in Europe
- CCPA (California)
- CPA (Colorado)
- CTDPA (Connecticut)
- CDPA (Indiana and Montana)
- ICDPA (Iowa)
- TIPA (Tennessee)
- TDPSA (Texas)
- UCPA (Utah)
- VCDPA (Virginia)
- POPIA in South Africa
- PDPA in Thailand
- LGPD in Brazil
- PIPA in South Korea and Japan
- NZPA in New Zealand
- PIPEDA in Canada
Also currently in proactive review is the DPDP Act in India, and the Federal Act on Data Protection in Switzerland is nearly passed. Federal laws to cover Canada, USA and Australia continue to be debated and are probably inevitable.
Each law is distinct, and contains its own intricacies; however, general themes for consideration in the digital world include big data, individual privacy rights and accountability. One of the most important is the focus on the individual’s sovereignty, rather than on the data storage location; for example, a European citizen is covered by the GDPR when doing business or being employed anywhere in the world.
This does of course generate some interesting international law questions, but I am going to steer away from these legal concepts, and focus on the practicalities for an IT team when adapting processes and creating retention periods for data within a living Production landscape.
I’ve given a quick overview below of some of the core tenets which apply to each of these laws.
| Privacy item | Explanation |
|---|---|
| Accountability | Every company is initially responsible for appointing a Data Protection Officer who is ultimately legally responsible for privacy within their business. In addition, clear definitions of Data Processors are made, keeping accountability within each company for the data they accept from other sources or move on to other related businesses. |
| Right to Access | This is often referred to as a Subject Access Request (SAR or DSAR). It requires any Data Processor to be able to search and identify a Data Subject within their business estate, and provide a summary of all Personally Identifiable Information (PII) held for them. A comprehensive report must be produced within a fixed period; some differences exist between the laws, but generally 28 days / 1 month is referenced. |
| Right to Deletion | A key addition to many of the privacy laws is the Right to be Forgotten or Right to Correction/Deletion. Here the onus of proving a legal justification for the PII data held within a business falls on the business; if no justification can be made, then every Data Subject has the right to request it is removed. From a technical viewpoint, the definition of ‘deletion’ is not explicit, and this is therefore open to your legal team’s review. However, deletion is a challenge in many Relational database types. In this document, I will explore the options available and my recommendations. |
| Right to Portability | This is similar to the Right to Access. However, as opposed to the Subject Access Request, this defines the need to be able to extract all personal information to be shared between businesses at the request of a Data Subject. As such, this data must be in a common readable format that can be processed by different businesses. Although not explicit in some of the laws, there is an additional requirement to have sufficient checks and procedures around such a file-share to protect the individual. |
| Proactive privacy management | An essential item for consideration by all businesses, this enforces the need to create retention policies for your data, including proactively identifying Data Subjects (and their related data) where organisations no longer have the legal justification to maintain that information, and processing data removal. |
| Cross-border data access | Often referred to under the banner of Schrems II (although this is specific for EU -US data transfer) this deals with the scenario of sharing data between legal jurisdictions. A simple scenario we often come across is employee data which is being managed centrally in one office for a multinational business. These articles define allowable data transfer. This can raise a particular challenge, as businesses want the advantage of a single HR and Payroll technical solution, but then also need to ensure that only relevant users can access specific datasets. |
There are more areas of commonality in privacy laws; however, for the purposes of this guide, these are the main areas I have focused on.
One of the most compelling reasons for data privacy compliance is the enforcement fines; the new laws provide for far higher financial sanctions to be applied by the legal bodies, as in the examples shown below.
How to get started
Every business is different and will have their own unique challenges; there is no ‘silver bullet’ which will solve all your data privacy challenges.
I’d suggest being careful of any company offering ‘out of the box compliance’; there are some great accelerators on the market, but any processes always need to be implemented and customised to your specific business.
This point is of even greater importance when reviewing technical solutions for SAP. For example, there are providers claiming AI and Machine Learning (ML) solutions which can automatically identify PII in your environment. While pattern-matching ML may be able to find table fields where data is mapped, it can’t understand the referential integrity of the SAP database. At best, this will mean that data scrambling or removal won’t be consistent or complete; at worst, this will break the SAP system by creating missing data in the referential chain. As such, when reviewing solution options, I would recommend selecting specialist providers with available references in similar industries and system types to the systems you are running.
Having said that, the actual implementation approach can be standardised into a few essential steps, no matter the technology or industry. What you do in each step will be very different depending on your situation. At EPI-USE Labs, we call this ‘the road to data privacy compliance’. In this document, I explore each of these steps in more detail.
A final thought: don’t underestimate the importance of a solid requirements gathering phase, with clear scope for all involved. You will undoubtedly have unforeseen impacts and changes to manage by implementing software which will effectively delete data from your Production system. This can become very costly and extend your timelines. If you include as many decision-makers as possible in the blueprint of the project, and get sign-off for the delivery upfront, this will ease your route to going live.
Essential steps for implementation
1) Identify your risks: Impact and risk assessment
Getting this and the next step right are what will set you up for success moving forward.
Risks outside of IT?
Before I focus on the technical IT assessment requirement, remember that the privacy project will not be solely focused on IT, but also needs to consider the people and business process elements of running your company.
For example, two common scenarios I have seen at multiple clients:
| Scenario 1 Front office staff dealing with customers |
Scenario 2 Visiting an office |
|---|---|
|
When I worked in a contact centre many years ago, I would regularly use a notepad to record pertinent details of calls taken, marking down identifiers, accounts numbers, telephone numbers (in case the call drops), etc.; keeping the call short and completing the admin of entering this data after the call. I would then regularly put the notepad in my bag at the end of shift, and take the bus home. What would have happened if I left that notepad on the bus? The overall data privacy and security process needs to consider confidential waste disposal, VPN/MFA devices and more. |
When I visit our client sites, I will regularly have an image taken of myself for an access badge, and might be requested for proof of ID, which will be copied and stored. What is the legally justified period to keep these records? My least favourite is the very common site sign-in book, an open register which anyone can access, in which every person visiting is requested to enter their name, company, car registration and contact telephone number. The whole book could be stolen, or images taken of different pages, causing a breach under the privacy laws. Of course, each company would need to keep a record for a period of time in case of incident. However, could a paper book be replaced with digital sign-in? Can retention periods be set against this data? |
It is often actually easier to define and control the IT estate within the bounds of the privacy laws, and it should be a primary focus. But it’s important for all privacy professionals to realise that you can’t focus only on fixing IT systems and be compliant with the legislation.
Your IT estate: participants in this phase
Regarding the IT estate, the best run projects I have seen have involved these participants in this phase:
- The named Data Protection Officer
- Legal and compliance teams
- Internal audit teams (if available)
- Testing data/Process owners
- Production data/Process owners
- IT and Infrastructure teams
The Data Protection Officer (DPO) is essential to solve stalemate situations between the business and compliance. The officer should have the seniority to be able to make these decisions when needed. I have seen projects where the blueprint phase was less successful, and our client’s ‘lesson learnt’ after the project identified the need to have the DPO involved early, to enforce the need for data anonymisation. Functional teams in general will not want to remove any data ‘just in case’ the customer was to return.
Legal and compliance teams have two key activities during this phase. The first is to give input on the privacy laws which the different parts of the business will be subject too. Of equal importance is the view on other regulations that impact the privacy laws. A common example is Taxation laws, which have strict guidelines on the length of time for which businesses are required to keep records from financial transactions. Understanding these additional compliance and legal requirements will drive the identification of your data retention framework.
Audit teams are a valuable addition; they understand what they would be checking under an audit to provide sign-off. Involving them early can avoid costly project upsets later down the line.
Testing owners are pivotal. Every business running SAP has copies of Production data provided to be able to test process changes, system updates or new functionalities before impacting the Production system. The process is essential for every business. As most businesses have gathered both informed and explicit consent to use their employee, customer and supplier data for testing, this now needs to be carefully managed. A clear understanding of the impacts of data scrambling will be needed to develop a design which is both compliant and has the least impact.
Similarly, the Production process owners will need to advise on the impacts of data removal to be compliant. Sometimes this creates a business justification which the legal and compliance team can argue into the company retention design. Alternatively, there may be process changes which need to be managed to meet the compliance requirements, and these owners will be responsible for moving these forward concurrently with the technical solutions implementation.
The IT and Infrastructure team’s role during this stage is to advise of data transfer via interface between systems and key integrations. For example, where an email address is used in the interface to a web client solution, what are the technical options to continue to test this process but without ‘real’ email addresses? They will also give guidance into how data is transferred: is it pushed from one system or pulled from the other? This can define the complexity of the required solution. Where data is pulled from the single system of record to secondary systems, you only need to update the “master” system and these change will inherit to integrated systems. Whereas if it is pushed, a new job or interface to trigger updates may be required to achieve the same effect, which increases complexity.
Priority and level of risk
One of the best outputs for the technical analysis I’ve seen was laid out as a system architecture map with ‘traffic lights’ to show the priority and level of risk:
With this landscape view, you are ready to prioritise and identify the vendors who can best support you on the privacy journey, focusing on the Red (Priority 1) systems from your initial assessment.
2) Find and map your PII
This is a critical first step to compliance, especially for markets where the privacy laws are new. Finding and mapping your Personally Identifiable Information (PII) allows you to demonstrate to your auditors/compliancy bodies that you have a clear understanding of the PII risk in your environment, and a plan to resolution. We have noticed at many clients in Europe that in cases where the client could prove they had started the process, the governing body would give the time to resolve the issue; whereas companies ignoring the issue completely have been more likely to be fined.
For an SAP system, the standard delivered data model is fairly complex. For example, a common business scenario could be as follows:
- You have an Employee in your environment, where you will capture the name, contact details, pay information, ID numbers, next of kin data and more, all populated into the employee ‘Infotype’ tables.
- That Employee works on a project for your business. During this time, the Employee travels and incurs some expenses against the project. So, their data is replicated into the Vendor tables in SAP.
- Due to the finance set-up or version of SAP you are running, the same details are also replicated to a Business Partner Object.
- This same Employee purchases something from your business and therefore becomes a Customer. Again, the personal details of name, address, telephone, bank details will be stored into another set of tables.
- The resulting interrelated web of tables and fields containing PII easily stretches into thousands of technical locations.
- The privacy law considers the Data Subject as a single being, not that they exist as an Employee or a Vendor or a Customer. If you have a Right to Deletion request, you have to be certain of the whole Data Subject’s relevance for retention to make your decision.
This scenario explains one of the cases in which AI and Machine Learning cannot effectively manage SAP data for privacy; you need specific domain knowledge built into your software to achieve complete and consistent data removal.
Click on image below to enlarge
What about customisations in SAP?
Most companies will have customised their SAP instance over the years to have specific processes that function the way they need them to for their industry and business. In SAP, these are called Z or Y tables. You can also purchase add-ons which provide their own tables and fields which may contain PII (these will always start with a / in other words: /addon/table).
So how can you map and understand all of this?
As SAP data management specialists, EPI-USE Labs has already mapped the standard SAP tables and Object integrations, both within one SAP system, and also between multiple SAP systems. Having completed consistent data copies for over two decades, we have the domain knowledge of the SAP solution to be able to accurately simplify and accelerate your mapping process.
We have designed an SAP-specific data privacy assessment service, where we use the domain knowledge along with software written for this purpose to analyse the dictionary of tables and fields in your environment and highlight the fields which possibly contain PII. Manual analysis of the results is completed, and workshops held with the same key stakeholders from the Impact and Risk Assessment to define the approach to compliance in both Production and non-production per type of PII.
More information on this service is available on our website.
The output of this project phase would be a technical and functional specification of the PII risk and locations in your specific SAP instance. It includes both the business requirement of how data will be handled in the different SAP environments, and the technical PII map of sensitive data types. I recommend this document is also shared with your audit teams. Following sign-off, you can move forward to the next phase of analysis.
3) Review access risk and controls
Now that you know where the PII is in your SAP system, the first control that can be put in place is user authorisation and access control, restricting who can access PII, and ensuring that access is justified. Many businesses already have some GRC (Governance, Risk management and Compliance) processes; however historically these will have been aimed at Segregation of Duties (SoD) and potential fraud. These new data privacy laws require PII access risks to be added to the mix.
You now need to consider who can access the different types of PII; for example, ensuring that non-HR staff can’t access HR details; and that HR staff can’t access financial information. In addition, you need to consider access to the same functional data being available from different geographical locations, and the impacts of the local privacy laws on that access.
Partnership with Soterion: solving GRC for SAP
EPI-USE Labs formed a close partnership with Soterion whose compliance software solves GRC for SAP® clients. Traditional SAP GRC appliances are not built to be adjusted easily; but Soterion can provide accelerators on a fully customisable platform. Our partnership brings together powerful complementary solutions, knowledge and experience, to help our clients address compliance with global data privacy legislation.
Similar to PII mapping, the starting point needs to be mapping who can access what. Soterion’s solutions allow you to get a first look, with a download of authorisation data and logs which will be uploaded to your own instance of Soterion. The accelerator rulesets which are pre-configured in the software are executed, providing an initial view of risks.
Soterion provide delivered rulesets to cater for:
| Privacy data access risks | Segregation of Duties (SoD) | Cross-legal jurisdiction data access | Critical transaction risk |
|---|---|---|---|
|
Most GRC solutions are focused on segregation of duties and fraud avoidance. Soterion performs these functions, and also has built a ruleset to analyze who has access to PII data. |
Who has access to both submit and approve payments, for example? Soterion will identify all the users who hold conflicting access in the system. |
Can your users from the US access European employee and customer data, or vice versa? If yes, which users would be affected in creating a Data Shield? |
Who has direct access for table maintenance, or can run programs directly? Is Vendor and Customer maintenance restricted to the correct people? |
Once the initial assessment is complete, you need to start the process of cleaning up these risks. With the differentiation of Potential versus Actual risks, you have a clear starting point to reduce your Potential risks. These users have authorisations that they never use, so you can look at removing superfluous roles.
Actual risks require a more detailed analysis. To effectively redesign these authorisations, engaging with the business is essential. I recommend an iterative project, prioritising groups of users in similar functional areas with the same identified risks; then reviewing the role structures and allocations, and redesigning the authorisation model to remove the risks. Soterion can help with Role Simulations, confirming the impact on risks of the changes you make before you make them.
Through this controlled roll-out, you can provide sufficient change control points and a clear compliance plan for access risk management.
EPI-USE Labs’ clients who have used Soterion solutions complete the implementation of the software within a week to identify the risk. They then model their longer-running role redesign project according to their needs. With a plan in place to tackle risks, and active management in place, you can achieve control and improve your compliancy standing after the one-week implementation.
4) Clean up the backlog in Production
Clients who have been running SAP for multiple years have been actively collecting data for all that time, and storing it. In most cases, you will find that all that Production data has been copied into multiple copies for development, testing or training purposes.
When GDPR first launched in Europe, our approach was to suggest that you would tackle the Production copies first, thus reducing the target. This is still an option; but after working with our clients, we realised that the first priority should be getting Production under control. That way, the next time a copy is taken, it will already be more compliant throughout the landscape.
I recommend running a System and Landscape Optimisation (SLO) project. There are two main approaches to these clean-ups:
- SAP Infrastructure Lifecycle Manager (ILM): Provided by SAP, this will create a deletion job for the whole record and all related data.
- Data Redaction (from EPI-USE Labs): Our proprietary software is built to selectively remove just the PII from a record, leaving the referential integrity of the record intact, including your business financial records.
SAP ILM (7.02) was released in 2011, intended as an archiving tooling for SAP data. Once GDPR went live in 2018, it was announced as the GDPR solution too.
Remove or redact data?
Because of the referential integrity of the SAP solution, it is not possible to simply remove just a Customer or Vendor from a finance system. Using ILM, you must remove the Customer and all associated sales/finance data, otherwise you create a system consistency issue.
Believing that you would then lose valuable business data to avoid errors, we designed the Redaction functionality, where the Customer record remains with all its associated transactions, but the sensitive PII data has been removed or replaced with a clearly demarked value. The resulting record would be similar to this:
With the Redaction approach, you can also have different retention periods for different timelines, rather than a full deletion.
To achieve the Production clean-up, there are two policies to review:
- Data Retention Policy – defining which data should be removed after which time periods. This can be individual data per table, or a list for core Data Subjects – i.e., Employees, Customers or Vendors.
- Data Redaction Policy – defining per table field what action should be taken when the retention period is triggered.
>For the initial clean-up, I recommend that the business takes responsibility for defining the list of Data Subjects to be removed. We would provide a technical retention report to define the initial input list based on the business requirements. The client is then responsible for validation and business sign-off of the list for removal.
EPI-USE Labs provides the Data Transform platform with pre-delivered accelerator policies for the standard SAP data in scope, which can be fully extended to customised needs.
Typically, I recommend at least three test cycles:
- Unit testing – to be completed by EPI-USE Labs to confirm requirement to output confirmation.
- Acceptance testing – both positive and negative testing; confirmation that the request data has been removed, but also that more data than is needed hasn’t been removed.
- Integration and regression testing – Confirmation that the removed data has not impacted any inter-system connectivity or processes adversely.
The second and third test cycles would be the responsibility of the business.
This first clean-up is recommended to be run as a full Production cut-over, with back-up restore options, clear process controls and tracking in place. Having run many such cutovers in my career, I can’t emphasise strongly enough the advantages of a full-dress rehearsal of activities to iron out an hour-by-hour cut-over plan.
5) Manage PII in Production copies
Following changes such as tax year changes to Payroll, new processes and developments, system upgrades, or re-platforming, a business needs to make sure their processes still function without impacting the effective running of the business.
To do this, full copies of the Production databases will often be taken throughout a year, and all data replicated into Development, Quality and pre-Production systems. Many clients will also have a training instance or separate long-term project track of SAP instances. This means the Production data has been proliferated into multiple additional systems with different use-cases for the data captured.
Informed and explicit consent of testing data?
Most of the data privacy laws refer to the need for informed and explicit consent for the use case of the data you capture as a business. Most companies have not gathered this consent for using the data for testing. Even if you did decide to go down this route, and contact all Employees, Customers and Suppliers to gather terms for consent, there is still the problem of non-consent. For instance, if you have 10,000 Customers, and 100 refuse consent, if your only option is to copy the full database, you now can no longer take copies from Production.
Some software vendors on the market offer solutions which provide masking (sometimes referred to as User Interface (UI) Masking). This is where the data remains unchanged in the database, but an interception is completed when users try to access the data through the UI and either cypher or restrict visibility of PII. The issue with UI masking is that any access to the database directly doesn’t go through the UI, as such no interception can occur. Usually, external data breaches and ransomware attacks would not use the UI, but make use of direct server access once network protections are breached. For this reason, personally I do not believe that UI masking complies with the data privacy laws.
A secure alternative
EPI-USE Labs’ Data Secure, part of the Data Sync Manager (DSM) Suite, is an alternative to both UI masking and Consent Management. For over a decade, Data Secure has been directly modifying the values of PII fields in the database itself. The framework designed avoids the use of cyphers and seed tables which can be reversed, and instead focuses on pattern-breaking where each field is calculated independently and then aligned through our specialist domain mapping. The solution is also designed to replace names with names, and bank details as valid formatted random bank details.
The aim is to ensure that your SAP data still has valid values which will pass system validations, but without leaving the actual PII information associated to the record. With accelerator policies provided for the standard SAP model, and a fully customisable framework, you can target the PII in non-production for consistent replacement, thus removing the PII risk.
Multiple system types
Many clients we work with have multiple system types to contend with, such as connected cloud applications (CONCUR, ARIBA or SUCCESSFACTORS).
I have two recommendations:
- Firstly, where it is an OData-connected cloud application, we have designed a cloud integration platform that allows the data to be replicated from the cloud application into the scrambling provided by Data Secure, providing cross-system integrated scrambling.
In this example, an SAP Employee and SuccessFactors Entity data are being anonymised to the same new values.
- However, there are multiple different types of systems and API connections. Although the Data Secure solution has other APIs available, we have also reviewed the other industry participants and identified a key partner to support non-SAP appliances. So, the second recommendation is to review DatProf for your non-SAP appliances. Capable of taking an input list of keys and new values, DatProf can take an extract of the SAP scrambling completed by Data Secure and use this to match the new scrambled data in all connected appliances.
