I’m slowly working through a new edition of my Cloud Native Journey booklet. Here’s a draft of the chapter on compliance, auditors, and all that. The goal is to draw on actual cases and lessons learned from organizations.
Exciting new audit needs ahead, hoss: “Organisations should review their IT systems and procedures to check they comply with GDPR requirements for privacy by design, ensuring only the minimum amount of personal data necessary is processed. Privacy Impact Assessments (PIAs) should be completed when using new technologies and the data processing is likely to result in a high risk to individuals.”
Original source: GDPR compliance – here are the 14 things you actually need to do
You probably still want to know who actually built a given container and what’s running in it.
Can we take that governance and work with the platform team to codify, to automate that which they were doing on a per application basis – that’s, quiet frankly slowing down the delivery of the software – can we take that governance and can we have them work with the platform team to codfiy, to actually automate on a per application basis, have them expose that as a service on the platform
In other words: you should not only automate the audit three-ring binders of compliance, but enforce as much as possible in the platform.
The rest of the talk is good stuff on how think through re-arranging your organization to be all DevOps-y, with the help of Pivotal Cloud Platform to automate all the infrastructure and middleware stuff:
Because FedRAMP is the expected standard in this market, but acquiring an ATO is a difficult, expensive and lengthy process, the number of federal IaaS providers is limited. Our discussions with vendors that have completed the process suggest an average of 18 months and $3.5 million to go through the process. This has led to increasing dissatisfaction with the FedRAMP Program Management Office, particularly for small providers, and it is working on streamlining the process as a result. Because the FedRAMP certification process is lengthy, providers may be in the process of certification.
As they used to say “a lot of effort went into making this effortless.”
Source: Gartner Reprint
Making it easier for US federal government projects to run more agile, if not “cloud native.”
Questions around audit and compliance always come up in discussions about improving software, and certainly when it comes to introducing things like continuous delivery, DevOps, and esp. something as big and different as Pivotal Cloud Foundry. To that end, I wrote up a way to approach those issues, along with a few tips for dealing with compliance and audit for my FierceDevOps column last month.
The onerous steps auditors want you to do were usually put in there for good reason, but, as I put it:
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.
(Binders picture from tookapic)
18F is fun the watch if you’re interested in transforming to cloud. In this FAQ about cloud.gov, their Cloud Foundry service, they talk about how they help speed up the slow meatware process of compliance:
A typical agency process to demonstrate compliance with FISMA and gain an ATO requires generation of a gigantic, copy-pasted document enumerating the full design of the system. We document all of the federally-required controls in every section of the cloud.gov platform in a software-friendly way. This enables us to generate different documents suitable to different contexts: human-readable, gap analysis, spreadsheet matrix, web page visualization, etc.
Any app deployed on cloud.gov will be able to leverage these “parts-included” descriptions to make generating their own documentation much easier; they only need to supply information about what their system adds on top of the PaaS. For more information, you can watch the recent DigitalGov University video on “Handling FISMA Faster and Better.”
There’s a few interesting things here:
- They automate as much of the process as possible, doing the copy and pasting for you. Now, this should make you question needing to do all that meatware work in the first place but…
- If you can’t beat the meatware process problem, join it and try to automate it. There’s probably some value in there, and even for the parts where there is no value, it might be a waste of effort to fight it (versus other ways to spend your resources of time and favors). 3. And, as I mention on my cloud strategy piece on dealing with legacy IT, perhaps by doing all this you can expose how silly it is and eliminate it.
(If you like this line of thinking, check out my webinar on Dec 1st in dealing with legacy IT in your cloud strategy.)
[T]here will be classes of developers that go after Git and they’ll love Git for what it allows them to do which is to stay off the radar until their tiered promotion gets it ultimately to visibility, but there will be other shops that want to have that visibility the entire time and their compliance or governance or whatever the management driven stuff that is required will keep it around.