“Large enterprises expect to get an average 246 GDPR enquiries per month, for which they will need to search 43 databases (seven minutes per search). They will spend more than 1,259 hours on this, which equates to nearly 60 hours of searches per working day or 7.5 employees dedicated solely to GDPR enquiries.”
It’s a database management company doing the survey, but still a good wet finger in the wind
Original source: GDPR requests to take thousands of hours a month, says survey
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:
Instead, the post emphasized new ways NASA is thinking about acceptable risk for these launches. During the space shuttle era, launch sites were governed by some 2,200 safety requirements. NASA worked to “strip down the expensive rules and came up with just 500 core safety requirements for launches.”
But, the post notes, ”at commercial launch sites, there are only 55 safety requirements.” This “underscores perhaps the single biggest difference between NASA and its commercial partners: risk tolerance. NASA likes to have next to none, and pays for it, while the companies tend to embrace calculated risk as a way to iterate and learn while still developing their products.”
This a major point in companies fixing up their software process: you probably have all sorts of rules and regulations that no longer apply. Just like with managing a legacy application portfolio, you have to aggressively manage your compliance portfolio to eliminate rules that no longer apply.
Matt Curry covers this point with a funny boat-metaphor at the start of his brand talk from last year. You also hear some cases of federal agencies forcing this culling by simply not following the rules and seeing if anyone complained: the compliance equivilent of just turning off old, dusty servers to see who’s using it.
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
The idea behind this consolidation is to give organizations system-wide insight across all their applications and their supporting environments, be they in the cloud or within private data centers.
Also, some momentum updates:
More than 80 percent of Chef’s revenue now comes from enterprise deployments, consisting of more than 900 commercial customers.
See also Tim Anderson’s coverage at The Register.
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.)