Skip to content
  • There are no suggestions because the search field is empty.

The Difference Between the Master Control Library, Living Control Set, and Conformity

How the Master Control Library, Living Control Set, Conformity Analysis, and Conformity Engagement work together in the Cyturus CRT.

How the CRT Organizes Controls

The CRT uses a control-based governance model to help organizations understand what controls exist, what controls apply, and how those controls relate to specific laws, regulations, frameworks, and obligations. Four concepts are central to this model.

1. The Master Control Library, or MCL, is the complete catalog of cybersecurity and data protection controls.

2. MCL Classes organize the MCL by laws, regulations, frameworks, standards, and other requirement sources.

3. The Living Control Set, or LCS, is the organization-specific subset of controls selected from the MCL.

4. A Conformity Analysis shows the relationship, alignment, and gaps between a selected law, regulation, or framework and the controls that exist within the organization's LCS.

Together, these concepts empower organizations to move from generic compliance mapping to a more precise, defensible understanding of control coverage, regulatory delta, and assessment scope.

(Figure 1)

What is the Master Control Library?

The Master Control Library, or MCL, is the complete catalog of cybersecurity and data protection controls available for use in Cyturus assessments. The CRT's FASCR® model leverages the Secure Controls Framework, or SCF, as the primary Master Control Library reference. The SCF provides the baseline taxonomy used to organize and interpret cybersecurity and data protection controls within the Cyturus CRT. 

In practical terms, the MCL is the broad control universe. It is not limited to one organization, one framework, one regulation, or one assessment. Instead, it serves as the reference catalog from which relevant controls can be selected, reviewed, mapped, and analyzed.

The MCL answers questions such as:

1. What controls exist in the broader control taxonomy? 

2. How are cybersecurity and data protection controls categorized? 

3. Which controls can be used as a baseline for organizational assessment? 

4. How do specific laws, regulations, and frameworks relate to the control catalog? 

Because Cyturus uses the SCF as the primary MCL reference, the MCL provides the foundation for control-based governance. It provides organizations a consistent control language when dealing with multiple regulatory regimes, frameworks, contractual obligations, and risk requirements. 

💡 For more information, see What is a Master Control Library?

What are MCL Classes?

MCL Classes are groupings within the Master Control Library that organize controls and requirement mappings by laws, regulations, frameworks, standards, and other authoritative requirement sources.

If the MCL is the full control universe, Classes provide a way to view that universe through the lens of a specific external or internal requirement source. A Class may represent a law, regulation, framework, standard, contractual requirement set, or other structured obligation that can be mapped to the MCL.

MCL Classes help answer questions such as which controls in the MCL are associated with a specific law, regulation, or framework? Classes are important because they provide the structure for analyzing the Living Control Set. They do not replace the MCL, and they are not the same as the LCS. Instead, they organize the MCL by source of specific requirements.

What is the Living Control Set?

The Living Control Set, or LCS, is the organization-specific subset of controls selected from the MCL. Where the MCL is the complete catalog, the LCS focuses on the organization's universe of controls. It reflects the controls relevant to the organization, based on its operating environment, obligations, maturity, risk posture, and evidence.

The LCS may be shaped by factors such as:

  1. The organization's business model and operating environment
  2. Applicable laws and regulations
  3. Contractual obligations
  4. Industry frameworks
  5. Data protection requirements
  6. Cybersecurity maturity
  7. Available evidence
  8. Risk appetite
  9. Risk tolerance
  10. Risk thresholds

The LCS is "living" because it is not static. It should evolve as the organization changes. New business activities, new regulatory obligations, new systems, new data types, new risks, and new contractual commitments may all affect which controls belong in the LCS. The LCS functions as the organization's source of truth for applicable controls. It represents what the organization has selected, prioritized, implemented, assessed, or plans to manage.

💡 For more information, see What is the Living Control Set?

What is a Conformity Analysis?

A Conformity Analysis is a visualization and review of the gaps between a specified set of requirements and the controls that exist within the LCS. The specified requirements may come from a law, regulation, standard, framework, contractual obligation, or other authoritative requirement set.

Conformity Analysis uses NIST Set Theory Relationship Mapping, or STRM, as interpreted by the Secure Controls Framework. The SCF states that it uses STRM based on NIST IR 8477 because that methodology is well suited for mapping different cybersecurity and data protection laws, regulations, and frameworks. It also states that, in the SCF's use of STRM, the SCF is always the Reference Document, while the law, regulation, or framework being mapped is the Focal Document.

This distinction matters because Conformity Analysis is not simply asking whether a control exists. It is asking how a requirement from the selected law, regulation, or framework relates to the controls available through the SCF-based MCL and the organization-specific LCS.

The analysis helps identify what controls are specified in the CRT Delta Controls: the gap between the selected requirement set and the controls currently represented in the LCS.

💡For more information about STRM, see the SCF's documentation here.

How STRM Works in Conformity Analysis

