Who’s who in the journey toward continuous compliance.

This is the first part of our series of blog posts illustrating the challenges that organizations and cloud providers face when trying to achieve continuous compliance. The series will provide the key concepts, technologies and industry standards that lead the way toward an operational, scalable and effective end-to-end solution.

We will start by introducing the compliance personas and their roles and actions in the compliance processes. Understanding the personas, their roles and needs is key to the design and architectural decisions for the Governance, Risk and Compliance (GRC) automation detailed in our follow-up blog posts.

In the second blog post of this series, we will review the compliance artifacts handled in the enterprise-wide compliance process and the design of their representation both for human consumption by the various personas and for programmatic enablement as code.

Follow-up blogs will cover our hierarchical Governance, Risk and Compliance (GRC) solution with its various types of Policy Orchestrators and Policy Validation Orchestrators, a standardized Exchange Protocol to enable interoperability between the Policy Validation Tools and Orchestrators, an AI-based regulation crosswalks support for the Policy Orchestrators and a few specific policy validation automation techniques. Stay tuned.

The importance of continuous compliance

These days, regulatory compliance is a business liability. The corporate world is moving from sporadic audits to continuous compliance realms, where the system’s posture is to be available at the touch of a dashboard. To achieve continuous compliance, we need both automation and standardization. Achieving automation is a challenging endeavor due to siloed governance processes, disconnect between organizational policies and their corresponding technical implementation and the complexity of compliance implementation and measurement.

Note that the closer we get to systems, APIs and programmatic data representation, the easier it is to drive digitization and automation. Meanwhile, the closer we are to manual processes and human format data representation, the more difficult it gets to drive digitization and transformation. Compliance lies in the second class — with its PDFs and Word docs for regulations, guidance and interpretations — and its manual procedures to gather sample evidence and generate spreadsheet reports. Therefore, to onboard on the compliance automation journey, we need to understand those manual, semi-automated and siloed procedures and their facilitators’ needs.

In this blog post, we survey the stakeholders and their roles and actions in the Governance, Risk and Compliance (GRC) management framework — from regulation authoring to evidence gathering to audit reporting. Since our focus in this series is on compliance, the risk aspects will be included at a later time. We then introduce compliance artifacts associated with these personas and exemplify their representation as compliance as code and policy as code to enable automation. A comprehensive coverage of the compliance artifacts will be the subject of our next blog post.

Compliance stakeholders

As we illustrate in Figure 1, the main compliance stakeholders involved in a Governance, Risk and Compliance (GRC) management framework and the flow of actions from these personas is as follows:

1. Regulators define regulations, laws and standards as catalogs with controls and parameters. They also establish predefined compliance requirements into baselines or profiles.
2. Control Providers — such as product vendors, service providers and OSS project maintainers — implement the controls from the regulation catalogs in their products (e.g., hardware, software, services, processes). In order to declare how the controls are implemented, they need to translate each control into technical rules applied to the product configuration parameters and behavior such as to reflect the control guidance. This translation is done by stating the mapping between the control and the technical rules. The Control Providers may also expose the nature of the evidence associated with each rule (e.g., schema, template, API payload).
3. The technical rules need to be tested or enforced to check or ensure that the regulated environments or reference architectures are configured and behave according to the regulation, baseline or predefined profiles of the Regulators. Control Assessors — such as assessment tool vendors, service providers, OSS project maintainers and compliance engineers — implement checks or products that host checks to test regulated environments or reference architectures for alignment with the expected compliance requirements. Their checks build on the evidence format declared by the Control Providers and have output states for the checks like “fail,” “pass,” “error” and “unable to perform.”
4. System Owners and CIOs are responsible for the overall procurement, development, integration, modification, operation, maintenance and disposal of their enterprise platforms, systems, OS, networks, databases and applications. They are responsible for ensuring compliance with the profiles selected by the CISO Security Engineers.
5. CISO enterprise architects, security engineers and compliance engineers are responsible for defining, customizing and associating profiles and controls with the owned regulated environments and reference architectures.
6. CISO enterprise architects, security engineers and compliance engineers are also responsible for creating new technical rules for their regulated enterprise and reference architectures to cover additional controls through cross-product combined capabilities and behaviors. Those new rules will result in new checks to further test that the regulated environments and reference architectures are configured and behave according to the profiles selected by CISO Security Engineers. These checks build on the evidence format declared by the Control Providers (or by the CISO in the case of custom tools and processes) and have output states like “fail,” “pass,” “error” and “unable to perform.”
7. CISOs are also the link between the System Owner and the Audit Officials for whom they need to prepare the package for the Authorization to Operate (ATO) (i.e., the System Security Plan (SSP) and the System Assessment Results (SAR) for the enterprise).
8. Based on the CISO’s selected profiles, SSP or System Assessment Plans (SAP), the Control Assessors test all applicable technical rules and generate System Assessment Results (SAR) that contain the compliance posture of the systems in the regulated environment or reference architecture. The SARs are shared with the CISO and the System Owners and/or Operation teams.
9. CISO and/or Systems Owners may generate plans of actions based on SAR posture failures. Systems Owners are responsible for ensuring the compliance with the profiles selected by the CISO. They retrieve the SAR from the Control Assessors and must take corrective actions to reduce or eliminate the risk of failure. They work with the Operations team to remediate the systems (for risk elimination) and with the CISO to adjust the profiles or SSP security plan (for risk mitigation).
10. Operations, Administrators and Developers need to focus on the day-to-day tasks of their respective jobs and minimize the involvement into regulations and audit. They need to understand how the technical controls of the systems for which they have expertise are impacting the compliance of their environment, reference architecture and apps, and, if failing to comply, to remediate them. They benefit from a plan of action and priorities to proceed with the remediations.
11. Audit Officials retrieve the SSP and SAR reports from the CISO in the recommended templated format of the audit. All the translations between the product native SAR formats and audit templated formats or standard formats (e.g., NIST OSCAL – Open Security Control Assessment Language)  could benefit from the support of an SDK like Trestle, which was introduced in an earlier blog.

