It pays to be more secure.
Don’t commit code that logs PII. You don’t need this kind of information in your logs. Plus, the number of people who have access to logs can be rather large. The best practice is to restrict access to information to only those required to be able to view it. Logs serve many purposes, from analyzing performance to auditing access to tracking down system problems and more. In most of these use cases, people don’t need access to PII. To better protect your customers, the system should never send this information to a log.
It is safer to do your log analysis using system IDs instead. After all, from a performance point of view, the customer’s PII is not relevant. You can check out the individual user tracks by examining IDs.
Thus, as part of the code review, developers should carefully examine which data the program sends to a log file.
PII should only be stored, encrypted, in the database. Ideally, it would be best if you segregated tables with PII from other application tables. Keeping the number of tables with PII to a minimum reduces risk, especially as the application grows in size and complexity. You can also reduce the number of people with access to those tables when they are kept separate.