How to Build Processes and Reports While Protecting Data for GDPR

Privacy and data protection remain essential priorities for companies of all types and sizes. More organizations realize they are accountable for any personal information they store, even with a justifiable business reason. While regulations like GDPR technically cover the personal data of European residents, it is wise to treat all customer data with the same level of responsibility. I would argue it is easier to do that anyway – if you treat all data with the assumption that it could belong to someone protected by the strictest limitations possible, you’ll always be prepared. And you need to be prepared. Consequences can be severe, not just for high-profile data breaches dominating the headlines. You can face penalties for improperly storing personal data, even if there hasn’t been a breach, and for not complying with a marketing opt-out or an erasure request. I can’t overstate how important it is to have policies in place that ensure the utmost protection of user data.

Top 5 Things To Know When Getting Started with GDPR

Looking at a few of the more significant GDPR fines can be a bit scary, but it’s important to maintain perspective. Some of those penalties are for things you’re hopefully not party to, like spying on employees or marketing to people who have explicitly opted out. Others are easy to avoid with a bit of work, and there are some things you can do to start minimizing risk right away.

1. Audit your current state – There is no point in trying to improve your handling of personal data if you have no idea how you’re handling it today. Make sure you know what personal information you’re storing, where, and why. Documentation such as requirement specifications and data dictionaries may be helpful here but are not always a given and are not always in sync with production systems. You may need to reverse engineer schema metadata, database diagrams, or application code to catalog everything. That still may not be exhaustive since personal information isn’t always stored in immediately apparent column or variable names.
2. Document all the personal information you store – Documenting can allow you to assign each piece of information a reason. There should be a justifiable business case for storing personal information for customers, end users, or employees. In most cases, you need to store my email address to communicate with me and support administrative functions such as password reset requests. Suppose you don’t have a specific need, though. In that case, it is harder to justify storing things like my social security number or income – even if you may have short-term cases for using them (e.g., passing them along to a third-party to qualify me for a mortgage).
3. Be aware of things that are not glaringly personal – I discovered recently that IP address is considered personal information. This is because anyone who gained access to an IP address I used could theoretically subpoena my service provider to directly correlate that activity to me. While you can justify storing that information – at least short-term – for security purposes, you need to be extremely confident your reasons are sound. Storing it to track my activity over longer periods of time is harder to justify and it is difficult to prove I knowingly gave consent to such tracking. It is shaky as a singular strategy anyway, since I share an outward-facing IP address with everyone in my household (or in a coffee shop or an office), my IP address might be assigned dynamically or reset frequently, and anything I do on my phone is going to jump from tower to tower. But those are the rules we, at least, are abiding by.
4. Know what you might need to do – Identifying and categorizing the personal data you collect and store is a great first step, but you’re not done. As long as you have that information in your systems, there are other things you’ll need to prepare for, including:

• Right to access – End users have the right to request a copy of all their personal information you have. You’ll need to have a way to provide the data in a consumable format, whether they are just curious or looking to migrate their personal information to another system.
• Right to erasure – In addition to requesting a copy all their personal information, a user can also request that you remove all traces of it from your systems. This requires the same kind of work as the right to access, since you first have to identify all the places you store the information before processing any removals. However, deletes can be a lot more disruptive to production systems (and have to happen against primary, writable copies of the databases). Also, you must follow those deletes through to any static copies that may exist on secondary systems. Generally, you have 30 days to comply with an erasure request.
• Marketing opt-out – End users can request that you cease sending them marketing materials, most commonly by email or text messages. Local or other jurisdictions may dictate how quickly you need to comply with this request, especially since many companies use third-parties to handle marketing activities, and they lack control over those systems. But you need to have a process to ensure this happens well within the timeframe and within those external parties’ service levels.

5. Protecting against a breach – Naturally, whether our data contains personal information, we should all be protecting our systems from potential breaches. We can do this with logical approaches, like using strong passwords, avoiding SQL injection vulnerabilities, and following the principle of least privilege. You can go further by protecting the data even internally, encrypting all personal information not meant for anyone except you and the user (like email address), and technologies like row-level security so only authorized applications and users can access other, relatively less private data (like usernames or bios users want displayed on a website).

GDPR Use Case: Storing Email Addresses

All of this does get tricky, though – for example, where do you store an email address you’re no longer allowed to store to prove you complied with the request and to ensure they don’t inadvertently get opted back in in the future? I have two suggestions:

1. Encrypt the email address for requests that come in while they are still being processed, so that they can only be accessed by the people in legal or compliance – who need to validate that those requests are from a legitimate owner of the information and will need to confirm that an access request for the same email address turns up zero information later.
2. Once the request is completed and confirmed, convert the encrypted value to one using a one-way hash so that nobody – even people who can legitimately decrypt the data – could look in the table and find all the email addresses of folks who requested erasure. Instead, they could only confirm if a specific email address is in the table by feeding it through the same hashing mechanism and comparing the hashes (kind of how most password systems work).

Who Is Responsible for GDPR Compliance?

Ultimately, your organization is responsible for all the personal information you store. I hope the ideas above help you become better prepared for that responsibility. You can learn more about how SolarWinds IT security solutions are built to help simplify security, compliance efforts, and support observability solutions on the SolarWinds Platform.