GRC Viewpoint

Achieving Continuous Compliance in Cloud Ecosystems

Visibility into compliance requirements across cloud ecosystems presents complex and nuanced challenges.  To illustrate this, there are at least 19 auditor validated certifications and attestations globally that don’t even cover regional requirements like CCPA, GLBA, EU Cloud Code of Conduct, MTCS Tier 3 (Singapore), just to name a few. Continuous integration/continuous deployment, auto-scaling, serverless, data lakes, and third parties add further complexity to the compliance ecosystem.  The whipped cream and cherry on this compliance sundae are the auditors that show up annually and regulators that show up when things go awry.

Even though at times this can all seem like too much to handle, we should remind ourselves about why compliance is so important to the organization and how, if we follow practical steps, this goal is within reach. 

In cyber security, we like to talk a lot about risk and compliance, sometimes touching on governance.  But do we ever really talk about the business risk of losing compliance, the potential liabilities when non-compliant, or the actual operational impacts of non-compliance?

Risk of non-compliance

To understand the business risk of losing compliance, organizations need to consider contractual obligations and rev-ops.  A simple example: an organization provides a cloud based payment application service to SOHO businesses and loses their ability to transact due to lost PCI DSS compliance resulting from a breach (e.g. ransomware).  In this example, the business revenue impact is straightforward, they lose revenue because they’re:

  • Unable to transact payments
  • Subject to processor, regulator, and financial institution fines
  • Paying attorney and litigation fees

Operational impact of non-compliance

But what about the operational impact?  This includes the time personnel are dedicated to remediating the issues that resulted from the ransomware being introduced into the cloud environment, updating of operational and technical controls to reduce the likelihood of recurrence, and lost DevOps cycles delivering improved client experiences.  There are a few other operational impacts that likely go unaccounted for like planning and status meetings or system architecture documentation updates necessary to regain compliance.

The above illustrates some, but not all, of the financial and operational impacts of losing compliance with PCI DSS.  This example doesn’t account for lost privacy compliance (GDPR, CCPA, PIPEDA, etc.).

As one can see, compliance presents risk to the organization, beyond simply being non-compliant and regulators and compliance regimes are aware.  This is why they are increasing the frequency in audits and systems reviews, building out processes for continuous authority to operate (c-ATO), and continuous monitoring (Con-Mon).  To be sure, these are good things, albeit complicated and time consuming. 

How to create a continuous compliance program

So how can you create a continuous compliance management program? Below I list three key steps:

  • Identify your compliance and regulatory requirements

A good place to start is to know your compliance and regulatory requirements.  Just because a client, prospect, or executive informs you that you need to be compliant with ITAR, do you really?  Are you in possession of any plans, diagrams, or documentation related to building military gear?  If the answer is no, then you don’t need that compliance and the associated overhead.  So, clearly understanding what your compliance and regulatory requirements are and being able to communicate with the business will help guardrail what’s needed for the business and what’s not.

  • Consolidate controls

Once your regulatory and compliance requirements are defined, identifying commonalities between them will reduce operational management burden.  Sounds simple, but it’s not.  In many cases there is a control which inevitably has sub-controls with several related controls.  The key here is to understand the control objective.  For example, NIST 800-53r5 has over 1000 individual controls, and going a bit deeper control AC-2 “Account Management” has roughly 18 sub-controls.  However, if you look at AC-2 “Account Management” you’ll find that your Cloud Service Provider (CSP) likely requires you to comply with the majority of these sub-controls.  Further to that point, the CSPs have available responsibility matrices that can help reduce the number of controls your organization has to address.  The key to identifying the commonalities is to consolidate compliance and regulatory scope to a manageable set.  It’s still challenging, but continuous compliance is getting within reach.

  • Apply automation where possible

Now that you’ve identified your compliance and regulatory requirements and consolidated the controls to a mostly manageable set, it’s time to automate.  I understand this is everyone’s favorite buzz word when discussing managing cloud ecosystems, but it does make sense.  In fact, you’re seeing industry rush to market with services to automate compliance.  Pick your compliance regime or regulatory body and they’re either building or releasing new ‘automations’ to make managing compliance ‘continuous’.  This includes services that maintain and monitor the operational policy and process documentation looking for gaps, cloud security posture management platforms that deliver ecosystem wide views on security and compliance, and auditor frameworks for ingesting all this data continuously in order to provide an enterprise compliance view at any particular moment of the day.

Overall, continuous compliance management is not a trivial endeavor.  It takes time, consideration, and an understanding of how compliance impacts not just potential business revenue, but also operations.  However, getting to a state where compliance is continuously monitored will reduce business revenue risks and operational friction while improving business posture and speed to market.

By Doug Hudson, Vice President of Public Sector at Orca Security

About the author: Doug Hudson is the VP of Public Sector for Orca Security. Doug works with C-Suite and cyber executives on risk management, governance, cyber strategy, compliance, and technology transformation. With 20 years experience across industries and public sector groups, he brings a unique perspective on organizational global value chain and associated cyber inflection points. Doug’s certifications include CISSP, CCSP, CCSK and Open-Fair.

Related Articles

Latest Articles