As with most regulations, GDPR is not a clear list of rules on what to do and what not. Therefore, questions regarding it are often way too broad to handle on a Q/A site. There are many myths and incorrect simplifications around the regulation, and a whole industry is based on the fear of the sanctions imposed by the regulation.
This answer tries to give a practical overview of the subject. I'm not a lawyer, but I've been working around this subject nearly since it was introduced, first with an information gathering wait-and-see approach, and currently with another practical, sort of prioritizing and iterative approach.
We don't (yet) know how the regulation will be interpreted by the courts, and many companies are still waiting to see what actions others are taking. As Server Fault is for IT professionals, we are not lawyers who could interpret the regulation and its relation with other laws. Even if we could, Q/A style questions would be very long to have all the detailed information needed to answer: GDPR compliance is not a matter of individual actions, but an entire strategy inside your company. If you need to ask such questions, you may need to hire a consultant or even a lawyer. Many will, however, survive without one.
You have to create (possibly with some legal advice) your own strategy and, based on that, decide what actions you are performing to comply with GDPR. When you are trying to implement those changes in an actual information system, you may encounter technical problems on how something should be achieved. That's when the question has been narrowed down to the scope of Server Fault!
To get started you should know what the regulation is for. It's basically a legal framework for ensuring that personal data is handled carefully during its whole lifetime, from collection to deletion. GDPR Article 5 describes the principles for processing personal data, in short:
- lawfulness, fairness and transparency
- purpose limitation
- data minimisation
- storage limitation
- integrity and confidentiality.
GDPR gives data subjects i.e. citizens control over their personal data, and tools to make sure these principles have been respected. Those include the rights to access one's own data, to correct and move it, and to erase it i.e. the right to be forgotten (if no other law requires its preservation). It also gives the possibility of sanctions, and your company might need to designate a data protection officer.
Most of the the principles have already been implemented in national law (due to the Data Protection Directive 95/46/EC), which makes the change quite limited for companies inside the EU. Companies outside the EU may have a bit more to do if they process the personal data of EU citizens.
One main thing that changes is accountability, which is best achieved in practice by documenting your procedures thoroughly:
- how and why the personal data is collected
- what makes the processing lawful (consent being just one condition from Art. 6)
- how the data is stored and processed
- who has access to the data and how you control and audit this
- whether it is removed (automatically / standard practice) when the reason for storage expires
- how you handle the risks involved i.e. risk analysis.
In my opinion, if you've been carefully thinking about these things, fixed the problems and mitigated the risks you've discovered, and then documented all this, you should be far away from sanctions – even if you do suffer an intrusion. There will be an ocean of possible negligent behaviour between your situation and the kind of behaviour that makes one liable for €20 million / 4% of turnover fines.