How do you Shift Compliance Left?

Our world today is changing faster than ever with new technology and applications being developed every single day.  Large enterprise digital transformation is underway, with organizations embracing cloud faster than ever and making investments in security tools to secure their code and environments.  With all this change, the one thing that hasn’t changed is compliance.  Compliance is still largely done after the fact as a paper-driven exercise with artifacts created by hand in Word documents and Excel spreadsheets that are instantly out of date the moment they are created.  My fellow co-founder and CTO, Travis Howerton, has said that “Compliance is the equal and opposite force to Digital Transformation.”

In the DevOps world, you may have heard of the concept of shifting security left to make security as near real time, continuous and complete as possible, ideally before the code exits the DevOps pipeline into production environments.   To that end, an array of security tools have been developed from code and vulnerability scanners such as SonarQube and Tenable to cloud security posture management solutions such as Wiz and Prisma which non-disruptively scan your cloud environments for vulnerabilities and misconfigurations and then automate the remediation of the same.  But when you think about compliance, the innovations that have existin this space are 20^th century tools such as Word and Excel to address today’s 21^st century compliance challenges.  These compliance artifacts are stored in file servers and legacy Governance, Risk and Compliance (GRC) toolsand furthermore, this problem is amplified by the fact that compliance needs to be managed across a multitude of standards and frameworks such as NIST, ISO 27001, PCI, SOX, HIPAA, etc.  The question that needs to be asked is how can we shift compliance left and make it near real time, continuous and complete just like we’ve done with security?

To answer this question, we have to consider why DevOps was created in the first place.  In the past, Developers would create code then hand it off to System Administrators (Operators) to test and then deploy said code into production.  Security would be brought in after the fact and have to test all these applications and provide guidance to both Developers and Operators on what changes needed to be made to run these applications in a production environment.  All of this back and forth resulted in giant inefficiencies that stymied Digital Transformation.  Enter Dev(Sec)Ops.   The DevOps Model as defined by Amazon Web Services is “the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes.”.   By employing DevOps, organizations can automate manual and slow processes, leveraging technology stacks and tooling to help their staff operate and evolve applications, as well as enable engineers to independently accomplish tasks that would normally require help from other teams.

How can we bring the fundamental principles of DevOps to Compliance?  I believe the time has come for RegOps (Regulatory Operations).  Given my personal affinity for standards and definitions, I’d like to posit the following definition:

RegOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to ensure compliance of applications and services against regulatory standards at high velocity: evolving and improving compliance and trust at a faster pace than organizations using traditional compliance artifact development and compliance management processes.

My fellow co-founder and CTO, Travis Howerton, posited a Compliance Manifesto mirroring the Agile Manifesto with the following 10 principles:

1. Regulations exist to maintain our privacy while keeping us safe and secure – we should honor them
2. Maintaining compliance as a business should be affordable, transparent, and easy
3. Compliance processes that are boring and repetitive should be automated – it is good for the business, good for the regulator, and good for the employee
4. Audits should be simpler and less risky for the business
5. Evidence should always be readily accessible and as near real-time as possible
6. Producing high quality compliance artifacts should be more profitable for the producer while consuming these same artifacts should be cheaper for the consumer – driving mutually beneficial incentives
7. Technology will change over time so any solutions must be extensible to take advantage of future innovations and minimize technical debt for the future
8. Getting started with compliance should be free with the goal of pulling out costs and accelerating business
9. We should build on industry compliance standards while accelerating their adoption
10. Do no harm – if the solution doesn’t improve privacy, safety and/or security, we should not do it

Just like with DevOps, it’ll take a cultural transformation coupled with tooling to move from compliance as imagined to compliance as implemented.  The time has come to shift both security and compliance left by bringing the principles of DevOps to Compliance.  The time for RegOps has arrived.