Posted by: David Schneier
Audit, compliance, exam, examination, GLBA, HIPAA, NCUA, NERC, PCI, regulatory, Regulatory Compliance, risk, risk assessment, SOX
I stumbled upon an old nemesis of mine recently and the bad taste it left in my mouth continues to offend my senses.
In an industry where there are standards that define how standards should be written and websites dedicated to dissecting each standard so that everyone can understand what the definition of “the” is, I’m often amazed by the broad range of solutions employed to achieve compliance. You’d think that from one solution to the next there would be obvious commonalities that would immediately identify what you’re looking at. But that’s generally not the case. I’ve seen so many flavors of SOX solutions you’d be amazed (at one client they have two very different and unconnected systems installed, one for IT and one for the business). At least in general terms, all of the systems I’ve encountered more or less wind up at the same logical meeting point, which is where a determination is offered as to whether or not the necessary controls are in place and functioning as expected.
What drives me crazy, though, isn’t the disparity in compliance solutions but rather in the broader interpretation of compliance. It’s somewhat binary; you’re either compliant or you’re not. Regardless of the method you use to attain and maintain it, once you reach the point where you’re compliant with a regulation you can stop adding to the framework. With SOX, I remember how the very first challenge that every company faced was in figuring out scope. The loosely defined guidance specified that only those controls directly connected to the most significant financial processes and applications needed to be tested. It was a constant struggle to get this done and one in which a clear dividing line eventually was drawn: those who used common-sense and those who didn’t.
It’s a dynamic I’ve encountered many times over my career that is regulation-agnostic. At what point do you stop implementing controls because all significant risks have been properly addressed? The common-sense side of the debate will identify areas that are at greatest risk either because of design or content; the other side, the literal side, will identify everything that’s even remotely related and pull it into scope. I’m a common-sense kind of practitioner. I prefer compact, efficient and relevant compliance frameworks. I hate “made” work; I hate doing something simply because someone said I had to even though there’s no apparent value or need for it. I’m of the “work smarter, not harder” mindset and that shows itself in all my work.
However, I encounter all too often the other side of the debate: Those controls and related activities inspired by people who will test everything and anything even remotely in-scope simply because it’s there. Some of my best and most significant regulatory work is found not in framework design but rather in my redesign. I have a bit of a reputation for coming into an institution and effectively ripping out all the waste, the redundancies and overlaps and whittling things down to a size that makes more sense for the size of the operation and then selling it to the examiner/auditor. I take great satisfaction in this sort of work because I’m saving my clients time and effort which translates into money at some point. One of the nicest compliments I can be paid is to be told that the most recent round of testing took only a fraction of the time and the auditor/examiner was happy with the results.
And so it’s maddening to me to find out that a solution I’ve worked on, one that was working beautifully and is running lean and efficient has been tinkered with because a new set of people have been brought in and are reexamining things in the absence of a credible reason to do so. That’s what happened recently and that’s what has left a bad taste in my mouth.
It wasn’t a solution of my design; I was simply supporting it to conduct the current year’s testing. It had been created previously by a team of people who had intimate knowledge of what was necessary to prove compliance with the regulation that required it, was well thought out and extended itself just far enough without going too far. It was one of those rare instances where I didn’t really see a need to make changes myself and instead only looked for opportunities to consolidate testing with related compliance activities. Along the way, I validated the work by bouncing things off associates of mine who are responsible for testing similar frameworks to make sure it made sense to them. They confirmed what I’d suspected: that the framework was solid, the scope appropriate and the degree of testing more than sufficient. So how is it that a year later that’s no longer true?
The justification appears to be that there was residual risk that wasn’t originally in-scope and should have been. Knowing what I do about the client’s infrastructure, the regulation requiring the work, and the way things happen in the industry, it just doesn’t hold up under scrutiny. Nothing significant changed in their environment; there was nothing from the industry side of things driving a reevaluation and in two-plus years of having their framework there wasn’t a single reported incident that would have made them non-compliant. I’m sure if you get all those involved into a room they’ll point to some relatively benign residual risk factors and pitch a really scary “what if” scenario. Because even in a sufficiently secured and controlled environment there remains risk. But someone needs to challenge how likely that risk is of ever reaching the point where it could actually cause harm to the organization. If they don’t, management will feel the need to take action and fund work that probably doesn’t need to be done.
Remember that despite the best efforts associated with SOX, most of the final financial numbers are crunched in spreadsheets where just about anyone can fudge or transpose a number without detection (or maybe even by accident). Regardless of all the work undertaken to beef up security and application controls, map all manner of business processes and document and test the heck out of all of it, the risk still remains that someone can step in at the very last minute and pretty much do as they wish.
I just think that there’s a better way to spend time and money, all the more so in this economy. It’s an old adage but it’s still very true today: “If it ain’t broke don’t fix it.”