Privacy and trust — two things that you can never have enough of. At the core of nearly every compliance framework is an effort to maintain privacy and increase trust. The privacy part is pretty easy to understand. Rules and regulations are put in place to define standards on: consent to release personal data, with whom personal data is shared, how personal data is protected, and when personal data is destroyed. These concepts are the cornerstones of regulations like GDPR and CCPA.

So, all you have to do is say, “yeah, we’re doing all the things” and you’re all good, right? If only. Remember earlier what I said about privacy and trust? Well, it turns out that nobody trusts anyone unless you can irrefutably prove to them why you should trust them. It’d be a lot easier if security was like Santa Claus. People believe in Santa on blind faith, but privacy and compliance regulations are essentially the opposite of that. You can’t go on blind faith. It’s much more like The Santa Clause where Tim Allen doesn’t believe in Santa until he literally falls off his roof and lands in front of him, binding him to the titular Santa Clause written by what I can only assume must be a small army of magical elvish lawyers.

Enter Audit Logs

In the world of compliance and security, Audit Logs are your Santa Claus falling off the roof. Audit logs take you from “belief” to a state of now having “proof”. When properly executed, Audit logs are used to prove to your customers and auditors that you are indeed doing “all the things” to properly ensure that personal data, financial data, healthcare data, and all other sensitive data are protected in accordance with their relevant compliance frameworks. Audit logs provide a transparent view into who did what when? As we take a quick look at the logging requirements of some common frameworks, we’ll see that answering those questions is a key component of them all.

• *Healthcare Information Portability and Accountability Act (HIPAA)
  *HIPAA requires that any creating, viewing, modifying, and deleting of Protected Health Information (PHI) must be recorded.
  Retention requirement: ~6 years

• *Sarbanes Oxley (SOX)
  *SOX requires that specific financial data for public companies like customer invoices, payroll records, bank statements, and accounts receivable must be logged and recorded. The systems that maintain these records must record who and when said changes were made.
  Retention requirements: 5 years — Forever

• *Payment Card Industry Data Security Standard (PCI DSS)
  *PCI requires that any access to payment card information, changes to administrative settings, authentication requirements, log configurations, and more must all be recorded and reviewable at any time.
  Retention requirements: Min. 1 year

• *General Data Protection Regulation (GDPR)
  *GDPR stipulates that all access to personal data, and consent of the data subject must be recorded.
  Retention requirement: As long as it is necessary <- I especially love the specificity of this requirement.

What’s a builder to do?

The best way for application builders to meet compliance is to carefully review the capabilities of your app, consider the applicable compliance frameworks, and ensure you’re recording the required information. It’s especially important to understand the data retention requirements so that you can architect a scalable and searchable backend for your audit records. Finally, you need to make sure that you protect your audit records from modification after being recorded. If you can do all these things you’ll have your Santa Clause.