Getting started with compliance on the cloud is easiest if you have a stepwise approach. Conveniently, there is a model made for this. It’s called the maturity model. The maturity model can be followed along a five-level framework, outlined later in this post. The goal is to start with the basics and work your way to a more mature compliance program and state. Of note, the later levels of the maturity model are hard to achieve in their totality. The maturity model is a framework to continually improve and optimize your compliance program.
Maturity Model Stages
Below are the 5 levels of the maturity model.
- Policy. Informed by privacy, these are the overarching, highest level policies for the handling of data and technology.
- Procedure. These translate the policies from level one above into actionable steps that can be followed.
- Implementation. These are the specific technical manifestations, or technical configurations, for the procedures above.
- Measurement. Once implemented, the configurations need to be measured on a continual basis to ensure continued alignment with procedures.
- Management. As gaps or anomalies are identified through measurement, procedures and resources need to be available to address them.
What is a Control?
Example: "Users shall only be provided with access to internal and external network services that they have been specifically authorized to use. Authentication and authorization mechanisms shall be applied for users and equipment."
Each piece of technology needs to go through a similar process.
This is an example Capability Maturity Model that some frameworks use to understand the maturity of controls.
Design Phase - Levels 1 through 3
The design phase technically includes the first three levels of the maturity model. Starting with building out a set of overarching policies. These policies need to be specific to an organization but there are general structures and even free templates available to help you get started.
Considering the changing nature of technology and cloud technology, in particular, policies still need to be generic enough to be consistent despite the changes. These policies flow to slightly more dynamic procedures that outline the ways that people and tools follow policies. Procedures are then implemented into specific configurations. Below is an example to make this more concrete.
Let’s assume, as an organization and to meet the compliance requirements for the data and/or geographies relevant to you, you need to monitor access to your data (this is something you should do regardless of compliance requirements). You create a policy that states that you log all access to data and provide automated tooling for detecting anomalies or high-risk events. You then create 1-n procedures for how you collect, store, and review those logs and events. Then, you implement your technology (servers, applications, network devices, cloud services, etc) to gather the relevant data and move it to the appropriate storage location as defined by your procedures. In addition to automated tooling, you will likely also have some manual process of reviewing logs.
If that’s all done, you’ve successfully climbed the maturity ladder through level three. You need to do this for each control and requirement so it is not a trivial amount of work. That said, this structure can be used over and over again.
Operationalize - Levels 4 and 5
Operationalizing your compliance program, from a maturity model point of view, encompasses measurement and management. It is rare for organizations to achieve 100% success, or scoring in the context of HITRUST, for levels four or five. Depending on the risk profile and scale of your organization, you can be HITRUST Certified without passing, or at least passing completely and for all controls, on levels four and five.
Once you implement your technology inline with your procedures which, in turn, tie up to your policies, you need ways to measure your controls to detect anomalies for investigation. There should be an expected state — your implementations — that you measure against. You then need resources, both human and capital, and procedures to manage any detected anomalies.
While you can be HITRUST Certified without passing completely on levels four and five, these levels are becoming increasingly important. The reason for their importance is the nature of the cloud. The cloud opens up configurations to non-admin and non-ops users, such as software developers. The cloud also changes the available tooling and configurations for abstracted services on a constantly dynamic basis. Measuring and managing your compliance program on the cloud is imperative to identify implementation anomalies and reduce your risk.
Extending the example from above on monitoring access to data, let’s start with the assumption that the technical tools and processes have been put in place to create, store, and analyze an event/log pipeline. The next step, level four (measurement), means you should be tracking to ensure the tools and data are flowing as expected and any manual processes, like reviews of logs, are being done. There is some automation in this process to detect data flow; this automation should be tested on a regular basis to ensure it is working. In the case of Datica, we also use a manual process to monitor manual event review activity; this involves reviewing activity in Jira.
Extending into level five (management), there should be resources dedicated to addressing anomalies and gaps identified by measurement. This includes both staff and budget (dollars) set aside for compliance-related work.
Don’t do it all at once
The example above about monitoring access to data is trivial but speaks to what needs to be done over and over again for each control. The most important thing, because this can become daunting fast, is to just get started. And the maturity model gives a clear stepwise approach on where and how you can get started. Start at level zero by determining the compliance regimes to which you need to comply. Then develop policies (level one), either using an open source template, from scratch or engage with a third-party consultant to help in the process. Then move to level two and on from there.
Don’t worry about the higher levels until you’ve ironed out each level beneath them. Developing a compliance program is a journey and you need to take the first step to get to your end goal. The unique thing about the compliance journey on the cloud is that the path continually changes despite the destination being a static target.