Learn what the GDPR means for your ServiceNow instance development.
Reading time: 5-8 min
Audience: ServiceNow platform owners, software engineers, Data Protection Officers, Data analysts, Chief Risk Officers, CTOs, CIO
The General Data Protection Regulation (GDPR) (Regulation [EU] 2016/679) is a regulation by which the European Commission intends to strengthen and unify data protection for individuals within the European Union (EU). It forces stricter responsibilities on organisations to prove that they have adequate processes in place to manage and protect personal data, and it pertains to any organisation that handles data about EU citizens—whether that organisation is based in the EU or not.
Coming into effect 25th of May of 2018 it is already causing substantial turmoil and stress in organisations.
Personal Identifiable Information (PII)
The EU defines “Personal Data” as “any information relating to an individual, whether it relates to his or her private, professional, or public life. It can be anything from a name, a photo, an email address, bank details, posts on social networking websites, medical information, or a computer’s IP address.”
Does it affect you?
If you are collecting any type of PII, you become a “data processor” (in the words of the regulation) and need to put measures in place to protect it.
Suddenly, companies around the world are realizing that they may be affected by the regulation even though they are not even in the EU. Why so? Because they are collecting information from residents of the EU. Plus all the European-based companies too. If you’re in one of the two settings, it is more than likely that you are subject to GPRD.
GDPR strongly emphasizes a risk-based thinking; you take every step to mitigate privacy risks until the risks become something you organisation can cope with. Organisations who don’t follow GDPR can be fined by up to 4% of their annual turnover.
But do not panic!
When you are a “data processor”, you can have free access to personal data under the following conditions:
- you document the activity
- there’s valid basis for processing
- access happens within defined boundaries.
This makes you liable and responsible so you have to be mindful of any sanctions. But this is the route to take if you absolutely need access the PII databases.
Remember that your data subjects should be able to verify, correct, export, move, and erase their data as easily as they provided it in the first place.
This means being aware of all the information collected from users. Including your SaaS platforms.
And how do I know which PII is in my ServiceNow instance?
Recognizing PII is a laborious and continuous task. You have to go form by form, field by field and look for any PII your system is collecting. You can also try to look for any documentation generated during the development life cycle. Or maybe talk to your operations team, HR, help centers and the like, and ask them for the type of data they are collecting when talking to people.
Alternatively, you can take an automated approach to identifying PII. And here is how.
What’s the process I need to follow from now on?
The best is setting up a process to manage your ServiceNow instances. And the best place to do so is within ServiceNow using the (GRC) Governance, Risk, and Compliance application.
The process below focuses only on creating new functionality for your ServiceNow platform and doesn’t try to deal with legacy information potentially affected by GDPR. This is a whole different (and bigger) task.
The process can be the following:
- Self-asses – Identify all the places in your ServiceNow instance that might hold PII data. Identify also any integration with other systems that could import PII into your ServiceNow instances.
- Assess each field that holds PII and ask yourself why (and if) it is needed.
- Identify who has access to the PII data (the field)
- Remediation – Create control mechanisms on who has access to the data – Use access control lists (ACLs), encryption and similar where needed.
- PII data mapping – Document your findings; mark the data which is governed by the GDPR law. You can use the configuration management database (CMDB) to do this.
- Create a task to regularly identifying new fields, forms etc. that hold PII, and update all your documentation.
- Define a process to delete user data if requested (but only the data which is not enforced to be stored by GDPR).
- Document this process and create evidence of your work! GDPR requires an audit trail.
You can automate 1 , 5 and 6 steps with existing market tools that look for patterns in your code so your pain will be less! 🙂 Click here to find more.
It is also a good practice to avoid copying any sensitive data from PROD to DEV environments. If you do so, you are giving developers access to data they shouldn’t see and in turn, they too become “data processors”. The same goes for the operations team.
Good luck with your GDPR!
