You're actually missing quite a bit of the requirements by GDPR. Stuff like your optional encryption (at rest) are basically required if you process any kind of interesting personal data, there's data minimization which helps reduce risk of breaches as well, as well as breach notifications, and so on.
Additionally it's better for both your security and sanity NOT to e.g. log things that can directly identify a user but e.g. just their user ID, that way when you delete a user from your DB (e.g. as per "right to be forgotten"), you don't also have to scan through your logs to delete them. You sort of should delete the data from your backups though - but in practice if you secure them well (both encrypt, and limit access, as well as retention), and make sure that in case you restore something the data is deleted again, you're probably fine.
Annoyingly the GDPR regulation is super vague in some parts, and has really crazy requirements in other ways, but unfortunately it is now a reality and affects everyone.
Anyway, much of this should definitely be considered optional, and far from required to make your first MVP, so while the checklist is pretty good and has a lot of good points, it's definitely wrong to mention the MVP here. No sensible person goes through the effort and investment of setting up all these systems before launching their product.
Thanks for the prompt on GDPR. Security of data is important. I've got an item about encrypt at rest, but would be good to highly the GDPR mandate. Thanks too for the suggestion on log data lines. Any other GDPR high priority issues?
GDPR is such an opaque beast it's hard to come up with clear and obvious answers to that, but there's a few things that pop into mind that are definitely helpful and good to keep in mind in general.
Setting up a list of 3rd parties you depend on for hosting and traffic (AWS/GCP/Azure, CloudFlare, etc.), or otherwise share personal data with (using their analytics systems, and other integrations) is going to help you realize just how many additional risks you have to worry about, and will make communicating this information easier to customers. E.g. something like: paypal.com/uk/webapps/mpp/ua/third...
Similarly keeping a list of all the systems you store personal data in, in any format: Google Drive, Sharepoint, Dropbox, your employees' personal laptops, your ZenDesk and Slack channel with instant notifications for new support requests, the "Top 10 support issues of 2018" document with copy & pasted ticket contents, etc.
All of these things, not just your database servers and application code, need to be secured. If you use Google G Suite or Office 365 or similar, make sure you require 2 Factor Authentication from everyone, including the CEO. Get e.g. Yubikeys.
Make sure everyone, ESPECIALLY the CEO has full disk encryption on their laptop, and that the machine requires a password on boot, on wakeup, and has a screensaver that locks it as well.
Ensure you get actual consent for pretty much everything, this means actual opt-in, not pre-checked checkboxes with intentionally bad UX (e.g. being the only checkbox label on your site that doesn't react to clicks) to subscribe to your news letter.
Have a plan for deleting stale personal data that you no longer need or have a legitimate use for, and no, the CEO saying "we might want to take a look at it in 20 years" is not a legitimate use - well anonymized data can still be used for analytics for a long time though.
You should generally speaking avoid collecting sensitive personal data, and what is considered "sensitive" might surprise you. If you have data on race, political preferences, religion, union status, health, sex life, or sexual orientation of a person that is considered sensitive, and many other seemingly innocuous things like "hobbies" could easily contain sensitive information. You should limit the amount of sensitive data you store, and how you store it must be particularly carefully done.
Have a process ready for what to do when people request a copy of their data, and what to do when people request their data to be deleted. Preferably an automated one. They can also request their data to be fixed if they detect a mistake. You also need to know the source of the data. Basically be ready to receive something like: linkedin.com/pulse/nightmare-lette...
One of the most obvious questions that comes to my mind, which really isn't obvious to most people, is do you really need that email address in plain text in your login information, or could that also be hashed? If they subscribe to your newsletter, maybe store their email only in that case. Reset password could require them to enter the same email as before. I wonder if there are email tokenization services similar to what Stripe does with credit cards, that'd be great for email notifications.
There's a few relevant things that I can also link to:
Wow, thank you so much for this detail. I love the nightmare letter! I'll mine your comments and try to distill into a few points that captures the important parts.
You should do a DevTo article about GDPR!
-- Added comments:
Here are three items I've distilled from your text:
Don't store sensitive data unless you truly need it. This means email addresses, personally identifying information and other personal information in general. Treat sensitive data like radioactive waste — i.e. there is an real, large and ongoing cost to securing it, and one day it can hurt you.
Keep a complete list of all the places you store sensitive information: databases, file systems, Dropbox, GitHub, Vault, Office docs and even the paper folder. This is useful to manage, required by GDPR and essential if hacked. You need to be able to locate all sensitive information.
If subject to GDPR, make sure you really understand the requirements and design it in from the start. For some, it will represent a major change in design and thinking. /Two links here/
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.