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

Figure 1: Compliance stakeholder actions in the Governance, Risk and Compliance management framework.

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:

Table 1: Personas and their actions in the enterprise-wide compliance processes.

Key compliance artifacts

Figure 2: Illustrative examples for various compliance artifacts and their programmatic representation. Regulations in PDF format (top) vs. Controls and Rules expressed as Compliance as Code (middle) vs. Checks Scripts as Policy as Code to test the systems (bottom).

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.


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.


More from Cloud

Kubernetes version 1.28 now available in IBM Cloud Kubernetes Service

2 min read - We are excited to announce the availability of Kubernetes version 1.28 for your clusters that are running in IBM Cloud Kubernetes Service. This is our 23rd release of Kubernetes. With our Kubernetes service, you can easily upgrade your clusters without the need for deep Kubernetes knowledge. When you deploy new clusters, the default Kubernetes version remains 1.27 (soon to be 1.28); you can also choose to immediately deploy version 1.28. Learn more about deploying clusters here. Kubernetes version 1.28 In…

Temenos brings innovative payments capabilities to IBM Cloud to help banks transform

3 min read - The payments ecosystem is at an inflection point for transformation, and we believe now is the time for change. As banks look to modernize their payments journeys, Temenos Payments Hub has become the first dedicated payments solution to deliver innovative payments capabilities on the IBM Cloud for Financial Services®—an industry-specific platform designed to accelerate financial institutions' digital transformations with security at the forefront. This is the latest initiative in our long history together helping clients transform. With the Temenos Payments…

Foundational models at the edge

7 min read - Foundational models (FMs) are marking the beginning of a new era in machine learning (ML) and artificial intelligence (AI), which is leading to faster development of AI that can be adapted to a wide range of downstream tasks and fine-tuned for an array of applications.  With the increasing importance of processing data where work is being performed, serving AI models at the enterprise edge enables near-real-time predictions, while abiding by data sovereignty and privacy requirements. By combining the IBM watsonx data…

The next wave of payments modernization: Minimizing complexity to elevate customer experience

3 min read - The payments ecosystem is at an inflection point for transformation, especially as we see the rise of disruptive digital entrants who are introducing new payment methods, such as cryptocurrency and central bank digital currencies (CDBC). With more choices for customers, capturing share of wallet is becoming more competitive for traditional banks. This is just one of many examples that show how the payments space has evolved. At the same time, we are increasingly seeing regulators more closely monitor the industry’s…