The SCF's STRM approach compares two sides:

  1. The Reference Document, which is the SCF control catalog.
  2. The Focal Document, which is the law, regulation, or framework being mapped.

The SCF describes the discrete components of the Focal Document as Focal Document Elements, or FDEs, and the SCF controls as Reference Document Elements, or RDEs. STRM then classifies the relationship between the FDE and the RDE using set theory principles.

The SCF identifies five relationship types:

  1. Subset: the Focal Document Element is a subset of the SCF control. In practical terms, the SCF control contains everything the requirement does, plus more.
  2. Intersects: the SCF control and the Focal Document Element overlap, but each includes functionality or content that the other does not.
  3. Equal: the SCF control and the Focal Document Element are functionally equivalent, although they may not be worded identically.
  4. Superset of: the Focal Document Element contains everything the SCF control does, plus more.
  5. No relationship: the SCF control and the Focal Document Element do not overlap.

Additionally, the SCF explains the Functional rationale used for STRM linking where the relationship is evaluated based on the equivalency of results: what happens if the concepts are implemented, performed, or executed.

💡 Conformity Analysis is not a superficial keyword comparison. It is a functional relationship analysis between control intent and requirement intent. 

What Conformity Analysis Shows

A Conformity Analysis helps users understand how well the organization's LCS aligns to a selected law, regulation, or framework. It can show:

  1. Which requirements are covered by controls already present in the LCS.
  2. Which mappings are equal, subset, superset, intersecting, or unrelated.
  3. Which requirements have no relevant control coverage in the LCS. In this case, the CRT will create the Unmapped Controls and AOs to ensure your Conformity Engagement covers all the FDE requirements.

This functionality empowers an organization to understand not only whether it has controls, but whether those controls are sufficient for the specific obligation being analyzed. For example, an organization may already have an access control process in its LCS. However, a new regulation may require additional procedural, reporting, evidence, or documentation elements. In that case, the control may intersect with the requirement, but it may not fully satisfy it. The remaining difference becomes part of the Delta.

What is a Conformity Engagement?

After reviewing the Conformity Analysis, the organization can create a Conformity Engagement. A Conformity Engagement is a linked control repository for managing the specific controls related to a defined regulatory or framework-based assessment. It is tied back to the LCS, but visually presents the controls from the perspective of the selected law, regulation, or framework.

This distinction is important.

  • The LCS remains the organization's control source of truth.
  • The Conformity Engagement provides an assessment view for a specific requirement set.

The engagement may inherit information from the LCS depending on how the user configured the Conformity Engagement. Either way, the engagement is designed to support review, assessment, evidence management, gap analysis, and conformity activities for the selected law, regulation, or framework.

A Conformity Engagement may include:

  1. Mapped SCF/MCL controls (new to the LCS).
  2. Relevant LCS controls.
  3. Custom controls and AOs not covered by the MCL, where applicable.
  4. Evidence and assessment activity (if inheritance is selected).

In other words, the Conformity Engagement turns the analysis into an actionable assessment container.

For more information, see [Creating a Conformity Engagement]

💡 For more information, see Conformity Engagements.

Putting It All Together

MCL vs. LCS vs. Conformity Analysis vs. Conformity Engagement

  • The MCL is the complete control catalog.
  • The LCS is the organization-specific set of controls selected from that catalog.
  • The Conformity Analysis compares the LCS against a specific law, regulation, or framework to identify alignment, relationships, and gaps (delta).
  • The Conformity Engagement is the operational assessment container created to manage that specific conformity effort.

A simple way to understand the relationship is:

  1. The MCL defines the universe of possible controls.
  2. The LCS defines the controls that matter to the organization.
  3. The Conformity Analysis identifies how those controls align to a selected requirement set.
  4. The Conformity Engagement manages the assessment of that requirement set.

Together, the MCL, MCL Classes, LCS, Conformity Analysis, and Conformity Engagement help organizations move from fragmented compliance mapping to a more scalable, defensible, control-based governance model.

Why This Matters

Traditional compliance programs often start with frameworks or regulations and then build separate assessment activities for each one. This legacy process creates duplication, inconsistency, and a fragmented view of control performance. Cyturus takes a control-based approach.

By using the SCF as the Master Control Library, selecting an organization-specific Living Control Set, and applying STRM-based Conformity Analysis, Cyturus assists organizations in understanding how controls support multiple obligations. This allows organizations to:

  • Reduce duplicative assessments.
  • Understand control coverage more clearly.
  • Identify regulatory deltas earlier.
  • Maintain a stronger source of truth.
  • Improve defensibility of mappings.
  • Manage obligations from a control-centered perspective.
  • Create assessment engagements that are specific without losing connection to the broader control environment.

The result is a more scalable and transparent approach to governance, risk, compliance, cybersecurity, and data protection. This is the foundation for the Cyturus Framework Agnostic Security, Compliance, and Resiliency (FASCR®) model.

 

 

Related Articles