In the table below, we summarize the personas involved in the enterprise-wide compliance processes and their actions:

Key compliance artifacts

Figure 2 depicts key compliance artifacts with concrete examples and their representation in human language and as compliance as code or policy as code. It illustrates the following key aspects of the compliance artifacts:

1. The regulations and regulations controls on the governance side are expressed as broad statements in human language (e.g., “SC-28 The information system protects the [confidentiality; integrity] of [information at rest].”) while the technical rules on the technical side are expressed as specific statements for the products and processes implementing the controls (e.g., “Ensure Cloud Object Storage is encrypted with KYOK”). In most cases, the wording in the technical rule indirectly reflects the claim of the control, requiring a product expert to generate the rules and making it difficult for a non-expert or AI to evaluate the coverage of the control statement. We will show in a future blog how artificial intelligence (AI) can support the compliance expert to navigate the regulations statements via crosswalks.
2. The representation format of these compliance artifacts evolves from PDFs, free text and spreadsheets to compliance as code (e.g., NIST OSCAL) and policy as code (e.g., OPA – Open Policy Agent) to achieve automation. On one hand, while we still need PDFs, free text and spreadsheets to facilitate the users’ creation and consumption of catalogs, profiles and vendors’ products rules and parameters description, we need to shift to compliance as code to enable the compliance tools and services to exchange, apply and control those compliance artifacts continuously in the environments. On the other hand, we also need the manual evidence evaluation processes to shift to policy as code — such as scripts in Python, JavaScript or OPA Rego — to continuously test the technical rules of the products deployed in the regulated environment. In the next blog, we will show how the NIST OSCAL framework and its standard language can be used to represent the typical GRC artifacts as code.
3. The key to achieving compliance automation and continuous compliance is the programmatic representation of the mapping from broad control statements in human language to specific technical rules and their associated parameters and checks. The multiple-step process to generate this key artifact, register it with the GRC framework and use it to provide the compliance posture will be the subject of our blog post on the GRC Exchange Protocol.

Conclusion

In this first blog post of this multi-blog series, we covered the main personas expected in the Governance, Risk and Compliance (GRC) management framework. As you undoubtedly have noticed, we have defined a specific set of actions focusing on a theoretical separation of duties for each persona. However, in a real organization, an individual may cover multiple roles — in which case, she will perform the actions associated with all those personas.

What’s coming next?

In our next blog post, we plan to provide you with detailed coverage of the compliance artifacts handled in the end-to-end compliance flow — from representing regulations to compliance posture to auditor reports. We will also provide their representation as code using the NIST OSCAL standard, with actual examples ready to use for your continuous compliance implementation of catalogs that represent standards (e.g., NIST 800-53), profiles that represent baselines, assessment results and more, together with their interdependencies in the Governance, Risk and Compliance framework and relationships to the persona’s roles and actions introduced in this blog.

Learn more

If you would like to dig deeper, see IBM Cloud compliance programs and the IBM Cloud Security and Compliance Center to learn about the supported compliance programs and how to manage your compliance on IBM Cloud.