Compliance is easy. You have a list of requirements, put them in a spreadsheet, then start checking off the boxes. Might take a couple of days to fill in some blanks, but no big deal.
You start tracking down answers, and the “couple of days” quickly passes. Discovering who does what in any decently sized company seems like a job unto itself. You find some policies and process documents, half of which are outdated and have the names of people who left the company years ago. Some of the others don’t seem to align with the scope of your exercise.
You try for a top-down strategy and head to the CIO’s office. You get an audit report from a couple of years ago. Some of the audit criteria align with your spreadsheet, but there are still big gaps. After a few more weeks of digging, your spreadsheet is a hodge-podge of references, conjecture, and wishful thinking in an attempt to convince the reader that the company is “compliant.”
On the surface, a spreadsheet with a list of requirements can easily seem like a checklist. Buried in the adjacent columns and links, however, are hints to a rich narrative that experienced auditors seek to tease out. If you don’t take control of that narrative, the same spreadsheet can paint the company in an admirable light or expose outright fraud.
So, if compliance isn’t checklists, then what is it? In my 20+ years of experience, the best way I’ve come to understand it is that compliance is, simply put, storytelling. Not storytelling in the sense of Joseph Campbell’s Hero’s Journey (although the struggle is real) or Dan Harmon’s Story Circle (despite the typical comedy of errors), but in the sense that compliance attempts to tell the story of the nuanced motivations underlying a business’s operating profile in a way that aligns with the intent of the compliance framework under evaluation.
Before we unpack this word salad, let’s address why we call all this “compliance” in the first place. To quote Red Forman from That 70’s Show when his son, Eric, is complaining about having to work:
Work is work. You don’t show up late, you don’t make excuses, and you don’t not work. If it wasn’t work, they wouldn’t call it work. They’d call it super, wonderful, crazy fun time. Or skippity-doo.
Compliance is compliance. It’s not something businesses want to do. It’s something they have to do. If it was something businesses wanted to do, it would be called opportunity. Would any rational business voluntarily retain six years of email records? Or undergo nine months of supervision by an external auditor every year? Or submit detailed, monthly reports of internal processes to select customers? I can’t imagine a single sane person who would willingly waste that time, energy, and money doing something they weren’t forced to do.
Unless, of course, they’re enticed to do it by getting something in return. In business, compliance is the carrot opposing the stick of litigation. Parties make promises via contract and, as long as they are demonstrating compliance with the terms of the contract, neither party has standing to sue. Regardless of geographic region or industry, investment in these compliant practices is typically the “bare minimum” and the compliance function itself sits within Legal.
But Legal can’t do everything. The more esoteric and specialized a domain of practice, the more Legal depends on specialists to perform compliance functions. In my world, this specialized domain is Cybersecurity and the esoteric notions are microservices, Kubernetes clusters, high availability, CI/CD pipelines, version control, DAST/SAST tooling, cryptographic configurations and on and on. Legal depends almost exclusively on cybersecurity specialists to not only design, implement, and operate demonstrably compliant practices, but to articulate to a variety of stakeholders exactly how those practices meet compliance requirements.
A business’s cybersecurity practices don’t start with ISO 27001 or PCI or HIPAA, and the practices will never be limited to a compliance framework. Cybersecurity in practice grew out of a need for protecting company interests and was shaped by its risk appetite, budget, external expectations, skillsets, personal motivations, associations, random happenstance and probably a lot of other things. The motivation for establishing and evolving a business’s cybersecurity practice is unique. Hence, the appearance of a business’s cybersecurity practice is also unique.
Now we come to the part of the story where the storytelling happens. At some point, the company will need to demonstrate and defend its claims of compliance to an external party. This external party has no insight into the motivations for the business’s cybersecurity practices, yet the external party has a list of expectations. Some of these expectations are clear and well defined; others are tacit and nebulous. The compliance analyst’s job is to tell the story of how the business’s cybersecurity practices meet the external party’s expectations in a manner the external party can understand. Charts and graphs, organized references to authoritative documentation, helpful visuals, interviews with key people, test methods and results, and historical context are all storytelling devices but the compliance analyst has the job of making it all make sense.
Talk to us about your compliance engineering needs.
About the Author
