The most important step is to remember that data is a "toxic asset"[0], in that as long as you have it its a potential danger. Data deletion is a valid strategy

The most important step is to remember that data is a "toxic asset"[0], in that as long as you have it its a potential danger. Data deletion is a valid strategy for controlling risks, and as bdibs said in another top-level comment here, you can't have a data breach for data you never had in the first place. Regarding [pseudo]anonymization, there are plenty of deanonymization attacks against various [pseudo]anonymization techniques, so always look into potential problems specific to the type of data you will be storing and [pseudo]anonymizing. Something I would recommend to handle the data you do decide to keep; look up a HIPPA electronic compliance guide, and see what engineering practices have been settled on by folks who will get hit with enormous fines if there is a breach. Curiously, when there are consequences for breaches due to non-compliance with data-handling best practices, companies get much better at doing the right thing. Industries where data-mishandling laws have teeth tend to have fewer breaches. Although I do think there are lessons to be learned for virtually everybody from HIPPA compliance guidelines, the approach you will end up using to protect your data will not be a one-size fits all approach; you will need to consider the architecture of your system, the kinds of data you need to keep, what you'll be using it for, whether you will access it regularly, etc. A good place to start looking is here[1]. It's got a huge number of short "cheat sheet" like guides that cover a narrow topic relating to security. Some ones you might want to check out: password storage[2], authentication[3], attack surface analysis[4], SQL-injection prevention[5], cryptographic data storage[6]. Find guides related to your data and what you want to do with it, then read up, following some of the recommended other links in each cheat sheet. [0] https://www.schneier.com/essays/archives/2016/03/data_is_a_toxic_asse.html https://www.schneier.com/essays/archives/2016/03/data_is_a_t... [1] https://github.com/OWASP/CheatSheetSeries https://github.com/OWASP/CheatSheetSeries [2] https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Password_Storage_Cheat_Sheet.md https://github.com/OWASP/CheatSheetSeries/blob/master/cheats... [3] https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md https://github.com/OWASP/CheatSheetSeries/blob/master/cheats... [4] https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.md https://github.com/OWASP/CheatSheetSeries/blob/master/cheats... [5] https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.md https://github.com/OWASP/CheatSheetSeries/blob/master/cheats... [6] https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Cryptographic_Storage_Cheat_Sheet.md https://github.com/OWASP/CheatSheetSeries/blob/master/cheats... Disclaimer: I am NOT a security expert, just someone with a hobbyist's interest in security. All opinions expressed in this comment are my own, and are not necessarily reflective of the security community at large. I encourage anyone reading this to do their own review of security best practices, the opinions of security researchers, and the technical literature on security.