Despite all the heart-ache and project delay caused by your organization’s compliance process, at some point, that process was put in place because it was a good idea at the time. We see this from common compliance “hurdles” like PCI and HIPAA, which were, respectively, put in place to reduce credit card fraud and ensure medical privacy (also preventing fraud). Who doesn’t want all that “think of the children” type stuff?
Unfortunately, the way that three-ring binder wielding ninjas and IT staff battle it out over these and other compliance check-lists often loses sight of the original, good intentions. Instead, it infects everyone with a bad case of table-flipping madness. Thanks to cloud technologies and the empathy over table-flipping approaches in DevOps, we’ve been finding ways to get over compliance hurdles and even, in some cases, make compliance projects easier and better.
In fact, I went over some of the options in my most recent column at FierceDevOps. As I frame it up there, most of the time, what those ninja auditors are looking for is proof and trust—that the documentation is there and risk-mitigating processes were followed more than ignored. This means that the process was not just followed, but there was a process in the first place. There are many examples of how a Cloud-Native approach is starting to make compliance “problems” easier to resolve.
Prevent The Need To Verify Each Snowflake By Melting Snowflakes
Once your cloud platform is trusted by the auditors, you may be able to reduce the total time it takes to pass compliance hurdles for each build because standards are baked in.
In the “just do whatever” approach to building applications that we’re just now waking up from, application teams were able to specify all sorts of infrastructure choices like custom OSes and custom services. For example, one large military organization I spoke with recently seemingly had lost count of the number of “special snowflakes” they had built over the decades. In situations like these, you not only get a tremendous amount of infrastructure debt, you end up having to manage everything down to the OS, if not the hardware, storage, and networking itself instead of just focusing on the application. In these cases, your auditors have to check everything with a fine-toothed comb, often for each release…because your stack is unique and the environment is highly heterogeneous, therefore untrusted.
When we standardize on a cloud platform, like Pivotal Cloud Foundry™, and then get our auditors to trust it, we can dramatically reduce compliance bottlenecks. One of the US federal agencies taking this approach has shown that you can fold compliance wait-times down from about a year to just two or three days.
Automate The Three Ring Binder
Automating the three ring binder is another option that is showing promise. As mentioned above, auditors typically want to see documentation of what happened, who approved it, and what’s deployed. Much of this is proving that things were done in a compliant way, but it’s also ensuring that a helpful paper trail is in place. In the good, lean practice of moving decision making as close to the actual worker as possible, projects like OpenControl are pulling developers into the three-ring binder delivery process.
The thinking here is that, if we’re so good at automating every other part of our applications, down to how tricky networking and storage are configured in ephemeral cloud topologies, we should be well equipped to better automate the generation of compliance needs. And, for much of it, who’s better to fill out the “check lists” for auditor three ring binders than the developers and product managers working on the actual product. Perhaps we can finally remove that weird analog process where a development team’s workflow is translated into an onerous PowerPoint with big green checks and red X’s through meatware magic.
The Call Came From Inside The Three Ring Binder!
Finally, sometimes you just need to roll up your sleeves and refactor the compliance process, or, more often, refactor yourself. Once again, there are often good, helpful reasons compliance rules and processes were put into place.
One example is ensuring a separation of duties. In some cases, those who write the code should not be able to deploy the code. It’s flippantly easy to dismiss this concern with “if you don’t trust your developers, you have bigger problems. As numerous high-profile cases in finance and spy-craft have shown and given the limited supply of altruism in the world, it’s all too easy for developers to try to deploy code that benefits them or their puppet-masters. You know, you don’t want your programmers doing the old salami slicing of all those half-pennies in the financial tubes.
So, you might have a compliance rule that prevents developers from deploying the code they wrote. In such cases, enabled by the highly automated ability to deploy in Cloud-Native approaches, you might give that responsibility to product managers, or even auditors themselves, as Home Depot’s Tony McCulley suggested recently.
The point is that you often need to engage with, understand, and then work with compliance people rather than working around them or ignoring them. It’s probably not as terrible a process as it seems at first—if you approach it with that smiley culture part of DevOps.
Always With The Meatware
There’s more in the full piece, but rest assured that “compliance” is like a lot of other problems when it comes to taking advantage of new technologies—what’s holding you back usually has little to do with hardware or software, and everything to do with meatware.
About the Author
