From Controls to Continuous Assurance: Rethinking GRC for Cloud-Native Environments

The standard process of building governance, risk, and compliance (GRC) programs has been straightforward: define a control, document a control, test the control on a regular basis, and generate a report for the auditor 1-2 times a year. This worked in the context where the IT infrastructure was changing slowly, the applications were monolithic and a change advisory board could have a reasonable discussion about any production deployment. It doesn’t work anymore.

In a cloud-native world with Kubernetes, serverless functions, ephemeral containers and infrastructure-as-code, the infrastructure changes by the hour rather than by the quarter. With a microservices architecture that involves hundreds of independently deployed microservices each with its own pipeline and ability to ship to production several times a day, point-in-time controls verification just isn’t going to cut it anymore.

It’s time for a fundamental rethinking of the traditional GRC practices: from a periodic controls verification to continuous assurance.

The Point-in-Time Problem

All popular traditional GRC frameworks (SOC 2, ISO 27001, PCI DSS, NIST 800-53) have been designed for static systems. They assume that the control can be verified, screenshotted, saved somewhere and considered valid until the next auditing cycle. And while this may be acceptable in the static world, it falls apart pretty quickly in the cloud-native one.

Here’s an example of how it plays out in practice: in March a compliance team verifies that all the S3 buckets are encrypted and access is properly scoped. By April, a new microservice created a new bucket in an automated Terraform pipeline, some developer modified IAM permissions in order to speed up the deployment process, and the environment drifts away from the state that was audited previously. The control wasn’t breached due to negligence but because of the normal development pace of a cloud-native system. The snapshot taken during the audit became irrelevant by the time of its completion.

Apply that to several hundred different services, dozens of cloud providers, and thousands of configuration changes each day and you start to get a picture of why a periodic, manual check-in yields an answer about compliance that is only valid on the day in question.

Why Continuous Assurance Is the Natural Fit

Continuous assurance takes the opposite approach by asking “are we compliant right now, and how do we prove it whenever we want?” Rather than thinking about compliance as a periodic thing, it is a quality that must be continuously monitored, measured and enforced, much the same way cloud-native teams monitor uptime, latency, or error rates.

This change is made possible, and perhaps necessary, by the inherently programmable nature of cloud-native infrastructure. The same things that make cloud-native environments difficult to govern using old-school approaches—automation, declarative infrastructure, APIs for everything—are also the things that make continuous assurance possible.

There are a few things to keep in mind:

Controls as code: When infrastructure is described declaratively (Terraform, CloudFormation, Kubernetes manifests), so too can controls be expressed. Policy-as-code tools like OPA, Kyverno and CSPM platforms enable teams to define a rule (“no public S3 buckets”, “no root-owned containers”, “no plaintext RDS”) in a single place and enforce that policy at each deployment.

Generation of evidence as a side effect of delivery: Instead of screenshots and spreadsheet compilation from compliance teams, evidence gets generated automatically and constantly as part of CI/CD pipelines, configuration management and monitoring toolchains. If a control is built into a CI/CD pipeline, by definition, there must be recorded evidence of enforcement of this control with a timestamp. Preparation for an audit becomes an ongoing process rather than a chaotic rush.

Drift detection supersedes periodic review: Using automated solutions that constantly detect any deviation between the current status of the infrastructure and the baseline one, the team could immediately detect security groups opened too broadly, IAM roles with extra privileges or a new CVE found in a container image – long before the next yearly audit would catch up with it.

Dynamic risk score calculation becomes a reality: Instead of static risk registers updated quarterly, the risk posture becomes a dynamic calculation based on live telemetry – what is currently deployed, what is currently exposed to attacks, what is currently vulnerable, not what was the case when the last assessment was done.

What This Means for GRC Teams

But this approach change is not only a technological one. It completely changes the way GRC processes should be implemented and the stakeholders who should be involved in them.

GRC moves to the left, to engineers. For continuous assurance to work, the controls have to be integrated in the very pipelines that deliver the code. That implies the need for actual collaboration between compliance and security teams and platform and DevOps engineering teams. The policy-as-code controls must be kept in version control and reviewed together with other code.

While the nature of the audit will change, the need for it won’t disappear. Continuous assurance doesn’t do away with independent validation entirely — SOC 2 and ISO 27001 require it. The difference is that, where previously auditors had to wade through an evidence assembly effort assembled manually by a compliance team in the course of a two-week audit period, now the auditors have access to the continuously produced evidence trail and can sample it anytime they want.

Pass/fail metrics give way to “posture over time.” An effective continuous assurance solution doesn’t just report the state of compliance — it shows the trends: how fast the issues get resolved, how often drift occurs, how long the control had to be out of compliance before it was detected. Such metrics tell more about the risk reality than a single year-end pass/fail result could ever reveal.

There has to be tooling consolidation. It’s quite typical for many organizations to use separate tools for security posture management in the cloud, for vulnerability management, IAM governance and compliance reporting, all of which provide separate dashboards and have their own definitions of what it means to be compliant. Continuous assurance relies on all of the signals being properly correlated rather than siloed, hence pushing many teams toward using integrated platforms that allow them to correlate the posture data across the stack or at least provide a unified data layer for such correlation.

The Cultural Shift Underneath the Technical One

One of the toughest parts of the change might not be technical in nature, but cultural. Traditional GRC teams were often organized in the context of the audit calendar, with their success being measured by the results of the report. Continuous assurance requires a very different approach from GRC teams, where they should be in charge of an always-on system, collaborate very closely with engineering rather than validate its findings, and be fine with real-time, imperfect visibility rather than the perfect picture every three months.

Engineering teams should think of compliance controls as a natural part of the process rather than something that gets imposed from outside.

In successful companies that have made the transition, they begin by choosing a select few important controls, translating these into policy as code, hooking them up to an existing pipeline, and letting the evidence generation occur automatically. Over time, coverage grows outwards, control-by-control, until continuous assurance is no longer a special project – it is simply business as usual when it comes to compliance.

The Bottom Line

For cloud-native infrastructures, the pace at which they evolve makes annual audits and static control checklists ineffective at providing meaningful information on risk levels. Continuous assurance is not a compliance trend; it is an inevitable outcome of infrastructure which is created and maintained as code. Companies that treat governance, risk, and compliance (GRC) as a verifiable feature of their codebase will do far more than just pass their compliance audits. They will have a far more current and accurate understanding of their security and compliance posture.