For many organizations, least privilege access controls and user access recertification are key components of their Sarbanes-Oxley (SOX) risk and controls framework. Companies rely on these controls to ensure that transactions are appropriate by restricting access to authorized individuals. Other organizations place more reliance on monitoring controls to validate that changes made or transactions processed were appropriate. Both approaches are sufficient for managing financial risk; however, with the new General Data Protection Regulation (GDPR), organizations both in the U.S. and abroad are having to rethink who has access to certain critical data elements.
What Is the General Data Protection Regulation?
The General Data Protection Regulation (GDPR) is a data-protection regulation that replaces Data Protection Directive implementations in European Union (EU) member states (e.g., in the UK, the law is known as the Data Protection Act). All organizations that collect and process the personal data of EU data subjects, regardless of location or size, must be in compliance on May 25, 2018. Thus, for example, if a higher-education organization stores and processes the data of a citizen, resident or visitor, it is subject to compliance obligations and the penalties for noncompliance, which can result in fines of up to 20 million euros or 4 percent of the organization’s annual global revenue, whichever is greater.
What Is Considered Personal Data?
Personal data, as defined by the regulation, is “any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.” What does this mean? There is a good bit of ambiguity in the definition, which presents a challenge for organizations trying to catalog the areas at risk. Fortunately, Article 4 offers some insight. The first category, “identifiers” (the category this paper will focus on), consists of personal data elements about the data subject and includes:
- Full name
- Home address
- Email address
- Passport number
- Credit card numbers
- Bank account numbers
- Date of birth
- Healthcare data
- Biometric data
- Employee identification
- Telephone number
(Note: Online and special-category identifiers must be managed as well but are not relevant for this specific discussion.)
Where Is Personal Data Stored?
In order to start the compliance effort, organizations first need to understand where the data exists. The data elements discussed above typically live in a company’s business-application inventory such as their ERP, HCM, CRM, data warehouse, purchasing or expense applications, bank applications, and physical-access applications. In addition, companies typically have development and test environments that also house this information. Furthermore, companies back up and indefinitely store production applications. All these data stores must be protected in order to be in compliance with GDPR, and organizations must identify where these elements are retained and ensure that access to the data elements is restricted to authorized personnel. Article 25 of the regulation, “Data Protection by Design and by Default,” mandates that organizations be responsible for ensuring that personal data is protected and that proper controls have been implemented. Companies are now going to be responsible for designing processes and security architecture that keeps personal data private.
How Does This Apply to Application Access and User-Access Recertification?
Application-level access is the first line of defense to ensure that access to personal data identifiers is appropriately restricted under GDPR. By restricting access to authorized individuals, organizations work to guarantee that inappropriate review or modification of personal data is limited. This is different from the SOX compliance standard in that the risk is no longer associated with financial reporting. In order to ensure that access is appropriately restricted, organizations must design programs and implement technology solutions that incorporate multiple elements of access management governance, including:
- Security Architecture: Strong application security architecture with clearly defined roles and responsibilities
- User Provisioning: Strong provisioning processes incorporating multiple approvals for high-risk data elements
- Access Identification: Tools and technology to support identifying access in complex business applications
- Role-Change Management: Processes to ensure that roles and responsibilities within the security architecture go through change control and are reviewed for the impact they have on access within the organization
- Firefighter Access: Temporary access-assignment processes to ensure that access is removed when it is no longer needed
- Master Data Monitoring: Audit trails to identify changes to the data elements and ensure that changes were authorized.
Conclusion
To comply with GDPR, organizations are going to have to implement stronger application-level security programs and incorporate security design early on in the application lifecycle to appropriately restrict access to personal data. Most companies have already addressed a portion of these activities given that they built their financial reporting risk framework or SOX risk and control matrices. Now, these features need to be applied more broadly to cover GDPR compliance risk. While this will not be the only undertaking companies must consider as they navigate GDPR requirements, it is an important step.
Kevin McCreary, Associate Director
Technology Consulting
kevin.mccreary@protiviti.com
Connect on LinkedIn
