SCF OVERVIEW &

PRACTITIONER GUIDEBOOK
version 2024.4

This document is designed for cybersecurity & data privacy practitioners to gain an understanding of:
 What the SCF is;
 What the SCF is not;
 The various capabilities of the SCF; and
 How the SCF is intended to be used in an organization.

A control is the power to influence or direct behaviors and the course of events. That is precisely why
the Secure Controls Framework® (SCF) was developed – we want to influence secure practices within
organizations so that both cybersecurity and data privacy principles are designed, implemented and
managed in an efficient and sustainable manner.

NOTE - This guide is for educational purposes only. You are highly encouraged to work with a cybersecurity, privacy or audit professional to
validate any compliance-related assumptions. For more information, please visit https://securecontrolsframework.com
 Table of Contents
Section 1. Terminology & Acronyms ..................................................................................................................... 5
Terminology Standardization ............................................................................................................................................................5
Acronyms ..........................................................................................................................................................................................7
Section 2. Introduction To The Secure Controls Framework®............................................................................... 9
Why Should An Organization Use The SCF? .......................................................................................................................................9
What The SCF Is ...............................................................................................................................................................................10
What The SCF Is Not ........................................................................................................................................................................10
Addressing The Who? What? Where? When? Why? and How? .......................................................................................................10
SCF Control Weighting Explanation .................................................................................................................................................11
Tailoring Is Required - Not All SCF Controls Are Applicable To Your Organization............................................................................11
Statutory Requirements................................................................................................................................................................12
Regulatory Requirements .............................................................................................................................................................12
Contractual Requirements ............................................................................................................................................................12
Tailoring SCF Controls - Defining “Must Have” vs “Nice To Have” Controls ......................................................................................13
Section 3. Designing & Building An Audit-Ready Cybersecurity & Data Privacy Program................................... 14
People, Processes, Technology, Data & Facilities (PPTDF)................................................................................................................14
Holistic Approach To Address Control Applicability .........................................................................................................................14
NIST IR 8477 - Set Theory Relationship Mapping (STRM) .................................................................................................................15
STRM Relationship Types ................................................................................................................................................................16
STRM Relationship Type #1: SUBSET OF ........................................................................................................................................16
STRM Relationship Type #2: INTERSECTS WITH .............................................................................................................................16
STRM Relationship Type #3: EQUAL ..............................................................................................................................................16
STRM Relationship Type #4: SUPERSET OF ....................................................................................................................................16
STRM Relationship Type #5: NO RELATIONSHIP.............................................................................................................................16
Expert-Derived Content (EDC) vs Natural Language Processing (NLP) ..............................................................................................16
Section 4. Understanding Fundamental Governance, Risk & Compliance (GRC) Functions................................ 17
GRC Is A Plan, Do, Check & Act (PDCA) Adventure – That Is A Concept that Should Be Embraced, Not Fought Against ...................17
Chicken vs Egg Debate: The Logical Order of GRC Functions ............................................................................................................18
Compliance ..................................................................................................................................................................................18
Governance ..................................................................................................................................................................................19
Risk Management ........................................................................................................................................................................20
GRC Integrations .............................................................................................................................................................................20
Section 5. Understanding What It Means To Adopt “Secure by Design” Principles ............................................ 21
Secure Practices Are Common Expectations ....................................................................................................................................21
Compliance Should Be Viewed As A Natural Byproduct of Secure Practices ....................................................................................21
Cybersecurity & Data Privacy by Design (C|P) Principles .................................................................................................................22
Steps To Operationalize The C|P Principles....................................................................................................................................22
SCF Domains & C|P Principles .......................................................................................................................................................22
Section 6. Understanding What It Means To Adopt “Privacy by Design” Principles ........................................... 27
SCF Data Privacy Management Principles (DPMP) ...........................................................................................................................27
Section 7. Integrated Controls Management (ICM) ............................................................................................ 29
IT General Controls (ITGC) ...............................................................................................................................................................29
Security vs Compliance ....................................................................................................................................................................29
This concept of identifying a negligence threshold is addressed in the SCF’s ..................................................................................30
Defining Compliance That Is Specific To Your Business Case ............................................................................................................30
Defining What It Takes For Your Business Processes To Be Secure & Resilient ................................................................................31
Discretionary Cybersecurity & Data Protection Considerations ......................................................................................................31
Discretionary Resilience Considerations ........................................................................................................................................31
Defining Negligence As It Pertains To Cybersecurity & Data Privacy ................................................................................................32
Determining A Breach Of Duty ......................................................................................................................................................32
Determining Whether There Was A Duty To Act ............................................................................................................................32
ICM Principles..................................................................................................................................................................................32
ICM Principle 1: Establish Context .................................................................................................................................................33

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 2 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 ICM Principle 2: Define Applicable Controls ...................................................................................................................................34
ICM Principle 3: Assign Maturity-Based Criteria ............................................................................................................................35
ICM Principle 4: Publish Policies & Standards ................................................................................................................................35
ICM Principle 5: Assign Stakeholder Accountability........................................................................................................................35
ICM Principle 6: Maintain Situational Awareness ..........................................................................................................................36
ICM Principle 7: Manage Risk........................................................................................................................................................36
ICM Principle 8: Evolve Processes ..................................................................................................................................................37
Section 8. Cybersecurity & Data Privacy Capability Maturity Model (C|P-CMM) ............................................... 39
Well Established Maturity Model ....................................................................................................................................................39
Nested Approach To Maturity .........................................................................................................................................................39
Maturity (Governance) ≠ Assurance (Security) ................................................................................................................................40
Defining C|P-CMM Levels ................................................................................................................................................................40
C|P-CMM Level 0 (L0) - Not Performed .........................................................................................................................................41
C|P-CMM Level 1 (L1) - Performed Informally ...............................................................................................................................41
C|P-CMM Level 2 (L2) - Planned & Tracked ...................................................................................................................................41
C|P-CMM Level 3 (L3) - Well Defined ............................................................................................................................................42
C|P-CMM Level 4 (L4) - Quantitatively Controlled .........................................................................................................................42
C|P-CMM Level 5 (L5) - Continuously Improving............................................................................................................................43
Defining A Capability Maturity “Sweet Spot” ..................................................................................................................................44
Negligence Considerations............................................................................................................................................................44
Risk Considerations ......................................................................................................................................................................44
Process Review Lag Considerations ...............................................................................................................................................44
Stakeholder Value Considerations .................................................................................................................................................44
Analog Example – Sit / Crawl / Walk / Run / Sprint / Hurdle ..........................................................................................................45
Maturity Model Use Cases...............................................................................................................................................................45
Use Case #1 – Objective Criteria To Build A Cybersecurity & Privacy Program ................................................................................46
Use Case #2 – Assist Project Teams To Appropriately Plan & Budget Secure Practices ....................................................................47
Use Case #3 – Provide Objective Criteria To Evaluate Third-Party Service Provider Security ............................................................48
Use Case #4 – Due Diligence In Mergers & Acquisitions (M&A) ......................................................................................................49
Section 9. Cybersecurity & Data Privacy Risk Management Model (C|P-RMM) ................................................. 51
Risk Management Discussion Protections .......................................................................................................................................52
Baselining Risk Management Terminology ......................................................................................................................................53
Understanding The Differences: Threats vs Vulnerabilities vs Risks ................................................................................................54
Understanding The Differences Between: Risk Tolerance vs Risk Threshold vs Risk Appetite...........................................................55
Risk Management Options ..............................................................................................................................................................61
Practical Risk Management Example ............................................................................................................................................61
Summarizing The Integration Of Risk Management & Business Planning ........................................................................................61
Risk Management: Strategic Considerations .................................................................................................................................62
Risk Management: Operational Considerations.............................................................................................................................63
Risk Management: Tactical Considerations ...................................................................................................................................63
Using The C|P-RMM ........................................................................................................................................................................65
C|P-RMM Step 1. Identify Risk Management Principles .................................................................................................................66
C|P-RMM Step 2. Identify, Implement & Document Critical Dependencies. ....................................................................................66
C|P-RMM Step 3. Formalize Risk Management Practices ..............................................................................................................67
C|P-RMM Step 4. Establish A Risk Catalog ....................................................................................................................................67
C|P-RMM Step 5. Establish A Threat Catalog ................................................................................................................................67
C|P-RMM Step 6. Establish A Controls Catalog..............................................................................................................................67
C|P-RMM Step 7. Define Capability Maturity Model (CMM) Targets .............................................................................................68
C|P-RMM Step 8. Perform Risk Assessments .................................................................................................................................68
C|P-RMM Step 9. Establish The Context For Assessing Risks ..........................................................................................................69
C|P-RMM Step 10. Controls Gap Assessment ................................................................................................................................70
C|P-RMM Step 11. Assess Controls To Determine Findings ............................................................................................................70
C|P-RMM Step 12. Prioritize Identified Deficiencies.......................................................................................................................72
C|P-RMM Step 13. Calculating Risk...............................................................................................................................................72
C|P-RMM Step 14. Risk Determination: Report on Conformity (ROC) .............................................................................................72
C|P-RMM Step 15. Identify The Appropriate Management Audience.............................................................................................74
C|P-RMM Step 16. Management Determines Risk Treatment .......................................................................................................75

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 3 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 C|P-RMM Step 17. Implement & Document Risk Treatment ..........................................................................................................75
Calculating Risk: Inherent Risk vs Residual Risk ...............................................................................................................................75
C|P-RMM Calculations Step 1: Calculate The Inherent Risk............................................................................................................76
C|P-RMM Calculations Step 2: Account For Control Weighting ......................................................................................................76
C|P-RMM Calculations Step 3: Account For Maturity Level Targets ...............................................................................................76
C|P-RMM Calculations Step 4: Account For Mitigating Factors To Determine Residual Risk ...........................................................76
Section 10. SCF Cybersecurity & Data Protection Assessment Standards (CDPAS)............................................. 77
CDPAS Purpose................................................................................................................................................................................77
CDPAS Intent ...................................................................................................................................................................................77
CDPAS Standards .............................................................................................................................................................................77
Section 11. Secure Controls Framework Conformity Assessment Program (SCF CAP)........................................ 79
SCF CAP Body of Knowledge (SCF CAP BoK) .....................................................................................................................................79
ABC’s of Conformity Assessment .....................................................................................................................................................79
Section 12. Risk & Threat Catalogs ..................................................................................................................... 80
SCF Risk Catalog...............................................................................................................................................................................80
SCF Threat Catalog...........................................................................................................................................................................83
Natural Threats ............................................................................................................................................................................83
Manmade Threats ........................................................................................................................................................................84
Section 13. Assessment Objectives (AOs) ........................................................................................................... 87
AO Origins .......................................................................................................................................................................................87
Objective Assessment Criteria .........................................................................................................................................................87
Section 14. Evidence Request List (ERL) .............................................................................................................. 88
Reasonable Assessment Artifacts ....................................................................................................................................................88
Section 15. Possible Solutions & Considerations ................................................................................................ 89
Solutions for Micro-Small Business ..................................................................................................................................................89
Solutions for Small Business ............................................................................................................................................................89
Solutions for Medium Business .......................................................................................................................................................89
Solutions for Large Business ............................................................................................................................................................89
Solutions for Enterprises .................................................................................................................................................................89
Section 16. Pre-Defined Control Sets .................................................................................................................. 90
SCF-B (Business Mergers & Acquisitions) .........................................................................................................................................90
SCF-I (Cyber Liability Insurance).......................................................................................................................................................90
SCF-E (Embedded Technology) ........................................................................................................................................................90
SCF-M (MSP/MSSP Secure Practices Baseline).................................................................................................................................90
SCF-R (Ransomware Protection) ......................................................................................................................................................91
SCF-Z (Zero Trust Architecture) ........................................................................................................................................................91
Section 17. Frequently Asked Questions (FAQ) .................................................................................................. 92
General FAQ ....................................................................................................................................................................................92
GEN-FAQ-001: How Do I Start Using The SCF? ...............................................................................................................................92
GEN-FAQ-002: How Do I Select Controls Specific To My Needs? .....................................................................................................92
GEN-FAQ-003: How Often Is The SCF Updated?.............................................................................................................................93
GEN-FAQ-004: Why Is The SCF Free To Use?..................................................................................................................................93
GEN-FAQ-005: What Does "Mechanisms Exist" Mean? .................................................................................................................93
GEN-FAQ-006: Are There Restrictions On The Use of the SCF? .......................................................................................................93
GEN-FAQ-007: How Does The Control Weighting Work In The SCF? ...............................................................................................93
GEN-FAQ-008: Why Does The SCF Say It Is The Common Controls Framework?..............................................................................93
GEN-FAQ-009: What Is The Cybersecurity & Data Protection Assessment Standards (CDPAS)?.......................................................94
Conformity Assessment Program (CAP) FAQ ...................................................................................................................................95
CAP-FAQ-001: What Is The SCF CAP? ............................................................................................................................................95
CAP-FAQ-002: What Is A Conformity Assessment? ........................................................................................................................95

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 4 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 1. TERMINOLOGY & ACRONYMS
The SCF Council recognizes two (2) primary sources for authoritative definitions for cybersecurity and data privacy terminology:
 The National Institute of Standards and Technology (NIST) IR 7298, Glossary of Key Cybersecurity Terms, is the approved
reference document used to define cybersecurity-related terminology;1 and
 NIST Glossary.2

From the context of building a cybersecurity and data privacy program, it is important to clarify mandatory versus optional criteria: 3
 The terms “SHALL” and “SHALL NOT” indicate requirements:
o To be followed strictly in order to conform; and
o From which no deviation is permitted.
 The terms “SHOULD” and “SHOULD NOT” indicate that:
o Among several possibilities one (1) is recommended as particularly suitable, without mentioning or excluding
others;
o A certain course of action is preferred, but not necessarily required; or
o A certain possibility, or course of action, is discouraged, but not prohibited.
 The terms “MAY” and “NEED NOT” indicate a course of action permissible within reasonable limits.
 The terms “CAN” and “CANNOT” indicate:
o A possibility and capability; or
o The absence of that possibility or capability.

TERMINOLOGY STANDARDIZATION
Within the cybersecurity profession, the term “control” can be applied to a variety of contexts and can serve multiple purposes.
When used in content with the SCF, a control is a mechanism (e.g., a safeguard or countermeasure) designed to address
protection needs specified by security requirements.
 Controls are:
o The power to make decisions about how something is managed or how something is done;
o The ability to direct the actions of someone or something;
o An action, method or law that limits; and/or
o A device or mechanism used to regulate or guide the operation of a machine, apparatus or system.
 Requirements are statements that translate, or express, a need and its associated constraints and conditions.

Additional clarification for assessment-relevant terminology:

 Assessment Boundary. The scope of an organization’s control implementation to which assessment of objects is applied:
o An assessment may involve multiple assessment boundaries; and
o Assessment boundary may be defined as the People, Processes, Technologies, Data and/or Facilities (PPTDF)
that comprise:
 The entire organization;
 A specific contract, project or initiative;
 A specific Business Unit (BU) within an organization; or
 A specific country, or geographic region, of the organization’s business operations.
 Assessment Object. The item (e.g., specifications, mechanisms, activities, individuals) upon which an assessment
method is applied during an assessment.
 Control Inheritance: Security control inheritance is a situation in which an information system or application receives
protection from security controls (or portions of security controls) that are developed, implemented, assessed,
authorized, and monitored by entities other than those responsible for the system or application; entities either internal
or external to the organization where the system or application resides. 4
 Material Control. When a deficiency, or absence, of a specific control poses a material impact, that control is designated
as a material control. A material control is such a fundamental cybersecurity and/or data privacy control that:
o It is not capable of having compensating controls; and
o Its absence, or failure, exposes an organization to such a degree that it could have a material impact.
 Material Risk. When an identified risk poses a material impact, that is a material risk.

1 NIST IR 7298 - https://nvlpubs.nist.gov/nistpubs/ir/2019/NIST.IR.7298r3.pdf

2 NIST Glossary - https://csrc.nist.gov/glossary
3 NIST SP 800-63A - https://pages.nist.gov/800-63-3/sp800-63a.html
4 NIST Glossary for Security Control Inheritance - https://csrc.nist.gov/glossary/term/security_control_inheritance

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 5 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 o A material risk is a quantitative or qualitative scenario where the exposure to danger, harm or loss has a material
impact (e.g., significant financial impact, potential class action lawsuit, death related to product usage, etc.);
and
o A material risk should be identified and documented in an organization's "risk catalog" that chronicles the
organization's relevant and plausible risks.
 Material Threat. When an identified threat poses a material impact, that is a material threat.
o A material threat is a vector that causes damage or danger that has a material impact (e.g., poorly governed
Artificial Intelligence (AI) initiatives, nation state hacking operations, dysfunctional internal management
practices, etc.); and
o A material threat should be identified and documented in an organization's "threat catalog" that chronicles the
organization's relevant and plausible threats.
 Material Incident. When an incident poses a material impact, that is a material incident.
o A material incident is an occurrence that does or has the potential to:
 Jeopardize the Confidentiality, Integrity, Availability and/or Safety (CIAS) of a system, application,
service or the data that it processes, stores and/or transmits with a material impact on the organization;
and/or
 Constitute a violation, or imminent threat of violation, of an organization's policies, standards,
procedures or acceptable use practices that has a material impact (e.g., malware on sensitive and/or
regulated systems, emergent AI actions, illegal conduct, business interruption, etc.).
o Reasonably foreseeable material incidents should be documented in an organization's Incident Response Plan
(IRP) that chronicles the organization's relevant and plausible incidents, so there are appropriate practices to
identify, respond to and recover from such incidents.
 Material Weakness. A material weakness is a deficiency, or a combination of deficiencies, in an organization's
cybersecurity and/or data privacy controls (across its supply chain) where it is probable that reasonable threats will not
be prevented or detected in a timely manner that directly, or indirectly, affects assurance that the organization can adhere
to its stated risk tolerance.
o When there is an existing deficiency (e.g., control deficiency) that poses a material impact, that is a material
weakness (e.g., inability to maintain access control, lack of situational awareness to enable the timely
identification and response to incidents, etc.).
o A material weakness will be identified as part of a gap assessment, audit or other form of assessment as a finding
due to one (1), or more, control deficiencies. A material weakness should be documented in an organization's
Plan of Action & Milestones (POA&M), risk register, or similar tracking mechanism for remediation purposes.
 Mechanism. A mechanism can be described as a: 5
o Process or system that is used to produce a particular result; or
o Device or method for achieving a security-relevant purpose.
 Reciprocity. Reciprocity is an agreement among participating organizations to accept each other’s: 6
o Security assessments to reuse system resources; and/or
o Assessed security posture to share information.
 Risk. A risk is:
o A situation where someone, or something valued, is exposed to danger, harm or loss (noun); or
o To expose someone or something valued to danger, harm or loss (verb).
 Risk Appetite: The types and amount of risk, on a broad level, an organization is willing to accept in its pursuit of value. 7
 Risk Tolerance: The level of risk an entity is willing to assume in order to achieve a potentially desired result. 8
 Risk Threshold: Values used to establish concrete decision points and operational control limits to trigger management
action and response escalation.9
 Threat. A threat:
o Is a person, or thing, likely to cause damage or danger (noun); or
o Indicates impending damage or danger (verb).

5 NIST Glossary for Mechanism - https://csrc.nist.gov/glossary/term/mechanism

6 NIST Glossary for Reciprocity - https://csrc.nist.gov/glossary/term/reciprocity
7 NIST Glossary for Risk Appetite - https://csrc.nist.gov/glossary/term/risk_appetite
8 NIST Glossary for Risk Tolerance - https://csrc.nist.gov/glossary/term/risk_tolerance
9 NIST Glossary for Thresholds - https://csrc.nist.gov/glossary/term/thresholds

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 6 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
ACRONYMS
The following acronyms are defined as:
Acronym Term Definition
1PD First Party Declaration 1PDs are self-attestations (e.g., internal assessments).

3PA are attestations made by an independent third-party, generally in the

3PA Third-Party Attestation
performance of an assessment or audit.
Third-Party Assessment, Assessment, attestation and certification services performed by a third-party
3PAAC Attestation and organization.
Certification Services
Third-Party Assessment A company that performs assessment, attestation and certification services.
3PAO
Organization
Artificial Intelligence and Tools that are advanced enough to act with limited human involvement through
AAT Autonomous Artificial Intelligence (AI), Machine Learning (ML) or similar autonomous
Technologies technologies.
AOs are objective statements that establish the desired outcome for the
AO Assessment Objective assessment for a specific control. There may be multiple AOs associated with a
control.
APIT assessments utilize automation to augment a traditional assessment
methodology, where AAT is used to compare the desired state of conformity versus
the current state via machine-readable configurations and/or assessment
evidence:
APIT Automated Point In Time  Relevant to a specific point in time (time at which the control was evaluated);
 In situations where technology cannot evaluate evidence, evidence is
manually reviewed; and
 The combined output of automated and manual reviews of artifacts is used
to derive a finding.
Assessment Technical ATE are assessment team members who have the necessary subject matters
ATE
Expert expertise to conduct a specific part of an assessment. ATE report to the ATL.
An ATL is an individual assigned by the 3PAO to lead its assessment team in the
ATL Assessment Team Lead
conduct of 3PAAC Services.
AEHR assessments are used for ongoing, continuous control assessments:
 AAT continuously evaluates controls by comparing the desired state of
conformity versus the current state through machine-readable
Automated Evidence with configurations and/or assessment evidence; and
AEHR
Human Assessment  Recurring human reviews:
o Evaluate the legitimacy of the results from automated control
assessments; and
o Validate the automated evidence review process to derive a finding.
Confidentiality, Integrity, CIAS is an evolution of the “CIA Triad” concept that defines the purpose of security
CIAS
Availability and/or Safety controls. It adds the component of Safety.
COI involves situations in which a personal interest, or relationship, conflicts with
COI Conflict of Interest
the faithful performance of an official duty.
Continuing Professional CPE describes the ongoing process of improving skills and competencies through
CPE
Education formal or informal educational activities.
DSR are discretionary cybersecurity and/or data privacy controls that address
Discretionary Security
DSR voluntary industry practices or internal requirements. DSR are primarily internally
Requirements
influenced, based on the organization’s respective industry and risk tolerance.
ERLs establish a finite list of supporting evidence used in an assessment:
 Prior to the start of the assessment, an ERL is provided by the 3PAO to the
OSA.
ERL Evidence Request List
 The ERL’s standardized evidence expectations allow OSAs to have sufficient
time to accumulate reasonable evidence to determine the adequacy of
control design and operation.
An independent, third-party organization that provides services, technologies,
ESP External Service Provider facilities and/or people. ESPs include but are not limited to:
 Consulting / professional services;

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 7 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
  Software development;
 Staff augmentation; and
 Technology support (e.g., Managed Services Provider (MSP)).
MCR are minimum requirements that must be addressed to comply with applicable
Minimum Compliance
MCR laws, regulations and contracts. MCR are primarily externally-influenced, based on
Requirements
industry, government, state and local regulations.
MPIT assessments are a traditional assessment methodology:
 Relevant to a specific point in time (time at which the control was evaluated);
MPIT Manual Point In Time
and
 Relies on the manual review of artifacts to derive a finding.
MLC are specific to each maturity level to define reasonable staffing, technologies
MLC Maturity Level Criteria
and processes to implement the desired level of maturity.
Master Services MSAs are comprehensive contracts between two parties that establish terms and
MSA
Agreement conditions of current and future transactions.
Organization Seeking A company, entity or business unit seeking the external assessment.
OSA
Assessment
Data protection through the design and governance of processes and technologies.
PbD Privacy by Design PbD prioritizes data protection as a core business requirement, rather than a
technical feature.
Refers to a RASCI matrix that defines responsibilities associated with individuals or
teams:
 Responsible - entity directly responsible for performing a task (e.g.,
control/process operator);
 Accountable - entity overall responsible for the task being performed and has
Responsible,
the authority to delegate the task to others (e.g., control/process owner);
RASCI Accountable, Supportive,
 Supportive - entity(ies) under the coordination of the Responsible person for
Consulted & Informed
support in performing the task;
 Consulted - entity(ies) not directly involved in task execution but were
consulted for subject matter expertise; and
 Informed - entity(ies) not involved in task execution but are informed when the
task is completed.
A formalized report that issues an assessment conformity designation. The ROC
ROC Report on Conformity summarizes the assessment findings and justification for the conformity
designation.
Processes and technologies are designed and built in a way that protects against
SbD Secure by Design reasonable threats. SbD prioritizes cybersecurity as a core business requirement,
rather than treating it as a technical feature.
SOWs are contracts that cover the work management aspects of a project (e.g.,
SOW Statement of Work scope, timeline, cost, responsibilities, etc.).

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 8 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 2. INTRODUCTION TO THE SECURE CONTROLS FRAMEWORK®
The Secure Controls Framework® (SCF) focuses on internal cybersecurity and data protection controls. These are the
administrative, technical and physical controls (e.g., policies, standards, procedures, technologies and associated processes)
that are designed to provide reasonable assurance that business objectives will be achieved and undesired events will be
prevented, detected and/or remediated. There is no cost to use the SCF and quite a few Governance, Risk and Compliance (GRC)
platforms natively support the SCF as a built-in control set.

The SCF is a more efficient way to operationalize cybersecurity and data privacy operations by simplifying the underlying controls
that comprise the basis of an organization’s cybersecurity and data privacy program. The reality is that most organizations struggle
with defining the minimum-security requirements that are necessary to address both (1) applicable compliance obligations and
(2) the need for secure practices. The SCF provides a straightforward and scalable method to define those “must have” and “nice
to have” requirements into a holistic control set to operationalize cybersecurity operations, risk management and third-party
governance.

In simple terms, the SCF is a metaframework, a “framework of frameworks.” It is a catalog of controls made up of over 200
authoritative sources (e.g., statutory, regulatory and contractual frameworks). This controls catalog contains over 1,200 controls
and is logically organized into thirty-three (33) domains. The structure of the SCF normalizes disparate control language into
something that is usable across technology, cybersecurity, data privacy and other departments where they can share the same
control language. The SCF enables not only intra-organization standardization, but inter-organization standardization (e.g.,
control GOV-03 means the same thing to one organization to any other organization using the SCF). The SCF targets silos, since
siloed practices within any organization are inefficient and can lead to poor security, due to poor communications and incorrect
assumptions.

The SCF is made up of volunteers who are specialists within the cybersecurity and data privacy professions. These people are
seasoned auditors, engineers, architects, incident responders, consultants and other specialists who live and breathe these
topics on a daily basis. The end product of their labor is "expert-derived content" that makes up the SCF.

WHY SHOULD AN ORGANIZATION USE THE SCF?

There is no sales pitch for using the SCF – it is a free resource so there is no financial
incentive for us to make companies use it. For companies that have just one or two
(1 or 2) compliance requirements, the SCF might be considered overkill for your
needs. However, for companies that have three or more (3+) compliance
requirements (e.g., organization that has requirements to address NIST 800-171,
NIST CSF, SOC 2 and GDPR), then the SCF is a great tool to streamline the
management of disparate cybersecurity & data privacy control frameworks.

In developing the SCF, we identified and analyzed over 200 cybersecurity and data
protection laws, regulations and frameworks. Through analyzing these thousands of
legal, regulatory and framework requirements, we identified the commonalities, and
this allows several thousand unique controls to be addressed by approximately
1,200 controls that make up the SCF. For instance, a requirement to maintain strong
passwords is not unique, since it is required by dozens of laws, regulations and
frameworks. This allows one well-worded SCF control to address multiple
requirements. This focus on simplicity and sustainability is key to the SCF, since it
can enable various teams to speak the same controls language, even though they
may have entirely different statutory, regulatory or contractual obligations that they
are working towards.

EXPERT INSIGHT (CONTROL SELECTION CONSIDERATIONS): Some people who are new to the SCF freak out due to their
misunderstanding where they think they have to all 1,200+ controls in the SCF. That is just not the case. It is best to visualize the
SCF as a “buffet of cybersecurity & data privacy controls,” where the presented buffet is a selection of 1,200+ controls. Just as
you do not eat everything possible on a buffet table, the same applies to the SCF’s control set where you only select the controls
you need. Once you know what is applicable to you, you can generate a customized control set that gives you just the controls
you need to address your statutory, regulatory and contractual obligations. The concept of tailoring the control set is explained at
the end of this section.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 9 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
WHAT THE SCF IS
The SCF is a comprehensive catalog of controls that is designed to enable companies to design, build and maintain secure
processes, systems and applications. The SCF addresses both cybersecurity & data privacy, so that these principles are designed
to be “baked in” at the strategic, operational and tactical levels.

The SCF is:

 A control set;
 A useful tool to provide a “Rosetta Stone” approach to organizing cybersecurity & data privacy controls so that the same
controls can be used among companies and teams (e.g., privacy, cybersecurity, IT, project, procurement, etc.); and
 Free for businesses to use. A result of a volunteer-led effort that uses “expert derived assessments” to perform the
mapping from the controls to applicable laws, regulations and other frameworks.

The SCF also contains helpful guidance on possible tools and solutions to address controls. Additionally, it contains maturity
criteria that can help an organization plan for and evaluate controls, based on a target maturity level.

WHAT THE SCF IS NOT

While the SCF is a comprehensive catalog of controls that is designed to enable companies to design, build and maintain secure
processes, systems and applications, the SCF will only ever be a control set and is not a “magic bullet” technology solution to
address every possible cybersecurity & data privacy compliance obligation that an organization faces.

The SCF is not:

 A substitute for performing due diligence and due care to understand and manage your specific compliance needs;
 A complete technology or documentation solution to address all your cybersecurity & data privacy needs (e.g., the
policies, standards, procedures and processes you need to have in place to be secure and compliant); and
 Infallible or guaranteed to meet every compliance requirement your organization offers, since the controls are mapped
based on expert-derived assessments to provide the control crosswalking that relies on human expertise and that is not
infallible.

ADDRESSING THE WHO? WHAT? WHERE? WHEN? WHY? AND HOW?

Ideally, the SCF can be used to address the “who, what where, when, why and how” for cybersecurity and data privacy at the
strategic, operational and tactical levels within your organization!

Using the SCF should be viewed as a long-term tool to not only help with compliance-related efforts but to ensure cybersecurity
& data privacy principles are properly designed, implemented and maintained. The SCF helps implement a holistic approach to
protecting the Confidentiality, Integrity, Availability and Safety (CIAS) of your data, systems, applications and other processes.
The SCF can be used to assist with strategic planning down to tactical needs that impact the people, processes and technologies
directly impacting your organization.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 10 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SCF CONTROL WEIGHTING EXPLANATION
The SCF assigns a value on a scale from 1-10, with 1 being the least important and 10 being the most important. These values are
subjective, based on SCF contributor discussion, since control weighting is important to help prioritize controls and assist with
the understanding what really matters from a risk management perspective. For an insight into the thought process, a control
weighting of 10 was framed as “Would you do business with an organization that did not have this control in place?” where certain
controls were identified as an absolute minimum from a risk threshold perspective from a “reasonable person” perspective.
 Those controls designated as a score of 10 should be considered a MATERIAL / KEY CONTROL (e.g., lack of or a
deficiency should be considered a material weakness).
 On the opposite side of the spectrum, a score of 1 was deemed “nice to have” but did not materially affect risk.

EXPERT INSIGHT (MATERIALITY): The intended usage of materiality is meant to provide relevant context regarding risk thresholds.
Materiality designations are intended to act as a "guard rail" for risk management decisions. A material weakness crosses an
organization’s risk threshold by making an actual difference to the organization, where systems, applications, services, personnel,
the organization and/or third-parties are, or may be, exposed to an unacceptable level of risk. A financial benchmark is commonly
used to determine materiality. From a financial impact perspective, for an item to be considered material, the control deficiency,
risk, threat or incident (singular or a combination) generally must meet one, or more, of the following criteria where the potential
financial impact is measured as: 10
 ≥ 5% of pre-tax income
 ≥ 0.5% of total assets
 ≥ 1% of total equity (shareholder value); and/or
 ≥ 0.5% of total revenue.

TAILORING IS REQUIRED - NOT ALL SCF CONTROLS ARE APPLICABLE TO YOUR ORGANIZATION
The SCF is a tool and is only as good as how it is used – just like a pocketknife shouldn’t be used as a prybar. If a SCF user incorrectly
scopes their requirements, the resulting controls will not address their applicable compliance requirements. That is not a
deficiency of the SCF – that is simply negligence on the part of the user of the tool.

To ensure scoping is done properly, it is imperative for you to speak with your legal, IT, project management, cybersecurity and
procurement teams. The reason for this collaboration is so that you can get a complete picture of all the applicable laws,
regulations and frameworks that your organization is legally obligated to comply with. Those teams will likely provide the best
insights into what is required, and this list of requirements will then make it simple to go through and customize the SCF for your
specific needs!

Understanding the requirements for both cybersecurity & data privacy principles involves a simple process of distilling
expectations. This process is all part of documenting reasonable expectations that are “right-sized” for an organization, since
every organization has unique requirements.

Beyond just using compliance terminology properly, understanding which of the three types of compliance is crucial in managing
both cybersecurity & data privacy risk within an organization. The difference between non-compliance can be as stark as (1) going
to jail, (2) getting fined, (3) getting sued, (4) losing a contract or (5) an unpleasant combination of the previous options.

Understanding the “hierarchy of pain” with compliance leads to well-informed risk decisions that influence technology
purchases, staffing resources and management involvement. That is why it serves both cybersecurity and IT professionals well to
understand the compliance landscape for their benefit, since presenting issues of non-compliance in a compelling business
context to get the resources needed to complete their jobs.

The most common types of compliance requirements are:

1. Statutory;
2. Regulatory; or
3. Contractual.

10 Norwegian Research Council - https://snf.no/media/yemnkmbh/a51_00.pdf

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 11 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
STATUTORY REQUIREMENTS
Statutory obligations are required by law and refer to current laws that were passed by a state or federal government. These laws
are generally static and rarely change unless a new law is passed that updates it (e.g., HITECH Act, provided updates to HIPAA,
CPRA provided updates to CCPA, etc.).

From a cybersecurity & data privacy perspective, statutory compliance examples include but are not limited to:
 US – Federal Laws
o Children’s Online Privacy Protection Act (COPPA)
o Fair and Accurate Credit Transactions Act (FACTA) – including “Red Flags” rule
o Family Education Rights and Privacy Act (FERPA)
o Federal Information Security Management Act (FISMA)
o Federal Trade Commission (FTC) Act
o Gramm-Leach-Bliley Act (GLBA)
o Health Insurance Portability and Accountability Act (HIPAA) / HITECH Act
o Sarbanes-Oxley Act (SOX)
 US – State Laws
o California SB1386
o Massachusetts 201 CMR 17.00
o Oregon ORS 646A.622
 International Laws
o Canada – Personal Information Protection and Electronic Documents Act (PIPEDA)
o UK – Data Protection Act (DPA)
o Other countries’ variations of Personal Data Protect Acts (PDPA)

REGULATORY REQUIREMENTS
Regulatory obligations are required by law, but they are different from statutory requirements in that these requirements refer to
rules issued by a regulating body that is appointed by a state or federal government. These are legal requirements through proxy,
where the regulating body is the source of the requirement. It is important to keep in mind that regulatory requirements tend to
change more often than statutory requirements.

From a cybersecurity & data privacy perspective, regulatory compliance examples include but are not limited to:
 US Regulations
o Defense Federal Acquisition Regulation Supplement (DFARS) (NIST 800-171)
o Federal Acquisition Regulation (FAR)
o Federal Risk and Authorization Management Program (FedRAMP)
o DoD Information Assurance Risk Management Framework (DIARMF)
o National Industrial Security Program Operating Manual (NISPOM)
o New York Department of Financial Services 23 NYCRR 500
 International Regulations
o European Union General Data Protection Regulation (EU GDPR)

CONTRACTUAL REQUIREMENTS
Contractual obligations are required by legal contracts between private parties. This may be as simple as a cybersecurity or
privacy addendum in a vendor contract that calls out unique requirements, but it also includes broader requirements from an
industry association that membership brings certain obligations.

From a cybersecurity & data privacy perspective, common contractual compliance examples include but are not limited to:
 Cybersecurity Supply Chain Risk Management (C-SCRM) (e.g., NIST SP 800-161 R1)
 Payment Card Industry Data Security Standard (PCI DSS)
 Service Organization Control (SOC)
 Generally Accepted Privacy Principles (GAPP)
 Center for Internet Security (CIS) Critical Security Controls (CSC)
 Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM)

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 12 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
TAILORING SCF CONTROLS - DEFINING “MUST HAVE” VS “NICE TO HAVE” CONTROLS
Secure and compliant operations exist when applicable controls are properly scoped and implemented. To assist in this process,
an organization’s applicable controls should be categorized according to “must have” vs “nice to have” requirements:
 Minimum Compliance Requirements (MCR) are the absolute minimum requirements that must be addressed to comply
with applicable laws, regulations and contracts. MCR are primarily externally-influenced, based on industry, government,
state and local regulations. MCR should never imply adequacy for secure practices and data protection, since they are
merely compliance-related.
 Discretionary Security Requirements (DSR) are tied to the organization’s risk appetite since DSR are “above and beyond”
MCR, where the organization self-identifies additional cybersecurity & data privacy controls to address voluntary industry
practices or internal requirements, such as findings from internal audits or risk assessments. DSR are primarily internally-
influenced, based on the organization’s respective industry and risk tolerance. While MCR establishes the foundational
floor that must be adhered to, DSR are where organizations often achieve improved efficiency, automation and enhanced
security.

Fundamentally, the SCF is an Excel spreadsheet. Therefore, you can use your Excel skills to manually filter the requirements. If
you are comfortable with Excel, it might take you 5-10 minutes to do this filtering, depending on how many requirements you need
to map to.

Within the SCF, there is a column labelled “Minimum Security Requirements (MSR) MCR + MSR” that will assist you in this process.

Follow these steps to tailor the SCF:

1. Either hide or delete all of the columns containing laws, regulations or frameworks that
are not applicable to your organization (e.g., if you only have to comply with ISO 27002,
PCI DSS and EU GDPR, then you can delete or hide all other mapping columns but
those).Using the filter option in Excel (little gray arrow on the top row in each column),
you would then filter the columns to only show cells that contain content (e.g., don’t
show blank cells in that column).
2. A selection of either MCR or DSR will automatically select the MSR + DSR column:
a. In the MCR column, simply put an “x” to mark that control as being “must have”
controls.
b. In the DSR column, simply put an “x” to mark that control as being “nice to have”
controls.
3. Unfilter the column you just performed this task on and do it to the next law, regulation
or framework that you need to map.
4. Repeat steps 2 and step 3 until all your applicable laws, regulations and frameworks are
mapped to.

EXPERT INSIGHT (BASELINING): The MSR + DSR resulting column shows the SCF controls that considered an organization's
Minimum Security Requirements (MSR) that will be used. The MSR is the baseline set of controls the organization should
implement to be both secure and compliant.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 13 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 3. DESIGNING & BUILDING AN AUDIT-READY CYBERSECURITY & DATA PRIVACY PROGRAM
Building an audit-ready cybersecurity & data privacy program requires addressing the holistic nature of cybersecurity & data
privacy concerning how People, Processes, Technologies, Data & Facilities (PPTDF) impact security practices.

Building a security program that routinely incorporates cybersecurity & data protection practices into daily operations requires a
mastery of the basics. A useful analogy is with LEGO®, the children's toy. With LEGO® you can build nearly anything you want, but
it starts with the understanding of the various LEGO® shapes and how they either snap together or are incompatible.
 Mastering the fundamentals of LEGO® building enables someone to become immensely creative since that individual
knows how everything interacts. It becomes possible to either follow the instructions or design and build structures based
on their own imagination.
 Conversely, when an individual ignores the fundamental concepts with LEGO® building, any created structure will be
weak and include systemic flaws.

Cybersecurity and data privacy controls are not much different from LEGO® blocks, since those disciplines are made up of
numerous building blocks that all come together to build secure systems and processes. The lack of critical building blocks will
lead to insecure and poorly architected solutions. When you envision each component that makes up a cybersecurity or data
privacy “best practice” is a LEGO® block, it is possible to conceptualize how certain requirements are the foundation that form
the basis for other components to attach to. Only when all the building blocks come together and take shape do you get a
functional security / privacy program!

Think of the SCF as a toolkit for you to build out your overall security program domain-by-domain so that cybersecurity & data
privacy principles are designed, implemented and managed by default!

PEOPLE, PROCESSES, TECHNOLOGY, DATA & FACILITIES (PPTDF)

The concept is to address the broader PPTDF that are what controls fundamentally
exists to govern.

The PPTDF model provides a comprehensive approach to address control

applicability. These five (5) components provide a lens to view the
applicability of controls:
1. People – Applicable to humans (e.g., training, background checks,
non-disclosure agreements, etc.).
2. Processes – Applicable to administrative work performed (e.g.,
processes, procedures, administrative documentation, etc.).
3. Technology – Applicable to systems, applications and services
(e.g., secure baseline configurations, patching, etc.).
4. Data – Applicable to data protection (e.g., encrypting
sensitive/regulated data, applying metatags, etc.).
5. Facilities – Applicable to infrastructure assets (e.g., physical access,
HVAC systems, visitor control, etc.).

HOLISTIC APPROACH TO ADDRESS CONTROL APPLICABILITY

Cybersecurity practitioners generally agree that the importance of robust cybersecurity and data protection controls cannot be
overstated. However, the applicability of those controls is sometimes in question since not all controls are applicable. To help
demonstrate the applicable nature of controls:
 An employee cannot have a secure baseline configuration applied;
 An Incident Response Plan (IRP) cannot sign a Non-Disclosure Agreement (NDA), use Multi-Factor Authentication (MFA)
or be patched;
 You cannot apply end user training to a firewall;
 Sensitive / regulated data cannot be assigned roles and responsibilities; and
 Your data center cannot undergo employee background screening.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 14 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
NIST IR 8477 - SET THEORY RELATIONSHIP MAPPING (STRM)
Starting in 2024, the SCF began leveraging the Set Theory Relationship Mapping (STRM) for crosswalk mapping. STRM is generally
well-suited to evaluate cybersecurity and data privacy laws, regulations and frameworks. With the publishing of NIST IR 8477,
Mapping Relationships Between Documentary Standards, Regulations, Frameworks, and Guidelines: Developing Cybersecurity
and data privacy Concept Mappings it establishes the US Government's playbook for how to perform crosswalk mapping between
different cybersecurity and data privacy laws, regulations and frameworks. 11

NIST IR 8477 is part of NIST’s broader NIST OLIR Program that is an “effort to facilitate Subject Matter Experts (SMEs) in defining
standardized online informative references (OLIRs) between elements of their documents, products, and services and elements
of NIST documents…” The SCF currently participates in the National Online Informative References (OLIR) Program and with
NIST's preference for STRM, we decided an aligned crosswalk mapping methodology makes sense.12

For SCF’s STRM practices, the SCF is always the “reference document” and the law, regulation or framework being mapped to is
always the “focal document.”

REFERENCE DOCUMENT (RD) FOCAL DOCUMENT (FD)

More information and graphics can be viewed at:

https://securecontrolsframework.com/content/strm/scf-set-theory-relationship-mapping.pdf

11 NIST IR 8477 - https://csrc.nist.gov/pubs/ir/8477/final

12 SCF NIST OLIR Participation - https://securecontrolsframework.com/nist-olir-participation/

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 15 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
STRM RELATIONSHIP TYPES
Within STRM, there are five (5) relationship types:
1. Subset Of;
2. Intersects With;
3. Equal;
4. Superset Of; and
5. No Relationship.

STRM RELATIONSHIP TYPE #1: SUBSET OF

Focal Document Element is a subset of SCF control. In other words, SCF control contains everything that Focal Document
Element does and more.

STRM RELATIONSHIP TYPE #2: INTERSECTS WITH

SCF control has some overlap with Focal Document Element, but each includes content that the other does not.

STRM RELATIONSHIP TYPE #3: EQUAL

SCF control and Focal Document Element are the same, although not necessarily identical.

STRM RELATIONSHIP TYPE #4: SUPERSET OF

Focal Document Element is a superset of SCF control. In other words, Focal Document Element contains everything that SCF
control does and more.

STRM RELATIONSHIP TYPE #5: NO RELATIONSHIP

SCF control and Focal Document Element are unrelated; their content does not overlap.

EXPERT-DERIVED CONTENT (EDC) VS NATURAL LANGUAGE PROCESSING (NLP)

NIST IR 8477 provides the “gold standard” practice for how an individual can perform crosswalk mapping with no technology
needed, where it can literally be performed with a pencil and piece of paper. Children learn the process of diagramming sentences
in grade school (e.g., Reed–Kellogg model) with pencils and paper. This is the process of graphically identifying nouns, verbs,
adjectives and modifiers to teach proper sentence structure for how various components of language work together to
communicate an idea. With the advent of Artificial Intelligence (AI), the ability to diagram sentences in both computer and human-
readable format is achievable through Natural Language Processing (NLP).

From a cybersecurity crosswalking perspective, NLP can be used to evaluate a control statement (e.g., must have firewall) to
identify the noun (e.g., firewall) and verb (e.g., must have) to determine the relative strength it maps to a different control (e.g.,
shall have network defense appliances). Where that becomes interesting is (1) protecting the underlying content (e.g., Intellectual
Property (IP)) and (2) patentability.

Works created by non-humans, including AI, are not eligible for copyright protection.13 While the SCF leverages expert-derived
content (e.g., human subject-matter experts), other metaframework solutions use NLP to create AI-generated crosswalk
mapping. Solutions leveraging NLP forfeit their IP since AI-generated content is currently prohibited from copyright protections
due to the content not being the work of a human creator. Therefore, NLP-generated content could be considered free content
from an IP perspective, since a copyright of AI-generated content would not be enforceable.

AI-based solutions in the GRC space also face a patentability issue due to the "mental steps" doctrine. In 2014, the US Supreme
Court ruled that inventions are ineligible for patenting if the patent claim is something a human could do in their mind or with
paper and pencil (e.g., a human performing sentence diagramming on a piece of paper and comparing the results of that sentence
diagram with another). That landmark case (Alice Corp. v. CLS Bank International) established a new uncertainty about patent
eligibility of AI and machine learning technologies. The result of Alice is that patents issued for compliance solutions leveraging
NLP to perform crosswalk mapping may not hold up to scrutiny by the Patent Trial and Appeal Board (PTAB) given NIST published
a document that describes how to perform crosswalk mapping without the assistance of technology.

13 37CFR Part 202 - https://www.federalregister.gov/documents/2023/03/16/2023-05321/copyright-registration-guidance-works-containing-material-generated-

by-artificial-intelligence

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 16 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 4. UNDERSTANDING FUNDAMENTAL GOVERNANCE, RISK & COMPLIANCE (GRC) FUNCTIONS
GRC can be a costly and labor-intensive endeavor, so what justifies the investment? Essentially, GRC functions help avoid
negligence, with the added benefit of improved IT/cyber/privacy operating effectiveness. The reality of the situation is your
company invests in cybersecurity & data privacy as a necessity. This necessity is driven in large part by laws, regulations and
contractual requirements that it is legally obligated to comply with. It is also driven by the desire to protect its public image from
damaging acts that happen when cybersecurity & data privacy practices are ignored. Regardless of the specific reason, those
charged with developing, implementing and running your organization’s cybersecurity & data privacy program must do so in a
reasonable manner that would withstand scrutiny that could take the form of an external auditor, regulator or prosecuting
attorney.
How fast would you drive your car if you didn’t have any brakes? Think
about that for a moment - you would likely drive at a crawl in first gear, and
even then, you would invariably have accidents as you bump into objects
and other vehicles to slow down. Brakes on a vehicle actually allow you to
drive fast, while help provide the ability to safely navigate dangers on the
road!

While it is not the most flattering analogy, GRC is akin to the brakes on your
car, where they enable a business’ operations to go fast and avoid
catastrophic accidents safely. Without those "brakes", an accident is a
certainty! These brakes that enable a business’ operations to stay within the
guardrails are its cybersecurity policies, standards and procedures. These
requirements constitute “reasonable practices” that the organization is
required to implement and maintain to avoid being negligent.

GRC IS A PLAN, DO, CHECK & ACT (PDCA) ADVENTURE – THAT IS A CONCEPT THAT SHOULD BE EMBRACED, NOT
FOUGHT AGAINST
GRC most often deals with legally-binding requirements, so it is important to understand that negligence is situationally-
dependent. For example, an intoxicated driver who gets behind the wheel acting negligently. However, when sober, that same
individual is a champion race car driver who is highly skilled and would not be considered incompetent in any regard. In this
example, driving intoxicated constitutes a negligent act and shows that negligence has nothing to do with being incompetent. The
point is to demonstrate that an organization can employ many highly-competent personnel, but even competent people can
behave in a negligent manner. GRC fundamentally exists to help an organization avoid circumstances that could be construed as
negligent acts.

[graphic download - https://securecontrolsframework.com/content/Plan-Do-Check-Act.pdf]

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 17 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
Considering how business practices continuously evolve, so must cybersecurity practices. The Plan, Do, Check & Act (PDCA)
process (also referred to as the Deming Cycle) enables the GRC function to continuously evaluate risks, threats and performance
trends, so that the organization's leadership can take the necessary steps to minimize risk by modifying how PPTDF work together
to keep everything both secure and operational. The PDCA approach is a logical way to conceptualize how GRC works:
 Plan. The overall process beings with planning. At its core, this phase is the process of conducting due diligence. The
results of this process will define necessary controls (e.g., requirements) that influence the need for policies, standards
and procedures. These actions directly influence resourcing and procurement actions that range from staffing needs to
tool purchases and services acquisition.
 Do. This phase is the process of conducting due care, where it is focused on the “reasonable care” necessary to properly
and sufficiently conduct operations that demonstrate the absence of negligence. This is the execution of procedures –
the processes that bring controls to life.
 Check This phase can be considered maintaining situational awareness. There are several ways to maintain situation
awareness and that ranges from control validation testing to audits/assessments and metrics.
 Act- This phase again brings up the concept of “reasonable care” that necessitates taking action to maintain the
organization’s targeted risk tolerance threshold. This deals with addressing two main concepts (1) real deficiencies that
currently exist and (2) areas of concern that may expose the organization to a threat if no action is taken.

The premise is that controls are central to cybersecurity & data privacy operations as well as the business rhythms of the
organization. Without properly defining MCR and DSR thresholds, an organization’s overall cybersecurity & data privacy program
is placed in jeopardy as the baseline practices are not anchored to clear requirements. Furthermore, understanding and clarifying
the difference between "compliant" versus "secure" (e.g., MCR vs. MCR+DSR) enhances risk management discussions.

CHICKEN VS EGG DEBATE: THE LOGICAL ORDER OF GRC FUNCTIONS

Which comes first? Governance, Risk or Compliance? This has been a hotly-debated topic since GRC was first coined nearly 20
years ago.14 There is a logical order to GRC processes that must be understood to avoid siloes and an improperly scoped security
program. First, it is necessary to level-set on the terminology of what GRC functions do:
 Governance. Structures the organization’s controls to align with business goals and applicable statutory, regulatory,
contractual and other obligations. Develops necessary policies and standards to ensure the proper implementation of
controls.
 Risk Management. Identifies, quantifies and manages risk to information and technology assets, based on the
organization’s operating model.
 Compliance. Oversight of control implementation to ensure the organization’s applicable statutory, regulatory,
contractual and other obligations are adequately met. Conducts control validation testing and audits/assessments.

When establishing GRC practices, what is described below is the precedence of how (1) compliance influences (2) governance,
which influences (3) risk management. This addresses the "GRC chicken vs egg" debate:

COMPLIANCE
The genesis of GRC is to first identify applicable statutory, regulatory and contractual obligations that the organization must
adhere to, as well as internal business requirements (e.g., Board of Director directives). This is a compliance function that
identifies statutory, regulatory and contractual obligations. It is a due diligence exercise to identify what the organization is
reasonably required to comply with from a cybersecurity & data privacy perspective. This process involves interfacing with various
Lines of Business (LOB) to understand how the organization operates, including geographic considerations. Generally,
Compliance needs to work with the legal department, contracts management, physical security and other teams to gain a
comprehensive understanding of the organizational compliance needs.

Compliance is the “source of truth” for statutory, regulatory and contractual obligations. With that knowledge, Compliance
informs Governance about the controls that apply to applicable laws, regulations and frameworks. This knowledge is needed so
that Governance can determine the appropriate policies and standards that must exist. Compliance may identify requirements
to adhere to a specific industry framework (e.g., NIST CSF, ISO 27002, NIST 800-53, etc.), but organizations are usually able to
pick the framework that best fits their needs on their own. This is often where various compliance obligations exceed what a single
framework can address, so the organization must leverage some form of metaframework (e.g., framework of frameworks).

14 OCEG – What is GRC - https://www.oceg.org/ideas/what-is-grc/

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 18 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
Compliance defines the controls necessary to meet the organization’s specific needs (e.g., MCR + DSR) and publishes one or
more control sets (e.g., specific to a project/contract/law/regulation or organization-wide controls). The control set(s) can be
considered an organization's Minimum Security Requirements (MSR) that will be used:
 By the Governance team to develop appropriate policies, standards and other information (e.g., program-level
guidance, Concept of Operations (CONOPS) documents, etc.; and
 By the Risk Management team to assess risk.

Given that not all controls are weighted equally, it is vitally important that personnel who represent the Risk Management function
are involved in developing an assigned weight for each control (e.g., the presence of a fully-patched border firewall should be
considered a more important control than end user awareness posters). This weighting of cybersecurity & data privacy controls is
necessary to ensure the results of risk assessments accurate support the intent of the organization's risk tolerance threshold.
That threshold is meant to establish a benchmark for defining acceptable and unacceptable risk.

GOVERNANCE
Based on these controls, Governance has two (2) key functions:
1. Develop policies and standards to meet those compliance obligations (defined by applicable control objectives); and
2. Assign ownership of those controls to the applicable stakeholders involved in the affected business processes. This
process often requires a documented Responsibility, Accountability, Supportive, Consulted and Informed (RASCI) chart
to ensure the organizational model supports effective implementation and oversight of the assigned controls.

Personnel representing the Governance function must work directly with the stakeholders (e.g., control owners and control
operators) who are directly responsible for implementing and operating their assigned cybersecurity & data privacy controls.
Those stakeholders are expected to develop and operate Standardized Operating Procedures (SOP) to ensure control
implementation is performed according to the company’s performance requirements, as established in the organization’s
cybersecurity & data privacy standards. The operation of those SOPs generates evidence of due care that reasonable practices
are in place and operating accordingly. Generating deliverables is an expected output from executing procedures.

The development and implementation of the policies and standards is evidence of due diligence that the organization's
compliance obligations are designed to address applicable administrative, technical and physical security controls. It is
important to ensure that policies and standards document what the organization is doing, as the policies and standards are often
the mechanisms by which outside regulators measure implementation and maturity of the control. Organizational governance
can be a vital element in the organization’s ability to implement, sustain and defend their compliance program.

Cybersecurity & data privacy documentation is generally comprised of six (6) main parts:
1. Policies establish management’s intent;
2. Control Objectives identifies leading practices;
3. Standards provide quantifiable requirements;
4. Controls identify desired conditions that are expected to be met;
5. Procedures / Control Activities establish how tasks are performed to meet the requirements established in standards and
to meet controls; and
6. Guidelines are recommended, but not mandatory.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 19 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
RISK MANAGEMENT
From a trickle-down perspective, while Risk Management logically follows both Compliance and Governance functions in
establishing a GRC program, Risk Management is crucial for the organization to maintain situational awareness and remain both
secure and compliant. Risk Management serves as the primary "canary in the coal mine" to identify instances of non-compliance
that lead to the improper management of risks and exposure of the organization to threats; since ongoing risk assessments
generally occur more frequently than internal/external audits that Compliance may oversee.

Risk Management activities addresses both due diligence and due care obligations to identify, assess and remediate control
deficiencies:
 Risk Management must align with Governance practices for exception management (e.g., compensating controls).
 Compliance must evaluate findings from risk assessments and audits/assessments (both internal and external) to
determine if adjustments to the organization’s cybersecurity & data privacy controls (e.g., MCR + DSR) are necessary,
based on business process changes, technology advancements and/or an evolution of the organization's risk threshold.

While Risk Management personnel do not perform the actual remediation actions (that is the responsibility of the control owner),
Risk Management assists in determining the appropriate risk treatment options:
 Reduce the risk to an acceptable level;
 Avoid the risk;
 Transfer the risk to another party; or
 Accept the risk.

One key consideration for GRC, especially Risk Management, is that the appropriate level of organizational management makes
the risk management decision. Therefore, risks need to be ranked, so that the appropriate levels of management can be
designated as "approved authorities" to make a risk treatment determination. For example, a project manager should not be able
to accept a "high risk" that should be made by a VP or some other executive. By formally assigning risk to individuals and requiring
those in managerial roles to own their risk management decisions, it can help the organization maintain its target risk threshold.

GRC INTEGRATIONS
The processes described above can be visualized in the following diagram which shows the interrelated nature of governance,
risk management and compliance functions to build and maintain an organization’s cybersecurity & data privacy program.

[graphic download - https://securecontrolsframework.com/content/GRC-Fundamentals.pdf]

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 20 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 5. UNDERSTANDING WHAT IT MEANS TO ADOPT “SECURE BY DESIGN” PRINCIPLES
For an organization claims it “just does ISO 27002” it is easy to say, “We’re an ISO shop and we exclusively use ISO 27002
cybersecurity principles” and that would be routinely accepted as being adequate. However, what about companies that have
complex cybersecurity and compliance needs, such as a company that must address SOC2, ISO 27002, CCPA, EU GDPR, PCI
DSS and NY DFS? In these complex cases that involve multiple frameworks, the reality is that ISO 27002 controls alone do not
provide appropriate coverage. This is why it is important to understand what secure principles your organization is aligned with,
so that the controls it implements are appropriate to build secure and compliant processes. What works for one company or
industry does not necessarily work for another, since requirements are unique to the organization.

Most companies have requirements to document cybersecurity & data protection processes but lack the knowledge and
experience to undertake such documentation efforts. That means organizations are faced with either outsourcing the work to
expensive consultants or they ignore the requirement and hope they do not get in trouble for being non-compliant. In either
situation, it is not a good place to be.

SECURE PRACTICES ARE COMMON EXPECTATIONS

While the European Union General Data Protection Regulation (EU GDPR) made headlines for requiring organizations to
demonstrate cybersecurity & data privacy principles are by both “by default and by design,” Secure Engineering & Data Privacy
(SEDP) principles are not just limited to EU GDPR. SEDP principles are actually common requirements in the constantly-evolving
statutory and regulatory landscapes. The following are common statutory, regulatory and contractual requirements that expect
SEDP practices:
 AICPA Trust Services Principles (ESP) (e.g., System and Organization Controls (SOC) 2 Type 1) – CC2.2, CC3.2, CC5.1 &
CC5.2
 Cloud Computing Compliance Controls Catalogue (C5) – KOS-01 & KOS-07
 Criminal Justice Information Services (CJIS) Security Policy – 5.10.1.1 & 5.10.1.5
 COBIT 2019 – DSS06.06
 COSO 2017 – Principles 10 & 11
 European Union Agency for Network and Information Security (ENISA) Technical Guideline of Security Measures – SO12
 European Union General Data Protection Regulation (EU GDPR) – Art 5.2, 24.1, 24.2, 24.3, 25.1, 25.2, 25.3, 32.1, 32.2 &
40.2
 Federal Risk and Authorization Management Program (FedRAMP) – SA-8, SC-7(18) & SI-01
 Food & Drug Administration (FDA) 21 CFR Part 11 – §11.30
 Federal Trade Commission (FTC) Act - §45(a) & §45b(d)(1)
 Generally Accepted Privacy Principles (GAPP) – 4.2.3, 6.2.2, 7.2.2 & 7.2.3
 Health Insurance Portability and Accountability Act (HIPAA) - 164.306, 164.308, 164.312, 164.314 & 164.530
 ISO 27002:2013 – 8.3.2
 ISO 27018 – A.10.1, A.10.4, A.10.5 & A.10.6
 ISO 29100 – 5.10 & 5.11
 National Industry Security Program Operating Manual (NISPOM) – 8-101, 8-302 & 8-311
 NIST SP 800-53 – PT-1, SA-8, SA-13, SC-7(18) & SI-1
 NIST SP 800-171 – 3.13.1, 3.13.3 & Non-Federal Organization (NFO)
 NIST Cybersecurity Framework – PR.IP-1
 Payment Card Industry Data Security Standard (PCI DSS) – 1.2, 1.3, 1.4, 1.5, 2.2, 6.5 & 12.5

COMPLIANCE SHOULD BE VIEWED AS A NATURAL BYPRODUCT OF SECURE PRACTICES

It is vitally important for any SCF user to understand that “compliant” does not mean “secure.” However, if you design, build and
maintain secure systems, applications and processes, then compliance will often be a natural byproduct of those secure
practices.

The SCF’s comprehensive listing of over 1,200 cybersecurity & data protection controls is categorized into thirty-three (33)
domains that are mapped to over 200 authoritative sources (e.g., statutory, regulatory and contractual frameworks). Those
applicable SCF controls can operationalize the cybersecurity & data privacy principles to help an organization ensure that secure
practices are implemented by design and by default.

You may be asking yourself, “What cybersecurity & data privacy principles should I be using?” and that is a great question. The
SCF helped with this common question by taking the thirty-three (33) domains of the SCF and creating principles that an
organization can use. The idea is that by focusing on these secure principles, an organization will design, implement and maintain
secure systems, applications and processes that will by default help the organization comply with its compliance obligations.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 21 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
CYBERSECURITY & DATA PRIVACY BY DESIGN (C|P) PRINCIPLES
The concept of building cybersecurity & data privacy into technology solutions both by
default and by design is a basic expectation for businesses, regardless of the industry. The
adoption of cybersecurity & data privacy principles is a crucial step in building a secure,
audit-ready program.

The C|P is a set of thirty-three (33) cybersecurity & data privacy principles that leverage the
SCF's extensive cybersecurity & data privacy control set. You can download the free poster
at https://securecontrolsframework.com/domains-principles/.

The “C pipe P” logo is a nod to the computing definition of the | or “pipe” symbol (e.g., shift + backslash), which is a computer
command line mechanism that allows the output of one process to be used as input to another process. In this way, a series of
commands can be linked to more quickly and easily perform complex, multi-stage processing. Essentially, the concept is that
security principles are being “piped” with privacy principles to create secure processes in an efficient manner.

STEPS TO OPERATIONALIZE THE C|P PRINCIPLES

1. Read through the C|P principles to familiarize yourself with the thirty-three (33) domains to understand how they come
together to address the cybersecurity, privacy and physical security considerations for a modern security program.
2. Identify the applicable SCF controls that your organization needs to implement to address its applicable statutory,
regulatory and contractual compliance needs.
3. Implement and monitor those SCF controls to ensure the C|P principles are being met by your day-to-day practices.

The C|P establishes thirty-three (33) common-sense principles to guide the development and oversight of a modern cybersecurity
& data privacy program. Those thirty-three (33) C|P principles are listed below:

SCF DOMAINS & C|P PRINCIPLES

SCF Cybersecurity & Data Privacy by
# SCF Domain Principle Intent
Identifier Design (C|P) Principles
Execute a documented, risk-based Organizations specify the development
program that supports business of an organization's cybersecurity &
objectives while encompassing data protection program, including
Cybersecurity & Data
1 GOV appropriate cybersecurity & data criteria to measure success, to ensure
Privacy Governance
protection principles that addresses ongoing leadership engagement and
applicable statutory, regulatory and risk management.
contractual obligations.
Ensure trustworthy and resilient Organizations ensure Artificial
Artificial Intelligence (AI) and Intelligence (AI) and autonomous
autonomous technologies to achieve a technologies are designed to be
beneficial impact by informing, advising reliable, safe, fair, secure, resilient,
Artificial and
or simplifying tasks, while minimizing transparent, explainable and data
2 Autonomous AAT
emergent properties or unintended privacy-enhanced. In addition, AI-
Technology
consequences. related risks are governed according to
technology-specific considerations to
minimize emergent properties or
unintended consequences.
Manage all technology assets from Organizations ensure technology
purchase through disposition, both assets are properly managed
physical and virtual, to ensure secured throughout the lifecycle of the asset,
use, regardless of the asset’s location. from procurement through disposal,
3 Asset Management AST ensuring only authorized devices are
allowed to access the organization's
network and to protect the
organization's data that is stored,
processed or transmitted on its assets.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 22 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 Maintain a resilient capability to sustain Organizations establish processes that
business-critical functions while will help the organization recover from
Business Continuity &
4 BCD successfully responding to and adverse situations with minimal impact
Disaster Recovery
recovering from incidents through well- to operations, as well as provide the
documented and exercised processes. capability for e-discovery.
Govern the current and future Organizations prevent avoidable
capacities and performance of business interruptions caused by
technology assets. capacity and performance limitations
Capacity & by proactively planning for growth and
5 CAP
Performance Planning forecasting, as well as requiring both
technology and business leadership to
maintain situational awareness of
current and future performance.
Manage change in a sustainable and Organizations ensure both technology
ongoing manner that involves active and business leadership proactively
participation from both technology and manage change, including the
business stakeholders to ensure that assessment, authorization and
6 Change Management CHG
only authorized changes occur. monitoring of technical changes across
the enterprise so as to not impact
production systems uptime and allow
easier troubleshooting of issues.
Govern cloud instances as an extension Organizations govern the use of private
of on-premise technologies with equal and public cloud environments (e.g.,
or greater security protections than the IaaS, PaaS and SaaS) to holistically
organization's own internal manage risks associated with third-
7 Cloud Security CLD
cybersecurity & data privacy controls. party involvement and architectural
decisions, as well as to ensure the
portability of data to change cloud
providers, if needed.
Oversee the execution of cybersecurity Organizations ensure controls are in
& data privacy controls to ensure place to ensure adherence to
appropriate evidence required due care applicable statutory, regulatory and
8 Compliance CPL
and due diligence exists to meet contractual compliance obligations, as
compliance with applicable statutory, well as internal company standards.
regulatory and contractual obligations.
Enforce secure configurations Organizations establish and maintain
according to vendor-recommended and the integrity of systems. Without
industry-recognized secure practices properly documented and implemented
that enforce the concepts of “least configuration management controls,
Configuration
9 CFG privilege” and “least functionality” for security features can be inadvertently
Management
all systems, applications and services. or deliberately omitted or rendered
inoperable, allowing processing
irregularities to occur or the execution
of malicious code.
Maintain situational awareness of Organizations establish and maintain
security-related events through the ongoing situational awareness across
centralized collection and analysis of the enterprise through the centralized
event logs from systems, applications collection and review of security-
and services. related event logs. Without
comprehensive visibility into
Continuous
10 MON infrastructure, operating system,
Monitoring
database, application and other logs,
the organization will have “blind spots”
in its situational awareness that could
lead to system compromise, data
exfiltration, or unavailability of needed
computing resources.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 23 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 Utilize appropriate cryptographic Organizations ensure the confidentiality
solutions and industry-recognized key and integrity of its data through
Cryptographic management practices to protect the implementing appropriate
11 CRY
Protections confidentiality and integrity of cryptographic technologies to protect
sensitive/regulated data both at rest systems, applications, services and
and in transit. data.
Enforce a standardized data Organizations ensure that technology
classification methodology to assets, both electronic and physical,
objectively determine the sensitivity are properly classified and measures
and criticality of all data and technology implemented to protect the
assets so that proper handling and organization's data from unauthorized
disposal requirements can be followed. disclosure, or modification, regardless
Data Classification &
12 DCH if it is being transmitted or stored.
Handling
Applicable statutory, regulatory and
contractual compliance requirements
dictate the minimum safeguards that
must be in place to protect the
confidentiality, integrity and availability
of data.
Provide additional scrutiny to reduce Organizations specify the development,
the risks associated with embedded proactive management and ongoing
technology, based on the potential review of security embedded
damages posed from malicious use of technologies, including hardening of
Embedded
13 EMB the technology. the “stack” from the hardware,
Technology
firmware and software to transmission
and service protocols used for Internet
of Things (IoT) and Operational
Technology (OT) devices.
Harden endpoint devices to protect Organizations ensure that endpoint
against reasonable threats to those devices are appropriately protected
devices and the data those devices from security threats to the device and
store, transmit and process. its data. Applicable statutory,
14 Endpoint Security END regulatory and contractual compliance
requirements dictate the minimum
safeguards that must be in place to
protect the confidentiality, integrity,
availability and safety considerations.
Execute sound hiring practices and Organizations create a cybersecurity &
ongoing personnel management to data privacy-minded workforce and an
Human Resources
15 HRS cultivate a cybersecurity & data privacy- environment that is conducive to
Security
minded workforce. innovation, considering issues such as
culture, reward and collaboration.
Enforce the concept of “least privilege” Organizations implement the concept
consistently across all systems, of “least privilege” through limiting
applications and services for individual, access to the organization's systems
Identification &
16 IAC group and service accounts through a and data to authorized users only.
Authentication
documented and standardized Identity
and Access Management (IAM)
capability.
Maintain a viable incident response Organizations establish and maintain a
capability that trains personnel on how viable and tested capability to respond
to recognize and report suspicious to cybersecurity or data privacy-related
activities so that trained incident incidents in a timely manner, where
17 Incident Response IRO
responders can take the appropriate organizational personnel understand
steps to handle incidents, in how to detect and report potential
accordance with a documented incidents.
Incident Response Plan (IRP).

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 24 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 Execute an impartial assessment Organizations ensure the adequacy of
process to validate the existence and cybersecurity & data privacy controls in
functionality of appropriate development, testing and production
Information
18 IAO cybersecurity & data privacy controls, environments.
Assurance
prior to a system, application or service
being used in a production
environment.
Proactively maintain technology assets, Organizations ensure that technology
according to current vendor assets are properly maintained to
recommendations for configurations ensure continued performance and
19 Maintenance MNT
and updates, including those supported effectiveness. Maintenance processes
or hosted by third-parties. apply additional scrutiny to the security
of end-of-life or unsupported assets.
Implement measures to restrict mobile Organizations govern risks associated
device connectivity with critical with mobile devices, regardless of
infrastructure and sensitive/regulated ownership (organization-owned,
Mobile Device data that limit the attack surface and employee-owned or third-party owned).
20 MDM
Management potential data exposure from mobile Wherever possible, technologies are
device usage. employed to centrally manage mobile
device access and data storage
practices.
Architect and implement a secure and Organizations ensure sufficient
resilient defense-in-depth methodology cybersecurity & data privacy controls
that enforces the concept of “least are architected to protect the
functionality” through restricting confidentiality, integrity, availability and
21 Network Security NET
network access to systems, safety of the organization's network
applications and services. infrastructure, as well as to provide
situational awareness of activity on the
organization's networks.
Protect physical environments through Organizations minimize physical
layers of physical security and access to the organization's systems
environmental controls that work and data by addressing applicable
Physical &
together to protect both physical and physical security controls and ensuring
22 Environmental PES
digital assets from theft and damage. that appropriate environmental
Security
controls are in place and continuously
monitored to ensure equipment does
not fail due to environmental threats.
Align data privacy practices with Organizations align data privacy
industry-recognized data privacy engineering decisions with the
principles to implement appropriate organization's overall data privacy
administrative, technical and physical strategy and industry-recognized
23 Data Privacy PRI
controls to protect regulated personal leading practices to secure Personal
data throughout the lifecycle of Data (PD) that implements the concept
systems, applications and services. of data privacy by design and by
default.
Operationalize a viable strategy to Organizations ensure that security-
achieve cybersecurity & data privacy related projects have both resource and
objectives that establishes project/program management support
Project & Resource
24 PRM cybersecurity as a key stakeholder to ensure successful project execution.
Management
within project management practices to
ensure the delivery of resilient and
secure solutions.
Proactively identify, assess, prioritize Organizations ensure that the business
and remediate risk through alignment unit(s) that own the assets and / or
25 Risk Management RSK with industry-recognized risk processes involved are made aware of
management principles to ensure risk and understand all applicable
cybersecurity & data privacy-related

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 25 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 decisions adhere to the organization's risks. The cybersecurity & data privacy
risk threshold. teams advise and educate on risk
management matters, while it is the
business units and other key
stakeholders that ultimately own the
risk.
Utilize industry-recognized secure Organizations align cybersecurity
engineering and architecture principles engineering and architecture decisions
Secure Engineering & to deliver secure and resilient systems, with the organization's overall
26 SEA
Architecture applications and services. technology architectural strategy and
industry-recognized leading practices
to secure networked environments.
Execute the delivery of cybersecurity & Organizations ensure appropriate
data privacy operations to provide resources and a management structure
27 Security Operations OPS quality services and secure systems, exists to enable the service delivery of
applications and services that meet the cybersecurity, physical security and
organization's business needs. data privacy operations.
Foster a cybersecurity & data privacy- Organizations develop a cybersecurity
minded workforce through ongoing user & data privacy-minded workforce
Security Awareness &
28 SAT education about evolving threats, through continuous education activities
Training
compliance obligations and secure and practical exercises.
workplace practices.
Develop and/or acquire systems, Organizations ensure that cybersecurity
applications and services according to & data privacy principles are
Technology a Secure Software Development implemented into any
29 Development & TDA Framework (SSDF) to reduce the products/solutions, either developed
Acquisition potential impact of undetected or internally or acquired, to make sure that
unaddressed vulnerabilities and design the concepts of “least privilege” and
flaws. “least functionality” are incorporated.
Execute Supply Chain Risk Organizations ensure that cybersecurity
Management (SCRM) practices so that & data privacy risks associated with
Third-Party only trustworthy third-parties are used third-parties are minimized and enable
30 TPM
Management for products and/or service delivery. measures to sustain operations should
a third-party become compromised,
untrustworthy or defunct.
Proactively identify and assess Organizations establish a capability to
technology-related threats, to both proactively identify and manage
assets and business processes, to technology-related threats to the
31 Threat Management THR
determine the applicable risk and cybersecurity & data privacy of the
necessary corrective action. organization's systems, data and
business processes.
Leverage industry-recognized Attack Organizations proactively manage the
Surface Management (ASM) practices risks associated with technical
Vulnerability & Patch to strengthen the security and vulnerability management that includes
32 VPM
Management resilience systems, applications and ensuring good patch and change
services against evolving and management practices are utilized.
sophisticated attack vectors.
Ensure the security and resilience of Organizations address the risks
Internet-facing technologies through associated with Internet-accessible
secure configuration management technologies by hardening devices,
33 Web Security WEB
practices and monitoring for monitoring system file integrity,
anomalous activity. enabling auditing, and monitoring for
malicious activities.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 26 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 6. UNDERSTANDING WHAT IT MEANS TO ADOPT “PRIVACY BY DESIGN” PRINCIPLES
Through our interactions with organizations, we identified that many organizations understand the cybersecurity framework they
wanted or needed to align with, but had no understanding of the privacy principles their organization should be aligned with. We
set out to fix that issue and what we did was select over a dozen of the most common privacy frameworks to create a "best in
class" approach to managing privacy principles. The best part is these are all mapped to the SCF and are built into the SCF, so you
can leverage the SCF for both your cybersecurity & data privacy needs!

Why should you care? When you tie the broader C|P in with the SCF Data Privacy Management Principles (DPMP), you have an
excellent foundation for building and maintaining secure systems, applications and services that address cybersecurity & data
privacy considerations by default and by design. The DPMP is included in the SCF download as a separate tab in the Excel
spreadsheet. 15

Think of the SCF Privacy Management Principles as a supplement to the C|P to assist in defining and managing privacy principles,
based on selected privacy frameworks. This can enable your organization to align with multiple privacy frameworks that also map
to your cybersecurity & data privacy control set, since we found the “apples to oranges” comparison between disparate privacy
frameworks was difficult for most non-privacy practitioners to comprehend.

SCF DATA PRIVACY MANAGEMENT PRINCIPLES (DPMP)

For organizations, we found the “apples to oranges” comparison between disparate privacy frameworks was difficult for most
non-privacy lawyers to understand. What this project did was identify a dozen of the leading privacy frameworks and create a set
of simplified, yet comprehensive, privacy management principles. Below are the seventeen (17) different frameworks the SCF
Data Privacy Management Principles are mapped to:
1. AICPA’s Trust Services Criteria (TSC) SOC 2 (2017);
2. Asia-Pacific Economic Cooperation (APEC);
3. California Privacy Rights Act (CPRA);
4. European Union General Data Protection Regulation (EU GDPR);
5. Fair Information Practice Principles (FIPPs) - Department of Homeland Security (DHS);
6. Fair Information Practice Principles (FIPPs) - Office of Management and Budget (OMB);
7. Generally Accepted Privacy Principles (GAPP);
8. HIPAA Privacy Rule;
9. ISO 27701;
10. ISO 29100;
11. Nevada SB820;

15 SCF DPMP - https://securecontrolsframework.com/data-privacy-management-principles/

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 27 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 12. NIST SP 800-53 R4;
13. NIST SP 800-53 R5;
14. NIST Privacy Framework v1.0;
15. Organization for Economic Co-operation and Development (OECD);
16. Office of Management and Budget (OMB) - Circular A-130; and
17. Personal Information Protection and Electronic Documents Act (PIPEDA).

We took these frameworks and looked for similarities and gaps. If you download the SCF Data Privacy Management Principles,
you will see the direct mappings to these leading privacy frameworks. Given this, you now know the origin of the principle we
include in our document. This is a great tool for organizations that may have to address multiple requirements because it brings a
common language to simply things.

The eighty-six (86) principles of the SCF Data Privacy Management Principles are organized into eleven (11) domains:
1. Privacy by Design;
2. Data Subject Participation;
3. Limited Collection & Use;
4. Transparency;
5. Data Lifecycle Management;
6. Data Subject Rights;
7. Security by Design;
8. Incident Response;
9. Risk Management;
10. Third-Party Management; and
11. Business Environment.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 28 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 7. INTEGRATED CONTROLS MANAGEMENT (ICM)
The premise of Integrated Controls Management (ICM) is that controls are central to cybersecurity & data privacy operations, as
well as the overall business rhythm of an organization. This premise of the ICM is supported by the Cybersecurity & Data Privacy
Risk Management Model (C|P-RMM), 16 that describes the central nature of controls, where not just policies and standards map to
controls, but procedures, metrics, threats and risks, as well.

ICM is defined as, “a holistic, technology-agnostic approach to cybersecurity & data privacy controls to identify, implement and
manage secure and compliant practices, covering an organization’s people, processes, technology and data, regardless of how
or where data is stored, processed and/or transmitted.”

ICM takes a different approach from the traditional definition of Governance, Risk
Management and Compliance (GRC) and/or Integrated Risk Management (IRM),
since ICM is controls-centric, where controls are viewed as the nexus, or central
pivoting point, for an organization’s cybersecurity & data privacy operations.

ICM is designed to proactively address the strategic, operational and tactical nature
of operating an organization’s cybersecurity & data privacy program at the control
level. ICM is designed to address both internal controls, as well as the broader
concept of Supply Chain Risk Management (SCRM).

OCEG defines GRC as, “GRC is the integrated collection of capabilities that enable an organization to reliably achieve objectives,
address uncertainty and act with integrity,” while Gartner jointly defines GRC/IRM as, "a set of practices and processes supported
by a risk-aware culture and enabling technologies, that improves decision making and performance through an integrated view of
how well an organization manages its unique set of risks."

Secure and compliant operations exist when applicable controls are properly scoped and implemented. ICM specifically focuses
on the need to understand and clarify the difference between "compliant" versus "secure" since that is necessary to have coherent
risk management discussions. To assist in this process, an organization’s applicable controls are categorized according to “must
have” vs “nice to have” requirements:
 Minimum Compliance Requirements (MCR) are the absolute minimum requirements that must be addressed to comply
with applicable laws, regulations and contracts. MCR are primarily externally-influenced, based on industry, government,
state and local regulations. MCR should never imply adequacy for secure practices and data protection, since they are
merely compliance-related.
 Discretionary Security Requirements (DSR) are tied to the organization’s risk appetite since DSR are “above and beyond”
MCR, where the organization self-identifies additional cybersecurity & data privacy controls to address voluntary industry
practices or internal requirements, such as findings from internal audits or risk assessments. DSR are primarily internally-
influenced, based on the organization’s respective industry and risk tolerance. While MCR establishes the foundational
floor that must be adhered to, DSR are where organizations often achieve improved efficiency, automation and enhanced
security.

IT GENERAL CONTROLS (ITGC)

The combination of MCR and DSR equate to an organization’s Minimum Security Requirements (MSR), which define the “must
have” and “nice to have” requirements for PPTDF in one control set. It defines the Minimum Viable Product (MVP) technical and
business requirements from a cybersecurity & data privacy perspective. In short, the MSR can be considered to be an
organization’s IT General Controls (ITGC), which establish the basic controls that must be applied to systems, applications,
services, processes and data throughout the enterprise. ITGC provide the foundation of assurance for an organization’s decision
makers. ITGC enables an organization’s governance function to define how technologies are designed, implemented and
operated.

SECURITY VS COMPLIANCE
For those on the receiving end of cybersecurity efforts, the terms “security” and “compliance” might seem synonymous. However,
understanding the subtle, yet crucial, differences between being compliant and being secure is paramount in safeguarding an
organization’s technologies and sensitive/regulated data.

16 SCF C|P-RMM - https://securecontrolsframework.com/risk-management-model/

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 29 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
There is a long-running debate pertaining to “compliance is not security” and there is some truth to that saying. However, instead
of a binary state of being singularly compliant or secure, it should be viewed as four (4) maturity-based quadrants where your
organization is either:
1. Not secure, resilient or compliant (negligent);
2. Secure & resilient, but not compliant;
3. Compliant, but not secure or resilient; or
4. Secure, resilient & compliant.

The underlying issue in the “compliance vs security” debate is complacency and this is important for the broader concept of ICM.
Your adversaries are unrelenting, so why would you consciously choose to settle? That is where the concept of negligence comes
into play, when your failure to conduct due diligence and due care activities can be considered negligent behavior. That term tends
to scare executives, and it should, but it does not change the reality that there is a negligence threshold that is specific to each
organization. The question for you is, “Do you know what your negligence threshold is, based on your applicable laws, regulations
and contractual obligations?”

This concept of identifying a negligence threshold is addressed in the SCF’s Cybersecurity & Data Privacy Capability Maturity
Model (C|P-CMM).17

DEFINING COMPLIANCE THAT IS SPECIFIC TO YOUR BUSINESS CASE

Compliance controls are viewed as “must have” requirements that are non-discretionary (e.g., not optional). These requirements
directly sourced from an organization’s applicable laws, regulations and contractual obligations. The process of clearly identifying
non-discretionary controls generally involves interviewing multiple stakeholders to gain appropriate situational awareness of all
pertinent compliance obligations. These stakeholders with valuable insights are often:
 Procurement / Contracts Management;
 Enterprise Risk Management (ERM);
 Legal;

17 SCF C|P-CMM - https://securecontrolsframework.com/capability-maturity-model/

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 30 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
  Physical Security; and
 Human Resources.

EXPERT INSIGHT (SCOPING): From a scoping perspective, compliance obligations may be organization-wide or narrowly scoped
to a specific enclave or project. It is solely your organization's responsibility to properly scope the applicability of its applicable
compliance controls. The Unified Scoping Guide (USG) is an excellent resource for your scoping exercise.18

DEFINING WHAT IT TAKES FOR YOUR BUSINESS PROCESSES TO BE SECURE & RESILIENT
Cybersecurity and data protection controls that are not required by a law, regulation or contractual obligation are “nice to have”
controls that are discretionary for an organization to implement. Any aspect of non-compliance with a discretionary control would
be isolated within the realm of the stakeholder making the requirement, since the requirement is internal to your organization. The
source of these discretionary requirements may be from:
 Board of Director (BoD) guidance;
 Steering Committee recommendations;
 Internal Audit findings;
 Third-party audit/assessment recommendations; and/or
 Internal staff preferences.

The importance of these discretionary controls is that those are often organization-specific considerations to mitigate risk that is
specific to an organization’s business practices.

DISCRETIONARY CYBERSECURITY & DATA PROTECTION CONSIDERATIONS

A common frustration amongst cybersecurity practitioners is about the gaps that exist in many “best practice” cybersecurity
frameworks. This is often where there are complaints about organizations holding an ISO 27001 certification, SOC 2 audit or PCI
DSS audit that still have breaches or security incidents, where the argument is that a certification does not mean the organization
is secure. The remedy to such gaps is through discretionary cybersecurity & data protection controls that are not directly
mandated by a compliance obligation, such as the requirements for:
 Data Loss Prevention (DLP);
 Network Access Control (NAC);
 File Integrity Monitoring (FIM);
 24/7 Security Operations Center (SOC);
 Artificial Intelligence (AI) governance controls;
 Sandboxing / detonation chambers;
 Segmented Dev / Test / Production environments;
 Cloud infrastructure-specific controls; and/or
 Embedded technology-specific controls.

DISCRETIONARY RESILIENCE CONSIDERATIONS

NIST defines resilience as, “The ability to prepare for and adapt to changing conditions and withstand and recover rapidly from
disruption. Resilience includes the ability to withstand and recover from deliberate attacks, accidents, or naturally occurring
threats or incidents.”19 From a discretionary control perspective, this may require the addition of technologies and processes to
help ensure the continuity of business operations, such as:
 Continuity of Operations Plan (COOP);
 Business Continuity / Disaster Recovery (BC/DR) Plan;
 Failover / redundancy capabilities;
 Business continuity test exercises;
 Offsite, online backup storage;
 Offsite, offline backup storage; and/or
 Transactional-level backups.

18 Unified Scoping Guide - https://complianceforge.com/content/pdf/unified-scoping-guide-usg.pdf

19 NIST Glossary - https://csrc.nist.gov/glossary/term/resilience#

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 31 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
DEFINING NEGLIGENCE AS IT PERTAINS TO CYBERSECURITY & DATA PRIVACY
The following content is leveraged from Cornell’s Law School Legal Information Institute (LII)20 to help provide some additional
context to the previous points previously explained.

Negligent conduct may consist of either an act, or an omission to act when there is a duty to do so. Primary factors to consider
in ascertaining whether the person's conduct lacks reasonable care are:
 The foreseeable likelihood that the person's conduct will result in harm;
 The foreseeable severity of any harm that may ensue; and
 The burden of precautions to eliminate or reduce the risk of harm.

Four (4) elements are generally required to establish a prima facie case of negligence:
1. Existence of a legal duty that the defendant owed to the plaintiff (e.g., complying with NIST SP 800-171 to protect
Controlled Unclassified Information (CUI));
2. Defendant's breach of that duty (e.g., failure to protect CUI in accordance with NIST SP 800-171 requirements under
applicable DFARS clauses);
3. Plaintiff's sufferance of an injury (e.g., financial losses due to lost contract due to non-compliance with NIST SP 800-171);
and
4. Proof that defendant's breach caused the injury (e.g., publicity about the data breach or other evidence pointing to
the entity being the source of the data breach)

Typically, to meet the injury element of the prima facie case, the injury must be one (1) of two (2) things:
1. Bodily harm; or
2. Harm to property (can be personal property or business property (physical or digital)).

DETERMINING A BREACH OF DUTY

When determining how whether the defendant has breached a duty, courts will usually use the Learned Hand formula 21, which is
an algebraic approach to determining liability. If B < PL, then there will be negligence liability for the party with the burden of taking
precautions where:
 B = Burden of taking precautions
 P = Probability of loss
 L = Gravity of loss

If the burden of taking such precautions is less than the probability of injury multiplied by the gravity of any resulting injury, then
the party with the burden of taking precautions will have some amount of liability.

DETERMINING WHETHER THERE WAS A DUTY TO ACT

Typically, if the defendant had a duty to act, did not act (resulting in a breach of duty) and that breach of duty caused an injury, then
the defendant's actions will be classified as misfeasance. There are several ways to determine whether the defendant had a duty to
act (this is not an exhaustive list):
 The defendant engaged in the creation of the risk which resulted in the plaintiff's harm;
 The defendant volunteered to protect the plaintiff from harm;
 The defendant knew / should have known that the conduct will harm the plaintiff; or
 Business/voluntary relationships.

ICM PRINCIPLES
There are eight (8) principles associated with ICM:
1. Establish Context;
2. Define Applicable Controls;
3. Assign Maturity-Based Criteria;
4. Publish Policies, Standards & Procedures;
5. Assign Stakeholder Accountability;
6. Maintain Situational Awareness;
7. Manage Risk; and
8. Evolve Processes.

20 Cornell’s Law School - https://www.law.cornell.edu/wex/negligence

21 Learned Hand Formula - https://academic.oup.com/lpr/article/5/1/1/990799

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 32 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 Integrated Controls Management (ICM) – Overlaid Onto The Integrated Cybersecurity Governance Model (ICGM)

[graphic download - https://securecontrolsframework.com/content/Plan-Do-Check-Act.pdf]

ICM PRINCIPLE 1: ESTABLISH CONTEXT

To build and maintain efficient and effective operations, a cybersecurity & data privacy program must have a hierarchical vision,
mission and strategy that directly supports the organization’s broader strategic objectives and business processes. This process
of establishing context involves identifying all applicable external compliance requirements (e.g., laws, regulations and
contractual obligations), as well as internal directives (e.g., Board of Directors, corporate policies, etc.). This is both a due
diligence and due care element of the cybersecurity & data privacy program, since context changes with time.

Things to consider when establishing context:

 Mission / vision / strategy of the organization;
 Statutory (law), regulatory (regulation) and contractual requirements for cybersecurity and data protection;
 Fiscal constraints;
 Organizational structure;
 Organizational risk appetite;
 Corporate culture (e.g., how receptive is the organization to change); and
 Geographic-specific requirements.

ICM PRINCIPLE 1 IMPLEMENTATION GUIDANCE

Part of your due diligence process is to establish the context of the scope for cybersecurity & data privacy controls. Practical steps
to establish context includes:
 Read through the C|P principles to familiarize yourself with the thirty-three (33) domains to understand how they come
together to address the cybersecurity, privacy and physical security considerations for a modern security program.
 Talk with representatives outside of IT and cybersecurity to gain an appreciation of other compliance requirements (e.g.,
legal, procurement, physical security, etc.).
 Come up with a list of the “must have” laws, regulations and frameworks that your organization must comply with.
 Come up with a list of “nice to have” requirements that your Board of Directors, or other stakeholders, feel are necessary.

Understanding the requirements for both cybersecurity & data privacy principles involve a simple process of distilling
expectations. This process is all part of documenting reasonable expectations that are “right-sized” for an organization, since
every organization has unique requirements.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 33 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
Some people freak out and think they must do all 1,200+ controls in the SCF and that is just not the case. It is best to visualize the
SCF as a “buffet of cybersecurity & data privacy controls,” where there is a selection of 1,200+ controls available to you. Just as
you do not eat everything possible on a buffet table, the same applies to the SCF’s control set. Once you know what is applicable
to you, you can generate a customized control set that gives you just the controls you need to address your statutory, regulatory
and contractual obligations.

The approach looks at the following spheres of influence to identify applicable SCF controls:
 Statutory obligations - These are laws (e.g., US state, federal and international laws).
 Regulatory obligations - These are requirements from regulatory bodies or governmental agencies.
 Contractual obligations - These are requirements that are stipulated in contracts, vendor agreements, etc.
 Industry-recognized practices - These are requirements that are based on an organization’s specific industry that are
considered reasonably-expected practices.

Please keep in mind that the SCF is a tool and is only as good as its used – just like a pocketknife shouldn’t be used as a prybar.
Realistically, if you do not scope the controls from the SCF correctly, you will not address your applicable compliance
requirements since you are missing what is expected. That is not a deficiency of the SCF – that is simply negligence on the part of
the user of the tool.

To make sure scoping is done properly, it is imperative for you to speak with your legal, IT, project management, cybersecurity and
procurement teams (and other stakeholders you may feel are relevant to scoping controls). The reason for this collaboration is so
that you can get a complete picture of all the applicable laws, regulations and frameworks that your organization is legally
obligated to comply with. Those teams will likely provide the best insights into what is required, and this list of requirements will
then make it simple to go through and customize the SCF for your specific needs!

ICM PRINCIPLE 2: DEFINE APPLICABLE CONTROLS

A tailored control set cybersecurity & data privacy controls must exist. This control set needs to be made of Minimum Compliance
Requirements (MCR) and Discretionary Security Requirements (DSR). This blend of “must have” and “nice to have” requirements
establish an organization’s tailored control set to ensure both secure practices and compliance.

Things to consider when defining applicable controls:

 Controls to address “must have” requirements from laws, regulations and contractual obligations to ensure the
organization is compliant with its obligations;
 Controls to address “discretionary” requirements that exist to ensure the organization has secure and resilient
operations; and
 There needs to be at least an annual review to ensure the applicable controls are accurate to the current needs for
compliance, security and resilience.

ICM PRINCIPLE 2 IMPLEMENTATION GUIDANCE

The SCF is fundamentally an Excel spreadsheet. Therefore, you can use your Excel skills to manually filter the requirements. If you
are comfortable with Excel, it might take you 5-10 minutes to do this filtering, based on how many requirements you need to map
to. Within the SCF, there is a column labelled “Minimum Security Requirements (MSR) MCR + MSR” that will assist you in this
process.

Follow these steps to tailor the SCF:

1. Either hide or delete all of the columns containing laws, regulations or frameworks that are not applicable to your
organization (e.g., if you only have to comply with ISO 27002, PCI DSS and EU GDPR, then you can delete or hide all other
mapping columns but those).Using the filter option in Excel (little gray arrow on the top row in each column), you would
then filter the columns to only show cells that contain content (e.g., don’t show blank cells in that column).
2. A selection of either MCR or DSR will automatically select the MSR + DSR column:
a. In the MCR column, simply put an “x” to mark that control as being “must have” controls.
b. In the DSR column, simply put an “x” to mark that control as being “nice to have” controls.
3. Unfilter the column you just performed this task on and do it to the next law, regulation or framework that you need to
map.
4. Repeat steps 2 and step 3 until all your applicable laws, regulations and frameworks are mapped to.

The MSR + DSR column will now have an “x” that marks each SCF control that is applicable for your needs, based on what was

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 34 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
selected for MCR and DSR controls. This will leave you with a SCF control set that is tailored for your specific needs.

ICM PRINCIPLE 3: ASSIGN MATURITY-BASED CRITERIA

The cybersecurity & data privacy program must assign maturity targets to define organization-specific “what right looks like” for
controls. This establishes attainable criteria for People, Processes, Technologies, Data & Facilities (PPTDF) requirements.
Tailored maturity level criteria can be used to plan for, budget for and assess against. Maturity targets should support the
organization’s need for operational resiliency.

Things to consider when assigning maturity-based criteria:

 Not all controls need to be the same level of maturity, since each control has an associated cost. The higher the level of
maturity, the higher the cost. This is a risk management decision to define what right looks like for the organization;
 The expected level of maturity needs to at least comply with applicable statutory, regulatory and contractual
requirements; and
 Lower levels of maturity may be considered negligent behavior from a due care perspective.

ICM PRINCIPLE 3 IMPLEMENTATION GUIDANCE

From the previous step, you identified the controls that are applicable to your specific needs (e.g., MCR + DSR). You can now use
the SP- CMM criteria to “define what right looks like” for each control. This is further explained in the Cybersecurity & Data Privacy
Capability Maturity Model (C|P-CMM). 22

The C|P-CMM draws upon the high-level structure of the Systems Security Engineering Capability Maturity Model v2.0 (SSE-CMM),
since we felt it was the best model to demonstrate varying levels of maturity for PPTDF at a control level. If you are unfamiliar with
the SSE-CMM, it is well-worth your time to read through the SSE-CMM Model Description Document that is hosted by the US
Defense Technical Information Center (DTIC).

ICM PRINCIPLE 4: PUBLISH POLICIES & STANDARDS

Documentation must exist, otherwise an organization’s cybersecurity & data privacy practices are unenforceable. Formalizing
organization-specific requirements via policies and standards are necessary to operationalize controls. Documented policies and
standards provide evidence of due diligence that the organization identified and implemented reasonable steps to address its
applicable requirements.

Things to consider when publishing policies & standards:

 The policies and standards need to reflect both the “must have” and “nice to have” requirements identified in Principle
2;
 Policies should be designed as “high level statements of management intent” and are not expected to change often; and
 Standards should be designed to assign granular requirements to enforce policies. As technologies change/evolve, those
standards will need to change to ensure compliant, secure and resilient operations.

ICM PRINCIPLE 4 IMPLEMENTATION GUIDANCE

There are generally three (3) options to obtain cybersecurity & data privacy documentation:
1. Use internal resources to write it in-house;
2. Hire a consultant to write a bespoke set of documentation; or
3. Purchase semi-customized templates online.

NOTE: ComplianceForge is a SCF Licensed Content Provider (LCP) and has editable policies, standards and procedures
templates that are based on the SCF.

ICM PRINCIPLE 5: ASSIGN STAKEHOLDER ACCOUNTABILITY

Controls must be assigned to stakeholders to ensure accountability (e.g., business units, teams and/or individuals). These
“control owners” may assign the task of executing controls to “control operators” at the Individual Contributors (IC)-level.
Stakeholders utilize the prescriptive requirements from policies and standards to develop Standardized Operating Procedures
(SOP) that enable ICs to execute those controls. The documented execution of procedures provides evidence of due care that
reasonable practices are being performed.

22 SCF C|P-CMM - https://securecontrolsframework.com/capability-maturity-model/

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 35 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
Things to consider when assigning stakeholder accountability:
 Procedures are not “owned” by the cybersecurity or privacy teams. Procedures are the responsibility of the control owner
/ operator; and
 The NIST NICE Cybersecurity Workforce Framework is a methodology to identify cybersecurity and data privacy-related
roles and associated responsibilities.23

ICM PRINCIPLE 5 IMPLEMENTATION GUIDANCE

Assigning stakeholder accountability offers unique challenges for organizations, since it is beyond IT, cybersecurity & data privacy.
Common stakeholders involve Human Resources (HR), procurement, facilities management, legal and many other teams to
ensure accountability is enforceable. Realistically, this step is an executive-management function since it requires inter-
departmental enforcement by organizational management.

A great starting point is the NIST SP 800-181, Workforce Framework for Cybersecurity (NICE Framework). 24 The NICE Framework
offers an efficient way to assign stakeholder accountability for internal and external stakeholders.

ICM PRINCIPLE 6: MAINTAIN SITUATIONAL AWARENESS

Situational awareness must involve more than merely “monitoring controls” (e.g., metrics). While metrics are a point-in-time
snapshot into discrete controls’ performance, the broader view of metrics leads to a longer-term trend analysis. When properly
tied in with current risk, threat and vulnerability information, this insight provides “situational awareness” that is necessary for
organizational leadership to adjust plans to operate within the organization’s risk threshold.

Things to consider when maintaining situation awareness:

 Metrics/analytics are meant to tell the long-term story of how the cybersecurity and data privacy program is doing. The
historical performance provides context to an organization’s senior leaders; and
 The metrics/analytics needs to be tied to measurable controls that can help eliminate Fear, Uncertainty and Doubt (FUD)
reporting.

ICM PRINCIPLE 6: IMPLEMENTATION GUIDANCE

Maintaining situational awareness has different meanings, based
on the security culture of an organization. Metrics / analytics
reporting is plagued by the Garbage In, Garbage Out (GIGO)
problem. Often the GIGO issue is rooted in executives trying to
explain their perceived needs for metrics to cybersecurity
practitioners in a way that describes the design of a "football bat"
(e.g., nonsensical solution).

ComplianceForge’s Cybersecurity Metrics Reporting Model

(CMRM) takes a practical view towards implementing a sustainable
metrics reporting capability. 25 At the end of the day, executive
management often just wants a simple answer to a relatively-
straightforward question: “Are we secure?”

ICM PRINCIPLE 7: MANAGE RISK

Proactive risk management processes must exist across all phases of development/information/system life cycles to address
confidentiality, integrity, availability and safety aspects. Risk management must address internal and external factors, including
privacy and Supply Chain Risk Management (SCRM) considerations. To manage risk, it requires the organization to enforce a
clearly defined risk threshold and ensure reasonable security practices are operational.

23 NIST NICE - https://www.nist.gov/itl/applied-cybersecurity/nice/nice-framework-resource-center

24 NIST SP 800-181 - https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-181r1.pdf
25 Cybersecurity Metrics Reporting Model (CMRM) - https://complianceforge.com/content/pdf/complianceforge-cybersecurity-metrics-reporting-model.pdf

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 36 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
Things to consider when managing risk:
 Traditional risk management practices have four (4) options to address identified risk:
o Reduce the risk to an acceptable level;
o Avoid the risk;
o Transfer the risk to another party; or
o Accept the risk.
 To provide the context of which option is viable for an organization, there needs to be defined risk tolerance.

ICM PRINCIPLE 7 IMPLEMENTATION GUIDANCE

There are many ways to manage risk. However, the SCF’s Cybersecurity & Data Privacy Risk Management Model (C|P-RMM)
contains a control-centric:26
 Risk catalog;
 Threat catalog; and
 Methodology to not only perform a risk assessment, but manage risk across the organization.

The value of the C|P-RMM is having a standardized methodology where controls are tied to specific risks and threats. Based on
the other criteria offered by the SCF (e.g., weighting and maturity criteria), the C|P-RMM makes calculating risk a straightforward
process.

Controls are the nexus of a cybersecurity & data privacy program, so it is vitally important to understand how controls should be
viewed from a high-level risk management perspective. To progress from identifying a necessary control to a determination of risk,
it is a journey that has several steps, each with its own unique terminology. Therefore, it is important to baseline the understanding
of risk management terminology.

Traditional risk management practices have four (4) options to address identified risk:
1. Reduce the risk to an acceptable level;
2. Avoid the risk;
3. Transfer the risk to another party; or
4. Accept the risk.

In a mature risk program, the results of risk assessments are evaluated with the organization's risk appetite into consideration.
For example, if the organization has a Moderate Risk Appetite and there are several findings in a risk assessment that are High
Risk, then action must be taken to reduce the risk. Accepting a High Risk would violate the Moderate Risk Appetite set by
management. In reality, this leaves remediation, transferring or avoiding as the remaining three (3) options, since accepting the
risk would be prohibited.

Risk management involves coordinated activities that optimize the management of potential opportunities and adverse effects.
Proactive risk management activities provide a way to realize potential opportunities without exposing an organization to
unnecessary peril.

The goal of risk analysis is to determine the potential negative

implications of an action or situation to determine one (1) of
two (2) decisions:
1. Acceptable Risk: the criteria fall within a range of
acceptable parameters; or
2. Unacceptable Risk: The criteria fall outside a range of
acceptable parameters.

ICM PRINCIPLE 8: EVOLVE PROCESSES

Cybersecurity & data privacy measures must adapt and evolve to address business operations and the evolving threat landscape.
This requires the adoption of a Plan, Do, Check & Act (PDCA) approach (e.g., Deming Cycle) to ensure the organization proactively
identifies its requirements, implements appropriate protections, maintains situational awareness to detect incidents, operates a
viable capability to respond to incidents and can sustain key business operations, if an incident occurs.

26 SCF C|P-RMM - https://securecontrolsframework.com/risk-management-model/

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 37 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
Things to consider when evolving processes:
 Changes in the compliance landscape (e.g., laws, regulations and contractual obligations);
 Technology changes; and
 Budget/resourcing constraints that affect how processes are implemented.

ICM PRINCIPLE 8 IMPLEMENTATION GUIDANCE

The ComplianceForge Integrated Cybersecurity Governance Model™ (ICGM) takes a comprehensive view towards governing a
cybersecurity & data privacy program.27 Without an overarching concept of operations for the broader GRC/IRM function,
organizations will often find that their governance, risk management, compliance and privacy teams are siloed in how they think
and operate. These siloed functions and unclear roles often stem from a lack of a strategic understanding of how these specific
functions come together to build a symbiotic working relationship between the individual teams that enables quality control over
PPTDF.

The ICGM utilizes a Plan, Do, Check & Act (PDCA) approach that is a logical way to design a governance structure:
 Plan. The overall ICM process beings with planning. This planning will define the policies, standards and controls for the
organization. It will also directly influence the tools and services that an organization purchases, since technology
purchases should address needs that are defined by policies and standards.
 Do. Arguably, this is the most important section for cybersecurity & data privacy practitioners. Controls are the “security
glue” that make processes, applications, systems and services secure. Procedures (also referred to as control activities)
are the processes in which the controls are actually implemented and performed.
 Check. In simple terms, this is situational awareness. Situational awareness is only achieved through reporting through
metrics and reviewing the results of audits/assessments.
 Act. This is essentially risk management, which is an encompassing area that deals with addressing two main concepts
(1) real deficiencies that currently exist and (2) possible threats to the organization.

27 Integrated Controls Management (ICM) Model - https://securecontrolsframework.com/integrated-controls-management/

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 38 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 8. CYBERSECURITY & DATA PRIVACY CAPABILITY MATURITY MODEL (C|P-CMM)
The C|P-CMM is meant to solve the problem of objectivity in both establishing and evaluating cybersecurity and data privacy
controls. There are four (4) main objectives for the C|P-CMM:
1. Provide CISO/CPOs/CIOs with objective criteria that can be used to establish expectations for a cybersecurity & privacy
program;
2. Provide objective criteria for project teams so that secure practices are appropriately planned and budgeted for;
3. Provide minimum criteria that can be used to evaluate third-party service provider controls; and
4. Provide a means to perform due diligence of cybersecurity and data privacy practices as part of Mergers & Acquisitions
(M&A).

There are likely many other use cases that the C|P-CMM can be used, but those objectives listed above drove the development of
this project. The reason for this simply comes down to a need by businesses, regardless of size or industry, for a solution that can
help fix those common frustrations that exist in most cybersecurity and data privacy programs. We want to help eliminate, or at
least minimize, the Fear, Uncertainty & Doubt (FUD) that is used to justify purchases and/or evaluate controls by injecting
objectivity into the process.

WELL ESTABLISHED MATURITY MODEL

There are many competing models that exist to demonstrate maturity. Given the available choices, the SCF decided to leverage
an existing framework, rather than reinvent the wheel. In simple terms, we provided control-level criteria to an existing CMM
model.

The C|P-CMM draws upon the high-level structure of the Systems Security Engineering Capability Maturity Model v2.0 (SSE-CMM),
since we felt it was the best model to demonstrate varying levels of maturity for PPTDF at a control level. If you are unfamiliar with
the SSE-CMM, it is well-worth your time to read through the SSE-CMM Model Description Document that is hosted by the US
Defense Technical Information Center (DTIC). 28

The SSE-CMM has been around for over two decades and is a community-owned maturity model, so it is free to use. The SSE-
CMM is also referenced as ISO/IEC 21827:2008 Information technology -- Security techniques -- Systems Security Engineering --
Capability Maturity Model (SSE-CMM).29

NESTED APPROACH TO MATURITY

By using the term “nested” regarding maturity, we refer to how the C|P-CMM’s control criteria were written to acknowledge that
each succeeding level of maturity is built upon its predecessor. Essentially, you cannot run without first learning how to walk.
Likewise, you cannot walk without first learning how to crawl. This approach to defining cybersecurity & privacy control maturity
is how the C|P-CMM is structured.

28 Defense Technical Information Center (DTIC) - https://apps.dtic.mil/dtic/tr/fulltext/u2/a393329.pdf

29 ISO/IEC 21827:2008 - https://www.iso.org/standard/44716.html

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 39 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
MATURITY (GOVERNANCE) ≠ ASSURANCE (SECURITY)
It is unfortunate that it must be explicitly stated, but a “maturity model” is entirely dependent upon the ethics and integrity of the
individual(s) involved in the evaluation process. This issue is often rooted in the assessor’s perceived pressure that a control
should be designated as being more mature than it is (e.g., dysfunctional management influence). Regardless of the reason, it
must be emphasized that consciously designating a higher level of maturity (based on objective criteria) to make an organization
appear more mature should be considered fraud. Fraud is a broad term that includes “false representations, dishonesty and
deceit.”30

This stance on fraudulent misrepresentations may appear harsh, but it accurately describes the situation. There is no room in
cybersecurity and data protection operations for unethical parties, so the SCF Council published this guidance on what a
“reasonable party perspective” should be. This provides objectivity to minimize the ability of unethical parties to abuse the
intended use of the C|P-CMM.

The following two (2) questions should be kept in mind when evaluating the maturity of a control (or Assessment Objective (AO)).
1. Do I have reasonable evidence to defend my analysis/decision?
2. If there was an incident and I was deposed in a legal setting, can I justify my analysis/decision without perjuring myself?

Do you need to answer “yes” to every bullet pointed criteria under a level of maturity in the C|P-CMM? No. We recognize that every
organization is different. Therefore, the maturity criteria items associated with SCF controls are to help establish what would
reasonably exist for each level of maturity. Fundamentally, the decision comes down to assessor experience, professional
competence and common sense.

While a more mature implementation of controls can equate to an increased level of security, higher maturity and higher
assurance are not mutually inclusive. From a practical perspective, maturity is simply a measure of governance activities
pertaining to a specific control or set of controls. Maturity does not equate to an in-depth analysis of the strength and depth of the
control being evaluated (e.g., rigor).

According to NIST, assurance is “grounds for confidence that the set of intended security controls in an information system are
effective in their application.”31 Increased rigor in control testing is what leads to increased assurance. Therefore, increased rigor
and increased assurance are mutually inclusive.

The SCF Conformity Assessment Program (SCF CAP) leverages (3) three levels of rigor. The SCF CAP’s levels of rigor utilize
maturity-based criteria to evaluate a control, since a maturity target can provide context for “what right looks like” at a particular
organization: 32
 Level 1 (Basic) - Basic assessments provide a level of understanding of the security measures necessary for determining
whether the safeguards are implemented and free of obvious errors.
 Level 2 (Focused) - Focused assessments provide a level of understanding of the security measures necessary for
determining whether the safeguards are implemented and free of obvious / apparent errors and whether there are
increased grounds for confidence that the safeguards are implemented correctly and operating as intended.
 Level 3 (Comprehensive) - Comprehensive assessments provide a level of understanding of the security measures
necessary for determining whether the safeguards are implemented and free of obvious errors and whether there are
further increased grounds for confidence that the safeguards are implemented correctly and operating as intended on an
ongoing and consistent basis and that there is support for continuous improvement in the effectiveness of the
safeguards.

DEFINING C|P-CMM LEVELS

A summary of the six (6) C|P-CMM levels are described below:
1. CMM Level 0 – Not Performed;
2. CMM Level 1 – Performed Informally;
3. CMM Level 2 – Planned & Tracked;
4. CMM Level 3 – Well Defined;
5. CMM Level 4 - Quantitatively Controlled; and
6. CMM Level 5 – Continuously Improving.

30 US Department of Justice - https://www.justice.gov/archives/jm/criminal-resource-manual-1007-fraud

31 US Department of Justice - https://www.justice.gov/archives/jm/criminal-resource-manual-1007-fraud
32 SCF CAP - https://securecontrolsframework.com/scf-conformity-assessment-program-cap/

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 40 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
C|P-CMM LEVEL 0 (L0) - NOT PERFORMED
This level of maturity is defined as “non-existence practices,” where the control is not being performed:
 Practices are non-existent, where a reasonable person would conclude the control is not being performed.
 Evidence of due care33 and due diligence34 do not exist to demonstrate compliance with applicable statutory, regulatory
and/or contractual obligations.

L0 practices, or a lack thereof, are generally considered to be negligent. The reason for this is if a control is reasonably-expected
to exist, by not performing the control that is negligent behavior. The need for the control could be due to a law, regulation or
contractual obligation (e.g., client contract or industry association requirement).
NOTE: The reality with a L0 level of maturity is often:
 For smaller organizations, the IT support role only focuses on “break / fix” work or the outsourced IT provider has a scope
in its support contract that excludes the control through either oversight or ignorance of the client’s requirements.
 For medium / large organizations, there is IT and/or cybersecurity staff, but governance is functionally non-existent and
the control is not performed through either oversight, ignorance or incompetence.

C|P-CMM LEVEL 1 (L1) - PERFORMED INFORMALLY

This level of maturity is defined as “ad hoc practices,” where the control is being performed, but lacks completeness &
consistency:
 Practices are “ad hoc” where the intent of a control is not met due to a lack consistency and formality.
 When the control is met, it lacks consistency and formality (e.g., rudimentary practices are performed informally).
 A reasonable person would conclude the control is not consistently performed in a structured manner.
 Performance depends on specific knowledge and effort of the individual performing the task(s), where the performance
of these practices is not proactively governed.
 Limited evidence of due care and due diligence exists, where it would be difficult to legitimately disprove a claim of
negligence for how cybersecurity/privacy controls are implemented and maintained.

L1 practices are generally considered to be negligent. The reason for this is if a control is reasonably-expected to exist, by only
implementing ad-hoc practices in performing the control that could be considered negligent behavior. The need for the control
could be due to a law, regulation or contractual obligation (e.g., client contract or industry association requirement).
NOTE: The reality with a L1 level of maturity is often:
 For smaller organizations, the IT support role only focuses on “break / fix” work, or the outsourced IT provider has a limited
scope in its support contract.
 For medium / large organizations, there is IT and/or cybersecurity staff but there is no management focus to spend time
or resources on the control.

C|P-CMM LEVEL 2 (L2) - PLANNED & TRACKED

Practices are “requirements-driven” where the intent of control is met in some circumstances, but not standardized across the
entire organization:
 Practices are “requirements-driven” (e.g., specified by a law, regulation or contractual obligation) and are tailored to
meet those specific compliance obligations (e.g., evidence of due diligence).
 Performance of a control is planned and tracked according to specified procedures and work products conform to
specified standards (e.g., evidence of due care).
 Controls are implemented in some, but not all applicable circumstances/environments (e.g., specific enclaves, facilities
or locations).
 A reasonable person would conclude controls are “compliance-focused” to meet a specific obligation, since the
practices are applied at a local/regional level and are not standardized practices across the enterprise.
 Sufficient evidence of due care and due diligence exists to demonstrate compliance with specific statutory, regulatory
and/or contractual obligations.

L2 practices are generally considered to be “audit ready” with an acceptable level of evidence to demonstrate due diligence and
due care in the execution of the control. L2 practices are generally targeted on specific systems, networks, applications or
processes that require the control to be performed for a compliance need (e.g., PCI DSS, HIPAA, CMMC, NIST 800-171, etc.).

It can be argued that L2 practices focus more on compliance over security. The reason for this is the scoping of L2 practices are

33 Due care is the standard of care where a reasonable person would exercise in the same situation or under similar circumstances. This standard of care is used
to determine whether a party’s actions (or inactions) were negligent.
34 Due diligence is the care that a reasonable person exercises to avoid harm to other persons or their property.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 41 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
narrowly-focused and are not enterprise-wide.

NOTE: The reality with a L2 level of maturity is often:

 For smaller organizations:
o IT staff have clear requirements to meet applicable compliance obligations, or the outsourced IT provider is
properly scoped in its support contract to address applicable compliance obligations.
o It is unlikely that there is a dedicated cybersecurity role and at best it is an additional duty for existing personnel.
 For medium / large organizations:
o IT staff have clear requirements to meet applicable compliance obligations.
o There is most likely a dedicated cybersecurity role or a small cybersecurity team.

C|P-CMM LEVEL 3 (L3) - WELL DEFINED

This level of maturity is defined as “enterprise-wide standardization,” where the practices are well-defined and standardized
across the organization:
 Practices are standardized “enterprise-wide” where the control is well-defined and standardized across the entire
enterprise.
 Controls are implemented in all applicable circumstances/environments (deviations are documented and justified).
 Practices are performed according to a well-defined process using approved, tailored versions of standardized
processes.
 Performance of a control is according to specified well-defined and standardized procedures.
 Control execution is planned and managed using an enterprise-wide, standardized methodology.
 A reasonable person would conclude controls are “security-focused” that address both mandatory and discretionary
requirements. Compliance could reasonably be viewed as a “natural byproduct” of secure practices.
 Sufficient evidence of due care and due diligence exists to demonstrate compliance with specific statutory, regulatory
and/or contractual obligations.
 The Chief Information Security Officer (CISO), or similar function, develops a security-focused Concept of Operations
(CONOPS) that documents organization-wide management, operational and technical measures to apply defense-in-
depth techniques (in this context, a CONOPS is a verbal or graphic statement of intent and assumptions regarding
operationalizing the identified tasks to achieve the CISO’s stated objectives. The result of the CONOPS is operating the
organization’s cybersecurity and data protection program so that it meets business objectives). Control or domain-
specific CONOPS may be incorporated as part of a broader operational plan for the cybersecurity and data privacy
program (e.g., cybersecurity-specific business plan).
L3 practices are generally considered to be “audit ready” with an acceptable level of evidence to demonstrate due diligence and
due care in the execution of the control. Unlike L2 practices that are narrowly focused, L3 practices are standardized across the
organization.

It can be argued that L3 practices focus on security over compliance, where compliance is a natural byproduct of those secure
practices. These are well-defined and properly-scoped practices that span the organization, regardless of the department or
geographic considerations.

NOTE: The reality with a L3 level of maturity is often:

 For smaller organizations:
o There is a small IT staff that has clear requirements to meet applicable compliance obligations.
o There is a very competent leader (e.g., security manager / director) with solid cybersecurity experience who has
the authority to direct resources to enact secure practices across the organization.
 For medium / large organizations:
o IT staff have clear requirements to implement standardized cybersecurity & privacy principles across the
enterprise.
o In addition to the existence of a dedicated cybersecurity team, there are specialists (e.g., engineers, SOC
analysts, GRC, privacy, etc.)
o There is a very competent leader (e.g., CISO) with solid cybersecurity experience who has the authority to direct
resources to enact secure practices across the organization.

C|P-CMM LEVEL 4 (L4) - QUANTITATIVELY CONTROLLED

This level of maturity is defined as “metrics-driven practices,” where in addition to being well-defined and standardized practices
across the organization, there are detailed metrics to enable governance oversight:
 Practices are “metrics-driven” and provide sufficient management insight (based on a quantitative understanding of

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 42 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 process capabilities) to predict optimal performance, ensure continued operations, and identify areas for improvement.
 Practices build upon established L3 maturity criteria and have detailed metrics to enable governance oversight.
 Detailed measures of performance are collected and analyzed. This leads to a quantitative understanding of process
capability and an improved ability to predict performance.
 Performance is objectively managed, and the quality of work products is quantitatively known.

L4 practices are generally considered to be “audit ready” with an acceptable level of evidence to demonstrate due diligence and
due care in the execution of the control, as well as detailed metrics enable an objective oversight function. Metrics may be daily,
weekly, monthly, quarterly, etc.

NOTE: The reality with a L4 level of maturity is often:

 For smaller organizations, it is unrealistic to attain this level of maturity.
 For medium / large organizations:
o IT staff have clear requirements to implement standardized cybersecurity & privacy principles across the
enterprise.
o In addition to the existence of a dedicated cybersecurity team, there are specialists (e.g., engineers, SOC
analysts, GRC, privacy, etc.)
o There is a very competent leader (e.g., CISO) with solid cybersecurity experience who has the authority to direct
resources to enact secure practices across the organization.
o Business stakeholders are made aware of the status of the cybersecurity and data privacy program (e.g.,
quarterly business reviews to the CIO/CEO/board of directors). This situational awareness is made possible
through detailed metrics.

C|P-CMM LEVEL 5 (L5) - CONTINUOUSLY IMPROVING

This level of maturity is defined as “world-class practices,” where the practices are not only well-defined and standardized across
the organization, as well as having detailed metrics, but the process is continuously improving:
 Practices are “world-class” capabilities that leverage predictive analysis.
 Practices build upon established L4 maturity criteria and are time-sensitive to support operational efficiency, which likely
includes automated actions through machine learning or Artificial Intelligence (AI).
 Quantitative performance goals (targets) for process effectiveness and efficiency are established, based on the business
goals of the organization.
 Process improvements are implemented according to “continuous improvement” practices to affect process changes.

L5 practices are generally considered to be “audit ready” with an acceptable level of evidence to demonstrate due diligence and
due care in the execution of the control and incorporates a capability to continuously improve the process. Interestingly, this is
where Artificial Intelligence (AI) and Machine Learning (ML) would exist, since AI/ML would focus on evaluating performance and
making continuous adjustments to improve the process. However, AI/ML are not required to be L5.

NOTE: The reality with a L5 level of maturity is often:

 For small and medium-sized organizations, it is unrealistic to attain this level of maturity.
 For large organizations:
o IT staff have clear requirements to implement standardized cybersecurity & privacy principles across the
enterprise.
o In addition to the existence of a dedicated cybersecurity team, there are specialists (e.g., engineers, SOC
analysts, GRC, privacy, etc.)
o There is a very competent leader (e.g., CISO) with solid cybersecurity experience who has the authority to direct
resources to enact secure practices across the organization.
o Business stakeholders are made aware of the status of the cybersecurity and data privacy program (e.g.,
quarterly business reviews to the CIO/CEO/board of directors). This situational awareness is made possible
through detailed metrics.
o The organization has a very aggressive business model that requires not only IT, but its cybersecurity and data
privacy practices, to be innovative to the point of leading the industry in how its products and services are
designed, built or delivered.
o The organization invests heavily into developing AI/ML technologies to make near real-time process
improvements to support the goal of being an industry leader.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 43 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
DEFINING A CAPABILITY MATURITY “SWEET SPOT”
For most organizations, the “sweet spot” for maturity targets is between L2 and L4 levels. What defines the ideal target within this
zone is generally based on resource limitations and other business constraints, so it goes beyond just the cybersecurity and data
privacy teams dictating targets. Identifying maturity targets is meant to be a team effort between both technologists and business
stakeholders.

From a business consideration, the increase in cost and complexity will always require cybersecurity and data privacy leadership
to provide a compelling business case to support any maturity planning needs. Speaking in terms the business can understand is
vitally important.

NOTE: During the development of the C|P-CMM, a contributor identified an interesting insight that L0-L3 are “internal” maturity
levels for cybersecurity and data privacy teams, whereas L4-L5 are “external” maturity levels that expand beyond those teams.
When you look at the stakeholders involved in L0-L3, it is almost entirely IT, cybersecurity and data privacy. It isn’t until L4-L5 where
there is true business stakeholder involvement in oversight and process improvement. This creates an internal to external shift in
owning the cybersecurity & privacy program.

NEGLIGENCE CONSIDERATIONS
Without the ability to demonstrate evidence of both due care and due diligence, an organization may be found negligent. In
practical terms, the “negligence threshold” is between L1 and L2. The reason for this is at L2, practices are formalized to the point
that documented evidence exists to demonstrate reasonable steps were taken to operate a control.

RISK CONSIDERATIONS
Risk associated with the control in question decreases with maturity, but noticeable risk reductions are harder to attain above L3.
Oversight and process automation can decrease risk, but generally not as noticeably as steps taken to attain L3.

PROCESS REVIEW LAG CONSIDERATIONS

Process improvements increase with maturity, based on shorter review cycles and increased process oversight. What might have
been an annual review cycle to evaluate and tweak a process can be near real-time with Artificial Intelligence (AI) and Machine
Learning (ML).

STAKEHOLDER VALUE CONSIDERATIONS

The perceived value of security controls increases with maturity. However, perceived value tends to decrease after L3 since the
value of the additional cost and complexity becomes harder to justify to business stakeholders. Companies that are genuinely
focused on being industry leaders are ideal candidates for L5 targets to support their aggressive business model needs.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 44 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
ANALOG EXAMPLE – SIT / CRAWL / WALK / RUN / SPRINT / HURDLE
The following example shows this approach being applied to the maturity levels for running, where it demonstrates the nested
approach to the maturity levels by each succeeding level of maturity incorporates skills learned by the preceding level.

The point of this example is to demonstrate a relatable scenario that readers can comprehend how being asked to jump straight
into an advanced level of maturity is not practical, where it requires some level of lesser maturity. For example, if you were just
learning how to walk, it would be foolish to try and run the 400m hurdles that require both the strength and skill of sprinting, but
also the knowledge of how to jump over an obstacle.

In this example, this maturity model is applied to a control to raise an individual’s resting heart rate through exercise.
 L0 – Sitting Down
o Sitting down would be non-existent effort. No evidence of exercise exists.
o Sitting down would be considered deficient in terms of meeting this control.
 L1 – Crawling
o Crawling is at best considered ad-hoc exercise and likely doesn’t meet the intent of the control.
o Crawling would be considered deficient in terms of meeting this control.
 L2 – Walking
o Walking builds on skills learned through crawling and demonstrates a capability that raises the individuals’
resting heart rate.
o Walking would meet the intent of the control, but there is clearly room for improvement.
 L3 – Running
o Running builds on the skills learned through walking and meets the control’s intent.
o Running would be the “sweet spot” of maturity for this example.
 L4 – 400-meter Sprint
o Sprinting builds on the skills learned through running and meets the control’s intent.
o Sprinting requires mastery of running skills to do it properly and avoid injury.
 L5 – 400-meter Hurdles
o Running the hurdles builds upon skills learned through sprinting and meets the control’s intent.
o Hurdling requires a mastery of sprinting, since jumping hurdles is in addition to a sprinting race.

MATURITY MODEL USE CASES

The C|P-CMM is meant to solve the problem of objectivity in both establishing and evaluating cybersecurity and data privacy
controls. There are four (4) main objectives for the C|P-CMM:
1. Provide CISO/CPOs/CIOs with objective criteria that can be used to establish expectations for a cybersecurity & privacy
program;
2. Provide objective criteria for project teams so that secure practices are appropriately planned and budgeted for;
3. Provide minimum criteria that can be used to evaluate third-party service provider controls; and
4. Provide a means to perform due diligence of cybersecurity and data privacy practices as part of Mergers & Acquisitions
(M&A).

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 45 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
USE CASE #1 – OBJECTIVE CRITERIA TO BUILD A CYBERSECURITY & PRIVACY PROGRAM
Identifying a target maturity state is intended to support your organization’s mission and strategy so without first understanding the
broader mission of the organization and having prioritized objectives, a CISO/CIO/CPO will be guessing when it comes to establishing
expectations for capability maturity. Like anything in life, if you fail to plan you plan to fail - CMM rollouts are no exception.

The time to execute a business plan to mature a cybersecurity and data privacy program generally spans several years, where
certain capabilities are prioritized over other capabilities. This means the CISO/CIO/CPO will establish CMM targets that evolve
each year, based on prioritization. In the graphic below, the use of a spider chart can be beneficial to identify current vs future
gaps with the C|P-CMM. Prioritization of capability maturities may be based on risk assessments, audits, compliance obligations
or management direction.

IDENTIFYING THE PROBLEM

Using a CMM helps organizations avoid “moving targets” for expectations. Maturity goals define “what right looks like” in terms of
the required PPTDF that are expected to exist to execute controls at the individual contributor level. Without maturity goals, it is
very difficult and subjective to define success for a security & privacy program.

All too often, unprincipled cybersecurity & privacy leaders manipulate the business through Fear, Uncertainty and Doubt (FUD) to
scare other technology and business leaders into supporting cybersecurity initiatives. These bad actors maintain the illusion of a
strong cybersecurity & privacy program, when, in reality, the department is an array of disjointed capabilities that lacks a unifying
plan. These individuals stay in the job long enough to claim small victories, implement some cool technology, and then jump ship
for larger roles in other organizations to extend their path of disorder. In these cases, a common theme is the lack of viable
business planning beyond a shopping list of technologies and headcount targets to further their career goals.

CONSIDERATIONS
Cybersecurity & privacy departments are a cost center, not a revenue-generating business function. That means cybersecurity &
privacy compete with all other departments for budget, and it necessitates a compelling business case to justify needed
technology and staffing. Business leaders are getting smarter on the topic of cybersecurity & privacy, so these leaders need to rise
above the FUD mentality and deliver value that is commensurate with the needs of the business.
When identifying a target level of maturity, it is crucial to account for your organization’s culture. The reason for this is the
implementation of perceived “draconian” levels of security can cause a revolt in organizations not accustomed to heavy

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 46 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
restrictions. One good rule of thumb when deciding between L3 and L4 targets is this simple question: “Do you want to be in an
environment that is in control, or do you want to be in a controlled environment?” L3 maturity is generally considered “an
environment that is in control” where it is well-managed, whereas being in a L4 environment is more of a “controlled environment”
that is more controlled and less free. Given those considerations, environments not used to heavy restrictions may want to target
L3 as the highest-level of maturity targets. Additionally, the cost to mature from a L3-4 or L4-5 could be hundreds of thousands to
millions of dollars, so there is a very real cost associated with picking a target maturity level. This is again where having
management support is crucial to success, since this is ultimately a management decision.

From a CISO/CIO/CPO perspective, identifying a target level of maturity is also very beneficial in obtaining budget and protecting
their professional reputation. In cases where business leadership doesn’t support reaching the proposed target level of maturity,
the CISO/CIO/CPO at least has documentation to prove he/she demonstrated a defined resourcing need (e.g., CMM level to
support a business need) and the request was denied. Essentially, this can help cover a CISO/CIO/CPO in case an incident occurs
and blame is pointed. That is just the reality of life for anyone in a high-visibility leadership position and being able to deflect
unwarranted criticism is professional reputation insurance.

IDENTIFYING A SOLUTION
The most efficient manner we can recommend would be to first look at the thirty-three (33) domains that make up the SCF and
assign a high-level CMM level target for each domain.

While a CISO/CIO/CPO can stop at the domain level to target CMM levels, it is expected that they or their subordinates go through
each of the corresponding SCF controls to then tag each control with the appropriate target CMM level. These control targets can
then be assigned to managers and Individual Contributors (IC) to develop operational plans to reach those goals. Ideally, a
quarterly status review is conducted to oversee the progress made towards reaching the target CMM levels.

USE CASE #2 – ASSIST PROJECT TEAMS TO APPROPRIATELY PLAN & BUDGET SECURE PRACTICES
When you consider regulations such as the EU General Data Protection Regulation (GDPR), there is an expectation for systems,
applications and processes to identify and incorporate cybersecurity and data privacy by default and by design. To determine
what is appropriate and to evaluate it prior to “go live” it necessitates expectations for control maturity to be defined.

IDENTIFYING THE PROBLEM

In planning a project or initiative, it is important to establish “what right looks like” from cybersecurity and data protection controls
that must be implemented to address all compliance needs. This includes internal requirements, as well as external requirements
from applicable laws, regulations and contracts. Prior planning of requirements can reduce delays and other costs associated
with re-engineering.

CONSIDERATIONS
Referencing back to the C|P-CMM Overview section of this document, L0-1 levels of maturity are identified as being deficient from
a “reasonable person perspective” in most cases. Therefore, project teams need to look at the “capability maturity sweet spot”
between L2-L4 to identify the reasonable people, processes and technologies that need to be incorporated into the solution.

As covered previously, avoiding negligent behavior is a critical consideration. The most common constraints that impact a
project’s maturity are: (1) budget and (2) time. A System Development Life Cycle (SDLC) has constraints, and it is expected that
security and privacy controls are applied throughout the SDLC.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 47 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
Projects do not have unlimited budgets, nor do they tend to have overly flexible timelines that allow for new security & privacy
tools to be installed and trained upon. From a project perspective, this is often going to limit target CMM levels to L2-3 for planning
purposes.

IDENTIFYING A SOLUTION
While there are over 1,200 controls in the SCF’s controls catalog, it is necessary for a project team to pare down that catalog to
only what is applicable to the project (e.g., ISO 27002, PCI DSS, CCPA, etc.). This step simply involves filtering out the controls in
the SCF that are not applicable. This step can also be done within Excel or within a GRC solution (e.g., SCF Connect). In the end,
the result is a tailored set of controls that meets the project’s specific needs.

Now that you have pared down the SCF’s controls catalog to only what is applicable, it is a manual review process to identify the
appropriate level of maturity for each of the controls. Ideally, the project will inherit the same target maturity level for controls as
used throughout the organization. For any deviations, based on budget, time or other constraints, a risk assessment should be
conducted to ensure a lower level of maturity for project-specific controls is appropriate.

USE CASE #3 – PROVIDE OBJECTIVE CRITERIA TO EVALUATE THIRD-PARTY SERVICE PROVIDER SECURITY
It is now commonplace for External Service Providers (ESPs), including vendors and partners, to be contractually bound to
implement and manage a baseline set of cybersecurity and data privacy controls. This necessitates oversight of ESPs to ensure
controls are properly implemented and managed.

IDENTIFYING THE PROBLEM

In managing a cybersecurity and data privacy program, it is important to address controls in a holistic manner, which includes
governing the supply chain. ESPs are commonly considered the “soft underbelly” for an organization’s security program, since
ESP oversight has traditionally been weak or non-existent in most organizations. There have been numerous publicized examples
of ESPs being the source of an incident or breach.

One of the issues with managing ESPs is most questionnaires ask for simple yes, no or not applicable answers. This approach
lacks details that provide critical insights into the actual security posture of the ESP. The C|P-CMM can be used to obtain more
nuanced answers from ESPs by having those ESPs select from L0-5 to answer if the control is implemented and how mature the
process is.

CONSIDERATIONS
Referencing back to the C|P-CMM Overview section of this document, L0-1 levels of maturity are identified as being deficient from
a “reasonable person perspective” in most cases. Therefore, organizations need to look at the “capability maturity sweet spot”
between L2-L4 to identify the reasonable people, processes and technologies that need ESPs need to be able to demonstrate to
properly protect your systems, applications, services and data, regardless of where it is stored, transmitted or processed. From
an ESP management perspective, this is often going to limit target CMM levels to L2-3 for most organizations.

ESP controls are expected to cover both your internal requirements, as well as external requirements from applicable laws,
regulations and contracts. Using the C|P-CMM can be an efficient way to provide a level of quality control over ESP practices.
Being able to demonstrate proper cybersecurity and data privacy practices is built upon the security principles of protecting the
confidentiality, integrity, availability and safety of your assets, including data.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 48 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
IDENTIFYING A SOLUTION
While there are over 1,200 controls in the SCF’s controls catalog, it is necessary to pare down that catalog to only what is
applicable to that specific ESP’s scope of control (e.g., Managed Service Provider (MSP), Software as a Service (SaaS) provider,
etc.). This step simply involves filtering out the controls in the SCF that are not applicable. This step can also be done within Excel
or within a GRC solution (e.g., SCF Connect). In the end, the result is a tailored set of controls that address the ESP’s specific
aspects of the cybersecurity & privacy controls that it is responsible for or influences.

Now that you have pared down the SCF’s controls catalog to only what is applicable, it is a manual review process to identify the
appropriate level of maturity for each of the controls that would be expected for the ESP. Ideally, the ESP will inherit the same
target maturity level for controls as used throughout the organization. For any deviations, based on contract clauses, budget, time
or other constraints, a risk assessment should be conducted to ensure a lower level of maturity for ESP-specific controls is
appropriate.

USE CASE #4 – DUE DILIGENCE IN MERGERS & ACQUISITIONS (M&A)

It is commonplace to conduct a cybersecurity and data privacy practices assessment as part of Mergers & Acquisitions (M&A)
due diligence activities. The use of a gap assessment against a set of baseline M&A controls (e.g., SCF-B control set) can be used
to gauge the level of risk. In practical terms, this type of maturity-based gap assessment can be used in a few ways:
 Sellers can provide the results from a first- or third-party gap assessment to demonstrate both strengths and weaknesses,
as a sign of transparency.
 Buyers can identify unforeseen deficiencies that can:
o Lead to a lower buying price; or
o Backing out of the deal.

IDENTIFYING THE PROBLEM

Acquiring another entity involves a considerable amount of trust. Cybersecurity M&A due diligence exists to prevent the purchasing
entity from potentially acquiring a class-action lawsuit or multi-million-dollar data protection-related fines (worst case scenarios). M&A
is a game of cat and mouse between the two parties:
 The divesting entity is going to want to “put its best foot forward” and gloss over deficiencies; and
 The acquiring entity wants to know the truth about strengths and weaknesses.

If the acquiring entity only leverages a single framework (e.g., NIST CSF, ISO 27002 or NIST 800-53) for due diligence work, it will
most likely provide a partial picture as to the divesting entity’s cybersecurity and data privacy practices. That is why the SCF-B is
a bespoke set of cybersecurity and data privacy controls that was purposely built for M&A to provide as complete a picture as
possible about the divesting entity’s cybersecurity and data privacy practices.

A control set questionnaire that asks for simple yes, no or not applicable answers is insufficient in M&A due diligence. Failure to
leverage maturity-based criteria will result in the inability to provide critical insights into the actual security posture of the divesting
entity. The C|P-CMM can be used to obtain more nuanced answers to determine (1) if a control is implemented and (2) how mature
the process behind the control is.

CONSIDERATIONS
Referencing back to the C|P-CMM Overview section of this document, L0-1 levels of maturity are identified as being deficient from
a “reasonable person perspective” in most cases. Therefore, acquiring entities need to look at the “capability maturity sweet
spot” between L2-L4 to identify the reasonable people, processes and technologies needed to demonstrate to properly protect
systems, applications, services and data, regardless of where it is stored, transmitted or processed.

Areas of deficiency can be identified and remediation costs determined, which can be used to adjust valuations. Key areas that
affect valuations include, but are not limited to:
 Non-compliance with statutory, regulatory and/or contractual obligations;
 Data protection practices (e.g., privacy);
 IT asset lifecycle management (e.g., unsupported / legacy technologies);
 Historical cybersecurity incidents;
 Risk management (e.g., open items on a risk register or Plan of Action & Milestones (POA&M);
 Situational awareness (e.g., visibility into activities on systems and networks);
 Software licensing (e.g., intellectual property infringement);
 Business Continuity / Disaster Recovery (BC/DR);
 IT / cybersecurity architectures (e.g., deployment of on-premises, cloud and hybrid architectures); and

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 49 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
  IT /cybersecurity staffing competencies.

IDENTIFYING A SOLUTION
The SCF did the hard work by developing the SCF-B control set. The “best practices” that comprise the SCF-B include:
 Trust Services Criteria (SOC 2);
 CIS CSC;
 COBITv5;
 COSO;
 CSA CCM;
 GAPP;
 ISO 27002;
 ISO 31000;
 ISO 31010;
 NIST 800-160;
 NIST Cybersecurity Framework;
 OWASP Top 10;
 UL 2900-1; and
 EU GDPR.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 50 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 9. CYBERSECURITY & DATA PRIVACY RISK MANAGEMENT MODEL (C|P-RMM)
To help simplify risk management practices, ComplianceForge and the SCF Council jointly developed the Cybersecurity & Data
Privacy Risk Management Model (C|P-RMM). The concept of creating the C|P-RMM was to establish an efficient methodology to
identify, assess, report and mitigate risk across the entire organization.

The C|P-RMM:
 Is a free solution that organizations can use to holistically approach that breaks risk management down into seventeen
(17) distinctive steps;
 Exists is to help cybersecurity and data privacy functions create a repeatable methodology to identify, assess, report and
mitigate risk;
 Offers flexibility to report on risk at a control level or aggregate level (e.g., a project, department, domain or organization-
level); and
 Guides the decision to a risk treatment option (e.g., reduce, avoid, transfer or accept).

Based on the applicable statutory, regulatory and contractual obligations that impact the scope of a risk assessment, an
organization is expected to have an applicable set of cybersecurity and data privacy controls to cover those fundamental
compliance obligations. That set of controls identifies the in-scope requirements that must be evaluated to determine what risk
exists. This is generally considered to be a “gap assessment” where the assessor:
 Evaluates those controls based on the entity's Threat Catalog to identify current or potential control deficiencies; and
 Utilize the Risk Catalog to identify the applicable risks, based on the identified control deficiencies.

Therefore, it is vitally important to understand that risks and threats do not exist in a vacuum. If your cybersecurity and data privacy
program is appropriately built, you will have a robust controls framework where risks and threats will map directly to controls.
Why is this?
 Controls are central to managing risks, threats procedures and metrics.
 Risks, threats, metrics and procedures need to map into the controls, which then map to standards and policies.

In risk management, the old adage that “the path to hell is paved with good intentions” is applicable. Often, risk management
personnel are tasked with creating risk assessments and questions to ask without having a centralized set of organization-wide
cybersecurity and data privacy controls to work from. This generally leads to risk teams making up risks and asking questions that
are not supported by the organization’s policies and standards. For example, an organization is an “ISO shop” that operates an
ISO 27002-based Information Security Management System (ISMS) to govern its policies and standards, but its risk team is asking
questions about NIST SP 800-53 or NIST SP 800-171 controls that are not applicable to the organization.

EXPERT INSIGHT (ROGUE RISK MANAGEMENT OPERATIONS): Cybersecurity teams “making up risks” points to a few security
program governance issues:
 If the need for additional controls to cover risks is legitimate, then the organization is improperly scoped and does not
have the appropriate cybersecurity and data privacy controls to address its applicable statutory, regulatory, contractual
or industry-expected practices.
 If the organization is properly scoped, then the risk team is essentially making up requirements that are not supported by
the organization’s policies and standards.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 51 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
The most important concept to understand in cybersecurity and data privacy-related risk management is that the cybersecurity
and IT departments generally do not “own” technology-related risks, since that “risk ownership” primarily resides with Line of
Business (LOB) management. An organization’s cybersecurity and data privacy functions serve as the primary mechanism to
educate those LOB stakeholders on identified risks and provide possible risk treatment solutions. Right or wrong, LOB
management is ultimately responsible to decide how risk is to be handled.

Where the C|P-RMM exists to help cybersecurity and data privacy functions create a repeatable methodology to identify, assess,
report and mitigate risk. This is based on the understanding that the responsibility to approve a risk treatment solution rests with
the management of the LOB/department/team/stakeholder that “owns” the risk. The C|P-RMM is meant to guide the decision to
one of these common risk treatment options:
1. Reduce the risk to an acceptable level;
2. Avoid the risk;
3. Transfer the risk to another party; or
4. Accept the risk.

The C|P-RMM is designed to be an integral tool of an organization’s ability to demonstrate evidence of due diligence and due care.
This not only benefits your organization by having solid risk management practices, but it can also serve as a way to reduce risk
for those who have to initiate the hard discussions on risk management topics.

EXPERT INSIGHT (RISK ACCEPTANCE): It is a common problem for individuals who are directly impacted by risk to simply claim,
“I accept the risk” in a misplaced maneuver to make the risk go away, so that the project/initiative can proceed without having to
first address deficiencies. This is why it is critically important as part of a risk management program to identify the various levels
of management who have the legitimate authority to make risk management decisions. This can help prevent low-level managers
from recklessly accepting risks that should be reserved for more senior management.

RISK MANAGEMENT DISCUSSION PROTECTIONS

If you worry about having to preface risk management discussions with, “Don’t shoot the messenger!” then the C|P-RMM can be
an additional layer of protection for your professional reputation. Where the C|P-RMM benefits security, technology and privacy
personnel is the potential “get out of jail” documentation that quality risk assessments and risk management practices can
provide. Just like with compliance documentation, if risk management discussions are not documented then risk management
practices do not exist.

Before you read further, ask yourself these two (2) questions about your organization and your personal exposure in risk
management:
1. Can you prove that the right people within your organization are both aware of risks and have taken direct responsibility
for mitigating those risks?
2. If there was a breach or incident that is due to identified risks that went unmitigated, where does the “finger pointing” for
blame immediately go to?

Instead of executive leadership hanging blame on the CIO or CISO, quality risk management documentation can prove that
reasonable steps were taken to identify, assess, report and mitigate risk. This type of documentation can provide evidence of due
diligence and due care on the part of the CIO/CISO/CRO, which firmly puts the responsibility back on the management of the
team/department/line of business that “owns” the risk.

Organizations often face conflicting expectations for risk management, based on department-level practices. For example, where
disjointed risk management practices exist, a “Moderate Risk” often has entirely different financial and/or operational impacts
across cybersecurity, IT, legal, finance, HR, operations, etc. The concept of Enterprise Risk Management (ERM) is to apply a
comprehensive, organization-wide approach to risk management practices, where each department operates according to a
similar playbook, where “Moderate Risk” means the same thing across the entire organization. This helps make an “apples to
apples” comparison that can aid in creating a more holistic approach to risk management practices when risk designations are
standardized.

Risk management activities are logical and systematic processes that can be used when making well-informed decisions to
improve effectiveness and efficiency. Proactive risk management activities have these characteristics:
 Integrated into Business As Usual (BAU) activities (e.g., everyday work);
 Focuses on proactive management involvement, rather than reactive crisis management;
 Identifies and helps prepare for what might happen;

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 52 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
  Identifies opportunities to improve performance; and
 Proposes taking action to:
o Avoid or reduce unwanted exposures; and/or
o Maximize opportunities identified.

The articulation of risk management concepts is both an art and science. This requires a clear understanding of certain risk
management terminology:
 Risk Appetite;
 Risk Tolerance; and
 Risk Threshold.

Risk management decisions must be explained in the context of the business, since risk management practices do not operate in
a vacuum. Therefore, it is crucial to understand the environment where risk management practices exist. This also requires a clear
understanding of business planning terminology:
 Mission;
 Vision; and
 Strategy.

From a hierarchical perspective:

 An organization’s risk appetite exists at the corporate level to influence actions and decisions, specifically the
organization’s strategy. The strategy provides prioritization and resourcing constraints to the organization’s various LOB.
 The risk appetite helps define the organization’s risk tolerance to influence actions and decisions at the LOB level. Risk
tolerance influences objectives, maturity targets and resource prioritization.
 Risk thresholds affect actions and decisions at the department and team levels. Risk thresholds influence processes,
technologies, staffing levels and the supply chain (e.g., vendors, suppliers, consultants, contractors, etc.). Defined risk
thresholds provide criteria to assess operational risks that exist in the course of conducting business.

It is acceptable for risk management practices to be:

 Quantifiable (objective);
 Qualifiable (subjective); or
 A hybrid approach that clearly identifies the subjective and object nature of risk analysis practices.

What is important to keep at the forefront of risk management considerations is the material nature of risk, as it pertains to the
organization. Risks that have a material impact include, but are not limited to:
 Confidentiality, Integrity & Availability (CIA) of the organization’s sensitive/regulated data;
 Supply chain security;
 Macroeconomic forces;
 Socio-political changes;
 Statutory / regulatory changes;
 Competitive landscape;
 Diplomatic sanctions (e.g., taxes, customs, embargoes, etc.); and
 Natural / manmade disasters (e.g., pandemics, war, etc.).
BASELINING RISK MANAGEMENT TERMINOLOGY
Risk management involves coordinated activities that optimize the management of potential opportunities and adverse effects.
Proactive risk management activities provide a way to realize potential opportunities without exposing an organization to
unnecessary peril.

The goal of risk analysis is to determine the potential negative implications of an action or situation to determine one (1) of two (2)
decisions:
1. Acceptable Risk: the criteria fall within a range of acceptable parameters; or
2. Unacceptable Risk: The criteria fall outside a range of acceptable parameters.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 53 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
Building upon the graphic listed above, when viewed from a risk appetite perspective, for an organization that wants to follow a
Moderate Risk Appetite, which establishes constraints for allowable and prohibited activities, based on the potential harm to the
organization:

UNDERSTANDING THE DIFFERENCES: THREATS VS VULNERABILITIES VS RISKS

Risks and threats both tie into cybersecurity and data privacy controls, but it is important to understand the differences:
 A risk exists due to the absence of or a deficiency with a control; but
 A threat affects the ability of a control to exist or operate properly.

ComplianceForge published a “threats vs vulnerabilities vs risks” informational graphic that describes the relationship between
these components. That informational graphic is shown below:35

35 Risk vs Threat vs Vulnerability Ecosystem - https://complianceforge.com/content/pdf/guide-risk-vs-threat-vs-vulnerability-ecosystem.pdf

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 54 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
WHAT IS A RISK?
In the context of cybersecurity & data privacy practices, “risk” is defined as:
 Noun: A situation where someone or something valued is exposed to danger, harm or loss.
 Verb: To expose someone or something valued to danger, harm or loss.

In the context of this definition of risk, it is important to define underlying components of this risk definition:
 Danger: state of possibly suffering harm or injury.
 Harm: material / physical damage.
 Loss: destruction, deprivation or inability to use.

WHAT IS A THREAT?
In the context of cybersecurity & data privacy practices, “threat” is defined as:
 Noun: A person or thing likely to cause damage or danger.
 Verb: To indicate impending damage or danger.

UNDERSTANDING THE DIFFERENCES BETWEEN: RISK TOLERANCE VS RISK THRESHOLD VS RISK APPETITE
Key concepts associated with risk management include:
 Risk Appetite: The types and amount of risk, on a broad level, an organization is willing to accept in its pursuit of value. 36
 Risk Tolerance: The level of risk an entity is willing to assume in order to achieve a desired result. 37
 Risk Threshold: Values used to establish concrete decision points and operational control limits to trigger management
action and response escalation.38

36
NIST Glossary for Risk Appetite - https://csrc.nist.gov/glossary/term/risk_appetite
37
NIST Glossary for Risk Tolerance - https://csrc.nist.gov/glossary/term/risk_tolerance
38
NIST Glossary for Thresholds - https://csrc.nist.gov/glossary/term/thresholds

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 55 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
WHAT IS A RISK APPETITE?
A risk appetite is a broad “risk management concept” that is used to inform employees about what is and is not acceptable, in
terms of risk management from an organization's executive leadership team.

A risk appetite does not contain granular risk management criteria and is primarily a “management statement” that is subjective
in nature. Similar in concept to how a policy is a "high-level statement of management intent," an organization's defined risk
appetite is a high-level statement of how all, or certain types of, risk are willing to be accepted.

Examples of an organization stating its risk appetite from basic to more complex statements:
 "[organization name] is a low-risk organization and will avoid any activities that could harm its customers."
 "[organization name] will aggressively pursue innovative solutions through Research & Development (R&D) to provide
industry-leading products and services to our clients, while maintaining a Moderate Risk Appetite. Developing
breakthrough products and services does invite potential risk through changes to traditional supply chains, disruptions to
business operations and changing client demand. Proposed business practices that pose greater than a Moderate Risk
will be considered on a case-by-case basis for financial, operational and legal implications.”

It is important to point out that in many immature risk programs, risk appetite statements are divorced from reality. Executive
leaders mean well when they issue risk appetite statements, but the Business As Usual (BAU) practices routinely violate the risk
appetite. This is often due to numerous reasons that include, but are not limited to:
 Technical debt;
 Dysfunctional management decisions;
 Insecure practices;
 Inadequate funding/resourcing;
 Improperly scoped support contracts (e.g., Managed Service Providers (MSPs), consultants, vendors, etc.); and
 Lack of pre-production security testing.

WHAT IS A RISK TOLERANCE?

Risk tolerance is based on objective criteria, unlike the subjective, conceptual nature of a risk appetite. Defining objective criteria
is a necessary step to be able to categorize risk on a graduated scale. Establishing objective criteria to quantify the impact of a
risk enables risk assessments to leverage that same criteria and assist decision-makers in their risk management decisions (e.g.,
accept, mitigate, transfer or avoid).

From a graduated scale perspective, it is possible to define "tolerable" risk criteria to create five (5) useful categories of risk:
1. Low Risk;
2. Moderate Risk;
3. High Risk;
4. Severe Risk; and
5. Extreme Risk.

There are two (2) objective criteria that go into defining what constitutes a low, moderate, high, severe or Extreme Risk includes:
1. Impact Effect (IE); and
2. Occurrence Likelihood (OL).

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 56 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
The six (6) categories of IE are:
1. Insignificant (e.g., organization-defined little-to-no impact to business operations);
2. Minor (e.g., organization-defined minor impacts to business operations);
3. Moderate (e.g., organization-defined moderate impacts to business operations);
4. Major (e.g., organization-defined major impacts to business operations);
5. Critical (e.g., organization-defined critical impacts to business operations); and
6. Catastrophic (e.g., organization-defined catastrophic impacts to business operations).

The six (6) categories of OL are:

1. Remote possibility (e.g., <1% chance of occurrence);
2. Highly unlikely (e.g., from 1% to 10% chance of occurrence);
3. Unlikely (e.g., from 10% to 25% chance of occurrence);
4. Possible (e.g., from 25% to 70% chance of occurrence);
5. Likely (e.g., from 70% to 99% chance of occurrence); and
6. Almost certain (e.g., >99% chance of occurrence).

There are three (3) general approaches are commonly employed to estimate OL:
1. Relevant historical data;
2. Probability forecasts; and
3. Expert opinion.

An organization's risk tolerance is influenced by several factors that includes, but is not limited to:
 Statutory, regulatory and contractual compliance obligations (including adherence to privacy principles for ethical data
protection practices).
 Organization-specific threats (natural and manmade).
 Reasonably expected industry practices.
 Pressure from competition.
 Executive management decisions.

LOW RISK TOLERANCE

Organizations that would be reasonably expected to adopt a Low Risk Tolerance generally:
 Provide products and/or services that are necessary for the population to maintain normalcy in daily life.
 Are in highly regulated industries with explicit cybersecurity and/or data privacy requirements.
 Store, process and/or transmit highly sensitive/regulated data.
 Are legitimate targets for nation-state actors to disrupt and/or compromise due to the high-value nature of the
organization.
 Have strong executive management support for cybersecurity and data privacy practices as part of “business as usual”
activities.
 Maintain a high level of capability maturity for preventative cybersecurity controls to implement “defense in depth”
protections across the enterprise.
 Have a high level of situational awareness (cybersecurity & physical) that includes its supply chain.
 Have cyber-related liability insurance.

Organizations that are reasonably expected to operate with a Low Risk Tolerance include, but are not limited to:
 Critical infrastructure
 Utilities (e.g., electricity, drinking water, natural gas, sanitation, etc.)
 Telecommunications (e.g., Internet Service Providers (ISPs), mobile phone carriers, Cloud Service Providers (CSPs), etc.)
(high value)
 Transportation (e.g., airports, railways, ports, tunnels, fuel delivery, etc.)
 Technology Research & Development (R&D) (high value)
 Healthcare (high value)
 Government institutions:
o Military
o Law enforcement
o Judicial system
o Financial services (high value)
o Defense Industrial Base (DIB) contractors (high value)

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 57 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
MODERATE RISK TOLERANCE
Organizations that would be reasonably expected to adopt a Moderate Risk Tolerance generally:
 Have executive management support for securing sensitive / regulated data enclaves.
 Are in regulated industries that have specific cybersecurity and/or data privacy requirements (e.g., CMMC, PCI DSS, SOX,
GLBA, RMF, etc.).
 Have “flow down” requirements from customers that require adherence to certain cybersecurity and/or data privacy
requirements.
 Store, process and/or transmit sensitive/regulated data.
 Are legitimate targets for attackers who wish to financially benefit from stolen information or ransom.
 Have cyber-related liability insurance.

Organizations that are reasonably expected to operate with a Moderate Risk Tolerance include, but are not limited to:
 Education (e.g., K-12, colleges, universities, etc.)
 Utilities (e.g., electricity, drinking water, natural gas, sanitation, etc.)
 Telecommunications (e.g., Internet Service Providers (ISPs), mobile phone carriers, etc.)
 Transportation (e.g., airports, railways, ports, tunnels, fuel delivery, etc.)
 Technology services (e.g., Managed Service Providers (MSPs), Managed Security Service Providers (MSSPs), etc.)
 Manufacturing (high value)
 Healthcare
 Defense Industrial Base (DIB) contractors and subcontractors
 Legal services (e.g., law firms)
 Construction (high value)

HIGH RISK TOLERANCE

Organizations that would be reasonably expected to adopt a High Risk Tolerance generally:
 Are in an unregulated industry, pertaining to cybersecurity and/or data privacy requirements.
 Do not store, process and/or transmit sensitive/regulated data.
 Lack management support for cybersecurity and data privacy governance practices.
 Do not have cyber-related liability insurance.

Organizations that may choose to operate with a High Risk Tolerance include, but are not limited to:
 Startups
 Hospitality industry (e.g., restaurants, hotels, etc.)
 Construction
 Manufacturing
 Personal services

SEVERE RISK TOLERANCE

Organizations that would be reasonably expected to adopt a Severe Risk Tolerance generally:
 Are in an unregulated industry, pertaining to cybersecurity and/or data privacy requirements.
 Do not store, process and/or transmit sensitive/regulated data.
 Lack management support for cybersecurity and data privacy governance practices.
 Do not have cyber-related liability insurance.

Organizations that may choose to operate with a High Risk Tolerance include, but are not limited to:
 Startups
 Artificial Intelligence (AI) developers

EXTREME RISK TOLERANCE

Organizations that would be reasonably expected to adopt an Extreme Risk Tolerance generally:
 Are in an unregulated industry, pertaining to cybersecurity and/or data privacy requirements.
 Do not store, process and/or transmit sensitive/regulated data.
 Lack management support for cybersecurity and data privacy governance practices.
 Do not have cyber-related liability insurance.
Organizations that may choose to operate with a High Risk Tolerance include, but are not limited to:
 Startups

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 58 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
  Artificial Intelligence (AI) developers

WHAT IS A RISK THRESHOLD?

Risk thresholds are directly tied to risk tolerance and utilize organization-specific criteria (e.g., acceptable and unacceptable
parameters). These risk thresholds exist between the different levels of risk tolerance (e.g., between Low Risk and Moderate Risk,
between Moderate Risk and High Risk, etc.). By establishing these risk thresholds, it brings the "graduated scale perspective" to
life for risk management practices. Risk thresholds are criteria that are unique to an organization:
 Organization-specific activities / scenarios that could damage the organization’s reputation;
 Organization specific activities / scenarios that could negatively affect short-term and long-term profitability; and
 Organization specific activities / scenarios that could impede business operations.

Risk thresholds are entirely unique to each organization, based on several factors that include:
 Financial stability;
 Management preferences;
 Compliance obligations (e.g., statutory, regulatory and/or contractual); and
 Insurance coverage limits.

WHAT IS MATERIALITY?
The SCF defines materiality as, “A deficiency, or a combination of deficiencies, in an organization’s cybersecurity and/or data
privacy controls (across its supply chain) where it is probable that reasonable threats will not be prevented or detected in a timely
manner that directly, or indirectly, affects assurance that the organization can adhere to its stated risk tolerance.” 39

The intended usage of materiality is meant to provide relevant context, as it pertains to risk thresholds. This is preferable when
compared to relatively hollow risk findings that act more as guidelines than actionable, decision-making criteria. Cybersecurity
materiality is meant to act as a "guard rail" for risk management decisions. A material weakness crosses an organization’s risk
threshold by making an actual difference to the organization, where systems, applications, services, personnel, the organization
and/or third-parties are, or may be, exposed to an unacceptable level of risk.

The SEC, Generally Accepted Accounting Principles (GAAP) and International Financial Reporting Standards (IFRS) lack specificity
in defining the criteria for materiality. Therefore, organizations generally have leeway to define it on their own. The lack of
authoritative definition for materiality is not unique, since the concept of risk appetite, risk tolerance and risk threshold also suffer
from nebulous definitions by statutory and regulatory authorities.

For an item to be considered material, the control deficiency, risk, threat or incident (singular or a combination) generally must
meet one or more of the following criteria where the potential financial impact is: 40
 ≥ 5% of pre-tax income
 ≥ 0.5% of total assets
 ≥ 1% of total equity (shareholder value); and/or
 ≥ 0.5% of total revenue.

This materiality determination can be visualized with this infographic with the callout for publicly traded companies having a
requirement to publicly disclose material cybersecurity incidents: 41

39 SCF Cybersecurity Materiality - https://securecontrolsframework.com/cybersecurity-materiality/

40 Norwegian Research Council - https://snf.no/media/yemnkmbh/a51_00.pdf
41 SEC Cybersecurity Final Rule - https://www.sec.gov/files/rules/final/2023/33-11216.pdf

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 59 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
HISTORICAL CONTEXT FOR CYBERSECURITY & DATA PRIVACY MATERIALITY USAGE
For Governance, Risk Management & Compliance (GRC) practitioners, materiality is often relegated to Sarbanes-Oxley Act (SOX)
compliance. However, the concept of materiality is much broader than SOX and can be applied as part of risk reporting in any type
of conformity assessment. Financial-related materiality definitions focus on investor awareness of third-party practices, not
inwardly looking for adherence to an organization's risk tolerance:
 Per the Security and Exchange Commission (SEC), information is material “to which there is a substantial likelihood that
a reasonable investor would attach importance in determining whether to purchase the security registered.” 42
 Per the International Accounting Standards Board (IASB), information is material, “if omitting, misstating or obscuring it
could reasonably be expected to influence the decisions that the primary users of general purpose financial statements
make on the basis of those financial statements, which provide financial information about a specific reporting entity.”43

In legal terms, “material” is defined as something that is relevant and significant:

 In a lawsuit, "material evidence" is distinguished from totally irrelevant or of such minor importance that the court will
either ignore it, rule it immaterial if objected to, or not allow lengthy testimony upon such a matter.
 A "material breach" of a contract is a valid excuse by the other party not to perform. However, an insignificant divergence
from the terms of the contract is not a material breach.

42 SEC - https://www.sec.gov/comments/265-24/26524-77.pdf
43 IFRS - https://www.ifrs.org/content/dam/ifrs/project/definition-of-materiality/definition-of-material-feedback-statement.pdf

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 60 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
RISK MANAGEMENT OPTIONS
Traditional risk management practices have four (4) options to address identified risk:
1. Reduce the risk to an acceptable level;
2. Avoid the risk;
3. Transfer the risk to another party; or
4. Accept the risk.

In a mature risk program, the results of risk assessments are evaluated with the organization's risk appetite in consideration. For
example, if the organization has a Moderate Risk Appetite and there are several findings in a risk assessment that are High Risk,
then action must be taken to reduce the risk. Accepting a High Risk would violate the Moderate Risk Appetite set by management.
In reality, which leaves remediation, transferring or avoiding as the remaining three (3) options, since accepting the risk would be
prohibited.

PRACTICAL RISK MANAGEMENT EXAMPLE

For an example scenario, a theoretical company is experimenting with Artificial Intelligence (AI) to strengthen its products and/or
services. Its long-standing risk appetite is relatively conservative, where the company draws a hard line that any risk over Moderate
is unacceptable. Additionally, the company has zero tolerance for any activities that could harm its customers (e.g., physically or
financially).

Given the necessary changes to ramp up both talent and technology to put the appropriate solutions in place to meet the
company’s deadlines, there are gaps/deficiencies. When the risk management team assesses the associated risks, the results
identify a range of risks from High to Extreme. The reason for these results is simply due to the higher likelihood of emergent
behaviors occurring from AI that potentially could harm individuals (e.g., catastrophic impact effect). The results were objective
and told a compelling story that there is a realistic chance of significant damage to the company’s reputation and financial
liabilities from class action lawsuits.

With those results that point to risks exceeding the organization’s risk appetite, it is a management decision on how to proceed.
What does the CEO / Board of Directors (BoD) do?
 Dispense with its long-standing risk appetite for this specific project so that a potentially lucrative business opportunity
can exist?
 Is the AI project cancelled due to the level of risk?
 If the CEO/BoD proceeds with accepting the risk, is it violating its fiduciary duties, since it is accepting risk that it
previously deemed unacceptable? Additionally, would it be considered negligent to accept high, severe or Extreme Risk
(e.g., would a rational individual under similar circumstances make the same decision?)?

These are all very real topics that need to be considered and how risk is managed has significant legal and financial implications.

SUMMARIZING THE INTEGRATION OF RISK MANAGEMENT & BUSINESS PLANNING

These key concepts of how risk appetite, risk tolerance and risk thresholds interact with strategic, operational and tactical actions
and decisions can be visualized in the following graphic:44
 At the strategic layer, where corporate-level actions and decisions are made, the organization’s risk appetite is defined.
The scope of the risk appetite can be organization-wide or compartmentalized to provide enhanced granularity.
 At the operational level, where Line of Business (LOB)-level actions and decisions are made, the organization’s risk
tolerance is put into practice. The organization’s risk tolerance is defined by its established risk appetite.
 At the tactical level, where department / team-level actions and decisions are made, the organization’s risk thresholds
are used to provide criteria to assess operational risk. That operational risk must adhere to the organization’s risk
tolerance and therefore, its risk appetite.

44Strategic vs Operational vs Tactical Risk Management - https://complianceforge.com/content/Risk-Appetite-vs-Risk-Tolerance-vs-Risk-Thresholds.pdf

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 61 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 [graphic download - https://complianceforge.com/content/Risk-Appetite-vs-Risk-Tolerance-vs-Risk-Thresholds.pdf]

RISK MANAGEMENT: STRATEGIC CONSIDERATIONS

At this level, corporate-level actions and decisions define the strategic direction of the organization and its approach to risk
management practices:

MISSION
 Influences the vision of the organization.
 Requires a strategy to accomplish.

VISION
 Inspires personnel to achieve the mission.

STRATEGY
 Implements the mission.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 62 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
  Quantifies “downstream” objectives for Lines of Business (LOB)
 Influences the organization’s risk appetite.

COMPLIANCE OBLIGATIONS
 Affect the strategy.
 Affect resource prioritization.

RISK APPETITE
 Must support the organization’s strategy.
 Defines the organization’s risk tolerance.

RISK MANAGEMENT: OPERATIONAL CONSIDERATIONS

At this level, Line of Business (LOB)-level actions and decisions define the operational management of the organization:

LINE OF BUSINESS (LOB) OBJECTIVES

 Are quantified and prioritized by the organization’s strategy.
 Influence necessary capability maturity targets.
 Quantifies “downstream” objectives at the department / team level.

CAPABILITY MATURITY TARGETS

 Are influenced by LOB objectives.
 Influences resource prioritization.
 Affects:
o Processes that are implemented to achieve objectives;
o Technologies used to support operations;
o Staffing levels at the department / team level; and
o Supply chain quality & security (e.g., vendors, suppliers, contractors, consultants, etc.).

RESOURCE PRIORITIZATION
 Creates operational risks.
 Affects:
o Processes that are implemented to achieve objectives;
o Technologies used to support operations;
o Staffing levels at the department / team level; and
o Supply chain quality & security (e.g., vendors, suppliers, contractors, consultants, etc.).

RISK TOLERANCE
 Is defined by the organization’s risk appetite.
 Influences LOB objectives.
 Quantifies the organization’s risk thresholds.

RISK MANAGEMENT: TACTICAL CONSIDERATIONS

At this level, department / team-level actions and decisions define the tactics used for day-to-day operations:

DEPARTMENT / TEAM OBJECTIVES

 Are quantified and prioritized by LOB objectives.
 Affect:
o Processes that are implemented to achieve objectives;
o Technologies used to support operations;
o Staffing levels at the department / team level; and
o Supply chain quality & security (e.g., vendors, suppliers, contractors, consultants, etc.).

PROCESSES
 Are affected by:
o Department / team objectives;
o Capability maturity targets; and

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 63 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 o Resource prioritization.
 Create operational risks.

TECHNOLOGIES
 Are affected by:
o Department / team objectives;
o Capability maturity targets; and
o Resource prioritization.
 Create operational risks.

STAFFING
 Are affected by:
o Department / team objectives;
o Capability maturity targets; and
o Resource prioritization.
 Creates operational risks.

SUPPLY CHAIN
 Are affected by:
o Department / team objectives;
o Capability maturity targets; and
o Resource prioritization.
 Creates operational risks.

RISK THRESHOLDS
 Provide criteria to assess operational risks.
 Affect:
o Processes that are implemented to achieve objectives;
o Technologies used to support operations;
o Staffing levels at the department / team level; and
o Supply chain quality & security (e.g., vendors, suppliers, contractors, consultants, etc.).

OPERATIONAL RISK
 Is assessed against the organization’s risk thresholds.
 Must adhere to the organization’s risk tolerance, where the organization has four (4) options to address identified risks:
1. Reduce the risk to an acceptable level;
2. Avoid the risk;
3. Transfer the risk to another party; or
4. Accept the risk.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 64 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
USING THE C|P-RMM
The C|P-RMM addresses risk management from how you start building a risk management program through the ongoing risk
management practices that are expected within your organization.

[graphic download - https://securecontrolsframework.com/content/SCF-Risk-Management-Model-Calculations.pdf]

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 65 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
The C|P-RMM is broken down into seventeen (17) primary steps:

C|P-RMM STEP 1. IDENTIFY RISK MANAGEMENT PRINCIPLES

It is necessary to identify one or more risk management principles that will form the basis of how the entity approaches its risk
management processes. The alignment with risk management principles must support the entity's policies and standards for risk
management objectives.

Common risk frameworks include:

 NIST SP 800-37;
 ISO 31010;
 COSO 2019; and
 OMB A-123.

C|P-RMM STEP 2. IDENTIFY, IMPLEMENT & DOCUMENT CRITICAL DEPENDENCIES.

This is a multi-step process that involves identifying, implementing and documenting the critical dependencies that are necessary
to legitimately identify, assess and manage risk:

C|P-RMM STEP 2A. RISK MANAGEMENT DEPENDENCIES

It is vitally important to establish the fundamental risk management dependencies. These dependencies need to be standardized
entity-wide or the organization will be hampered by conflicting definitions and expectations:
 Define the “acceptable risk” threshold for your entity;
 Define risk Occurrence Likelihood (OL);
 Define risk Impact Effect (IE);
 Define risk levels;
 Define the various levels of entity management who can “sign off” on risk levels; and
 Establish a Plan of Action & Milestones (POA&M), risk register or some other method to track risks from identification
through remediation.

C|P-RMM STEP 2B. TECHNOLOGY DEPENDENCIES

In order to support risk management processes, it is necessary to establish the technology dependencies that affect risk
management decisions:
 Maintain accurate and current hardware and software inventories;
 Maintain accurate and current network diagrams;
 Maintain accurate and current Data Flow Diagrams (DFD);
 Document the technology dependencies that affect operations (e.g., supporting systems, applications and services);
 Consistent application of cybersecurity and data privacy controls across the organization; and
 Maintain situational awareness of technology-related assets across the organization (e.g., vulnerability scanning & patch
management levels).

C|P-RMM STEP 2C. BUSINESS DEPENDENCIES

In order to support risk management processes, it is necessary to establish the business dependencies that affect risk
management decisions:
 A data classification scheme needs to exist that is consistent across the organization, including an understanding of what
constitutes the “crown jewels” of that require enhanced data protection requirements;
 Business leadership needs to dictate the technological support it requires for business operations to function properly.
This enables technology and security leadership to define “what right looks like” from a necessary maturity level for
cybersecurity and data privacy controls;
 A multi-discipline effort is needed to establish and maintain a Supply Chain Risk Management (SCRM) program that
governs the organization’s supply chain. This requires legal, procurement, security, privacy and Line of Business (LOB)
involvement;
 Policies and standards must be uniformly applied across the organization;
 LOB management needs to ensure its project teams properly document business practices and provide that information
to technology, cybersecurity and data privacy personnel in order to ensure a shared understanding of business practices
and requirements exists. This information is necessary to build out a System Security & Privacy Plan (SSPP); and
 Since the LOB “owns” risk management decisions, the organization needs to ensure that those individuals in roles that
make risk management decisions are competent and appropriately trained to make risk-related decisions.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 66 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
C|P-RMM STEP 3. FORMALIZE RISK MANAGEMENT PRACTICES
Document a formal Risk Management Program (RMP) that supports the entity's policies & standards. The RMP is meant to:
 Reference the most appropriate industry frameworks to provide a comprehensive and holistic approach to identifying,
managing and remediating risks;
 Incorporate both cybersecurity and data privacy concepts in all stages of asset and data lifecycles; and
 Document the organization’s program-level guidance that defines the "who, what, why, when & how" about the
organization's specific risk management practices.

C|P-RMM STEP 4. ESTABLISH A RISK CATALOG

It is necessary to develop a risk catalog that identifies the possible risk(s) that affect the entity. The use case for the risk catalog is
to identify the applicable risk(s) associated with a control deficiency. (e.g., if the control fails, what risk(s) is the organization
exposed to?). In the context of the C|P-RMM, “risk” is defined as:
Noun: A situation where someone or something valued is exposed to danger, harm or loss.
Verb: To expose someone or something valued to danger, harm or loss.

In the context of this definition of risk, it is important to define underlying components of this risk definition:
 Danger: state of possibly suffering harm or injury
 Harm: material / physical damage
 Loss: destruction, deprivation or inability to use

The SCF’s Risk Catalog thirty-nine (39) risks.

C|P-RMM STEP 5. ESTABLISH A THREAT CATALOG

It is necessary to develop a threat catalog that identifies possible natural and man-made threats that affect the entity's
cybersecurity & data privacy controls. The use case for the threat catalog is to identify applicable natural and man-made threats
that affect control execution. (e.g., if the threat materializes, will the control function as expected?) In the context of the C|P-RMM,
“threat” is defined as:
Noun: A person or thing likely to cause damage or danger.
Verb: To indicate impending damage or danger.

This threat catalog is sorted by natural and man-made threats:

C|P-RMM STEP 5A. NATURAL THREATS

Natural threats are caused by environmental phenomena that have the potential to impact individuals, processes, organizations
or society, as a whole. The SCF’s Threat Catalog contains fourteen (14) natural threats.

C|P-RMM STEP 5B. MANMADE THREATS

Manmade threats are caused by an element of human intent, negligence or error, or threat of violence that have the potential to
impact individuals, processes, organizations or society, as a whole. The SCF’s Threat Catalog contains twenty-three (23)
manmade threats.

C|P-RMM STEP 6. ESTABLISH A CONTROLS CATALOG

It is necessary to develop a catalog of cybersecurity and data privacy
controls that addresses the organization's applicable statutory,
regulatory and contractual obligations. Risks used by the organization
as part of risk analysis processes must map to the organization's
existing cybersecurity & data privacy controls. Ideally, the controls are
weighted since not all cybersecurity & data privacy controls are equal,
in terms of impact or consequence.
To assist in this process, it is helpful for the organization to categorize
its applicable controls according to “must have” vs “nice to have”
requirements: 45
 Minimum Compliance Requirements (MCR) are the absolute
minimum requirements that must be addressed to comply
with applicable laws, regulations and contracts.

45 Integrated Controls Management (ICM) model - http://integrated-controls-management.com/

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 67 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
  Discretionary Security Requirements (DSR) are tied to the organization’s risk appetite since DSR are “above and beyond”
MCR, where the organization self-identifies additional cybersecurity and data protection controls to address voluntary
industry practices or internal requirements, such as findings from internal audits or risk assessments.

Secure and compliant operations exist when both MCR and DSR are implemented and properly governed:
 MCR are primarily externally-influenced, based on industry, government, state and local regulations. MCR should never
imply adequacy for secure practices and data protection, since they are merely compliance-related.
 DSR are primarily internally-influenced, based on the organization’s respective industry and risk tolerance. While MCR
establishes the foundational floor that must be adhered to, DSR are where organizations often achieve improved
efficiency, automation and enhanced security.

The combination of MCR and DSR equate to an organization’s Minimum Security Requirements (MSR), which define the “must
have” and “nice to have” requirements for PPTDF in one control set. It defines the Minimum Viable Product (MVP) technical and
business requirements from a cybersecurity and data privacy perspective. In short, the MSR can be considered to be an
organization’s IT General Controls (ITGC), which establishes the basic controls that must be applied to systems, applications,
services, processes and data throughout the enterprise. ITGC provides the foundation of assurance for an organization’s decision
makers. ITGC enables an organization’s governance function to define how technologies are designed, implemented and
operated.

C|P-RMM STEP 7. DEFINE CAPABILITY MATURITY MODEL (CMM) TARGETS

It is necessary for an entity to define “what right looks like” for the level of maturity it expects for deployed cybersecurity and data
privacy controls. This is generally defined by aligning with a Capability Maturity Model (CMM). While there are several to choose
from, the SCF’s Cybersecurity & Data Privacy Capability Maturity Model (C|P-CMM) contains control-level criteria for each of the
levels of the maturity model.

Maturity model criteria should be used by the organization as the benchmark to evaluate cybersecurity and data privacy controls.

C|P-RMM STEP 8. PERFORM RISK ASSESSMENTS

With the previous steps addressed, an assessor will leverage those deliverables (e.g., Risk Management Program (RMP), threat
catalog, risk catalog, controls catalogs, etc.) to implement a functional capability to assess risk across the entity. That
documented assessment criteria from the previous steps exist to guide the assessor when performing risk assessments.

Assessing risks in the context of the RMS applies to various assessment scenarios:
 Cybersecurity Risk Assessment;
 Third-Party Risk Assessment;
 Data Protection Impact Assessment (DPIA);
 Business Impact Assessment (BIA); and
 Privacy Impact Assessment (PIA).
There are three (3) levels of rigor for a risk assessment:
1. Standard;
2. Enhanced; and
3. Comprehensive.

The definition of each assessment method includes types of objects to which the method can be applied. In addition, the
application of each method is described in terms of the attributes of depth and coverage.
 The depth attribute addresses the rigor and level of detail of the assessment.
 The coverage attribute addresses the scope or breadth of the assessment.

C|P-RMM STEP 8A. RISK ASSESSMENT LEVEL 1: STANDARD RIGOR (MINIMUM ASSURANCE)
Standard rigor assessments provide a level of understanding of the administrative, technical and physical cybersecurity and/or
data protection measures necessary for determining whether the applicable controls are:
1. Implemented; and
2. Free of obvious errors.

Standard rigor represents sufficient due care in the evaluation of cybersecurity and/or data protection controls. Standard rigor is
appropriate for the Manual Point In Time (MPIT) assessment methodology that:
1. Is relevant to a specific point in time (time at which the controls were evaluated); and

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 68 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 2. Relies on the manual review of artifacts to derive a finding.

C|P-RMM STEP 8B. RISK ASSESSMENT LEVEL 2: ENHANCED RIGOR (MODERATE ASSURANCE)
Enhanced rigor assessments provide a level of understanding of the administrative, technical and physical cybersecurity and/or
data protection measures necessary for determining whether:
1. The applicable controls are:
a. Implemented; and
b. Free of obvious/apparent errors; and
2. There are increased grounds for confidence that the applicable controls are:
a. Implemented correctly; and
b. Operating as intended.

Enhanced rigor is appropriate for the Automated Point In Time (APIT) assessment methodology that utilizes automation to
augment a traditional assessment methodology, where AAT is used to compare the desired state of conformity versus the current
state via machine-readable configurations and/or assessment evidence:
1. Is relevant to a specific point in time (time at which the controls were evaluated);
2. In situations where technology cannot evaluate evidence, evidence is manually reviewed; and
3. The combined output of automated and manual reviews of artifacts is used to derive a finding.

C|P-RMM STEP 8C. RISK ASSESSMENT LEVEL 3: COMPREHENSIVE RIGOR (HIGH ASSURANCE)
Comprehensive rigor assessments provide a level of understanding of the administrative, technical and physical cybersecurity
and/or data protection measures necessary for determining:
1. Whether the applicable controls are:
a. Implemented; and
b. Free of obvious/apparent errors;
2. Whether there are further increased grounds for confidence that the applicable controls are:
a. Implemented correctly; and
b. Operating as intended on an ongoing and consistent basis; and
3. There is support for continuous improvement in the effectiveness of the applicable controls.

Comprehensive rigor is appropriate for the Automated Evidence with Human Review (AEHR) assessment methodology that is
used for ongoing, continuous control assessments:
1. AAT continuously evaluates controls by comparing the desired state of conformity versus the current state through
machine-readable configurations and/or assessment evidence; and
2. Recurring human reviews:
a. Evaluate the legitimacy of the results from automated control assessments; and
b. Validate the automated evidence review process to derive a finding.

C|P-RMM STEP 9. ESTABLISH THE CONTEXT FOR ASSESSING RISKS

Now that a methodology exists to assess risk, it is necessary for the assessor to establish the context of the Cybersecurity & Data
Privacy Risk Environment (SPRE). The SPRE is the overall operating environment that is in scope for the risk assessment. This is
where applicable threats, risks and vulnerabilities affect the entity’s protection measures.

An assessor can generally find this information in a well-documented System Security & Privacy Plan (SSPP). If the scoping is
incorrect, the context will likely also be incorrect, which can lead to a misguided and inaccurate risk assessment.

SPRE Context SSPP Component

General description & purpose
Applicable statutory, regulatory & contractual requirements
Background Information Applicable contracts
Stakeholders (internal & external)
Unique data protection considerations
Hardware & software in use
System Environment
Geolocation considerations
Description
Identity & Access Management (IAM)

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 69 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 Network boundaries
Supply chain overview
Ongoing maintenance & support plan

Without specific statutory, regulatory or contractual scoping instructions, the organization should leverage the Unified Scoping
Guide (USG) as the basis for scoping sensitive and/or regulated data. 46

C|P-RMM STEP 10. CONTROLS GAP ASSESSMENT

Based on the applicable statutory, regulatory and contractual obligations that impact the SPRE, the entity is expected to have an
applicable set of controls to cover those needs. That set of controls identifies the in-scope requirements that must be evaluated
to determine what risk exists. This is generally considered to be a “gap assessment” where the assessor:
 Evaluates those controls based on the entity's Threat Catalog to identify current or potential control deficiencies; and
 Utilize the Risk Catalog to identify the applicable risks, based on the identified control deficiencies.

Whenever possible, Assessment Objectives (AOs) need to be used to assess a control. Per the NIT Glossary, an AO is “a set of
determination statements that expresses the desired outcome for the assessment of a security control, privacy control, or control
enhancement.” There may be one or more AOs assigned to a control and all AOs are expected to be satisfied to legitimately be
able to conform to the intent of the control.

C|P-RMM STEP 11. ASSESS CONTROLS TO DETERMINE FINDINGS

When the control deficiencies are identified, the assessor must utilize an entity-accepted method to assess the risk in the most
objective method possible. Methods for assessing a control for deficiencies is generally defined as either:
 Qualitative;
 Semi-Qualitative; or
 Quantitative.

In most cases, it is not feasible to have an entirely quantitative assessment, so assessments should be expected to include semi-
qualitative or qualitative aspects. There are multiple methods to assess and calculate risk. The C|P-RMM simplifies risk
management practices by utilizing a form of risk matrix that takes Occurrence Likelihood (OL) and Impact Effect (IE) into account
to determine the risk categorization.

When a control is assessed, the result is referred to as a finding. Findings are not designed to have a specific “score” associated
with the evaluation of a control. Its value is in the subjective status associated with the implementation of the control. These

46 Unified Scoping Guide (USG) - https://complianceforge.com/content/pdf/unified-scoping-guide-usg.pdf

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 70 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
findings are useful for the Report on Conformity (ROC), or whatever you want to call the risk assessment report, to summarize the
findings to the organization’s management.

The four (4) categories of findings are:

1. Satisfactory;
2. Not Applicable;
3. Alternative Control; and
4. Deficient.

C|P-RMM STEP 11A. SATISFACTORY

Positive finding. Appropriate evidence of due diligence and due care exists to demonstrate the design and/or operation of an
organization’s cybersecurity and/or data protection control satisfactorily meets all applicable Assessment Objectives (AOs) that
determine if the intent of the control is achieved.

C|P-RMM STEP 11B. NOT APPLICABLE

Neutral finding. Appropriate evidence demonstrates the control is not applicable, due to applicable business practices and/or
technical implementation.

C|P-RMM STEP 11C. ALTERNATIVE CONTROL

Positive finding. Appropriate evidence of due diligence and due care exists to demonstrate the design and/or operation of an
organization’s cybersecurity and/or data protection control satisfactorily meets all applicable AOs that determine if the intent of
the control is achieved.

C|P-RMM STEP 11D. DEFICIENT

Negative finding. A “deficiency” exists when the design and/or operation of an organization’s cybersecurity and/or data protection
control fails to meet one of more AO that determines if the intent of the control is achieved.

A deficiency would fail to reasonably prevent or detect a threat in a timely manner.

 A design-related deficiency exists when a control fails to meet the control objective, so even if that control operates as it
was designed, the operation of that control would fail to satisfy one or more AOs.
 An operation-related deficiency exists when a control does not operate as it was designed.

EXPERT INSIGHT (CONTROL ASSESSMENTS): I the context of control assessments, a designation of:
 Satisfactory is positive, where the assessment criteria are met;
 N/A is neutral, where the control, or AO, does not apply;
 Alternative Control is neutral, where another control, or controls, is/are designated as sufficiently reducing the risk(s)
associated with the control; and
 Deficient is negative, where the assessment criteria are not met;

There are multiple methods to actually assess and calculate risk. The C|P-RMM leverages work done in this area by
ComplianceForge’s Risk Management Program (RMP) to simplify risk management practices.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 71 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
C|P-RMM STEP 12. PRIORITIZE IDENTIFIED DEFICIENCIES
Once a deficiency with a control is identified, it is necessary to determine the level of urgency that should be applied to it. Findings
need to be categorized by one of the following levels of prioritization:
 Emergency;
 Elevated; or
 Standard.

The organization’s risk documentation methodology should utilize one or more of the following options:
 Risk Register;
 Plan of Action & Milestones (POA&M);
 Risk Assessment Report;
 System Security & Privacy Plan (SSPP); or
 Another documentation option of your choosing.

C|P-RMM STEP 13. CALCULATING RISK

Risk can be calculated at a single control or a summary of multiple controls. The C|P-RMM makes it possible to categorize risk
into a set of pre-defined levels of risk that result from an intersection of

. The C|P-RMM leverages the following five (5) categories of risk:

1. Low;
2. Moderate;
3. High;
4. Severe; and
5. Extreme.

Before a risk report can be documented, it is very important to clarify if the results of the assessment are “inherent risk” or
“residual risk” since those have entirely different meanings and implications. Some people want to see both inherent and residual
risk, while some people just want to be presented with residual risk. That is why it is important to understand what story the risk
scores tell:

 INHERENT RISK: The Occurrence Likelihood (OL), in combination with the Impact Effect (IE) will provide the "inherent
risk" score. This is considered a raw or unmitigated risk score. It is important to note that inherent risk does not take into
account any control weighting, the maturity of implemented controls or any other mitigating factors.

 RESIDUAL RISK: To understand the "residual risk" that takes into account control weighting, the maturity of implemented
controls and other mitigating factors, it requires expanding upon inherent risk calculations. To identify the residual risk
score, OL is calculated by IE, Control Weighting (CW), Maturity Level (ML) and Mitigating Factors (MF).

C|P-RMM STEP 14. RISK DETERMINATION: REPORT ON CONFORMITY (ROC)

Risk management requires educating stakeholders for situational awareness and decision-making purposes. There are many
options and formats available to report, but this can be considered a Report on Conformity (ROC). The reason for this is a risk
assessment fundamentally is evaluating if an organization’s cybersecurity and data privacy practices support its stated risk
tolerance.

This approach can be summarized by reporting to the organization’s management on the “health” of the assessed controls by one
of the following four (4) risk determinations:
1. Strictly Conforms;
2. Conforms;
3. Significant Deficiency; or
4. Material Weakness.

C|P-RMM STEP 14A. STRICTLY CONFORMS

This is a positive outcome and indicates that at a high-level, the organization’s cybersecurity and data privacy practices conform
to its selected cybersecurity and data privacy practices. Strictly Conforms means:
 The organization/LOB can demonstrate Strict Conformity with its selected cybersecurity and/or data protection controls,

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 72 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 where one hundred percent (100%) of the assessed controls have reasonable evidence to conclude:
o The controls are met and operational;
o Any control designated as Not Applicable (N/A) is validated as such by the assessor; and/or
o Where applicable, compensating controls are validated by the assessor as being:
 Applicable;
 Reasonable; and
 Implemented and operating properly; and
 Assessed controls provide reasonable assurance that the organization’s/LOB’s cybersecurity and data protection
program provides adequate security, where it:
o Adheres to a defined and documented risk tolerance;
o Mitigates material cybersecurity and/or data protection risks;
o Is designed to detect and protect against material cybersecurity and/or data protection threats; and
o Is prepared to respond to material incidents.

Strictly Conforms is a statement to the organization’s management that sufficient evidence of due care and due diligence exists
to assure that the organization’s stated risk tolerance can be achieved.

C|P-RMM STEP 14B. CONFORMS

This is a positive outcome and indicates that at a high-level, the organization’s cybersecurity and data privacy practices conform
to its selected cybersecurity and data privacy practices. Conforms means:
 The organization/LOB can demonstrate Conformity with its selected cybersecurity and/or data protection controls, where
at least eighty percent (80%) of the assessed controls have reasonable evidence to conclude:
o The controls are met and operational;
o Any control designated as Not Applicable (N/A) is validated as such by the assessor; and/or
o Where applicable, compensating controls are validated by the assessor as being:
 Applicable;
 Reasonable; and
 Implemented and operating properly; and
 Any assessed control deficiency is not material to the organization’s/LOB’s cybersecurity and data protection program;
and
 Assessed controls provide reasonable assurance that the organization’s/LOB’s cybersecurity and data protection
program provides adequate security, where it:
o Adheres to a defined and documented risk tolerance;
o Mitigates material cybersecurity and/or data protection risks;
o Is designed to detect and protect against material cybersecurity and/or data protection threats; and
o Is prepared to respond to material incidents.

Conforms is a statement to the organization’s management that sufficient evidence of due care and due diligence exists to assure
that the organization’s stated risk tolerance can be achieved.

C|P-RMM STEP 14C. SIGNIFICANT DEFICIENCY

This is a negative outcome and indicates the organization was unable to demonstrate conformity with its selected cybersecurity
and data privacy practices, due to systematic problems. Significant Deficiency means:
 The organization/LOB can demonstrate limited conformity with its selected cybersecurity and/or data protection controls
due to a systemic problem within the organization’s cybersecurity and data protection program, where:
o At least seventy percent (70%), but less than eighty percent (80%), of the assessed controls have reasonable
evidence to conclude:
 The controls are met and operational;
 Any control designated as N/A is validated as such by the assessor; and/or
 Where applicable, compensating controls are validated by the assessor as being:
• Applicable;
• Reasonable; and
• Implemented and operating properly;
 Any assessed control deficiency is not material to the organization's cybersecurity and data protection program;
 Assessed controls do not provide reasonable assurance that the organization’s cybersecurity and data protection
program provides adequate security, where it:
o Adheres to a defined and documented risk tolerance;

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 73 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 o Mitigates material cybersecurity and/or data protection risks;
o Is designed to detect and protect against material cybersecurity and/or data protection threats; and
o Is prepared to respond to material incidents; and
 The organization’s cybersecurity and data protection program:
o Has systemic problems inherent in the overall function of a team, department, project, application, service
and/or vendor rather than a specific, isolated factor; and
o Requires implementing limited changes to personnel, technology and/or practices to correct the design and
implementation of deficient cybersecurity and/or data protection controls.

Significant Deficiency is a statement to the organization’s management that insufficient evidence of due care and due diligence
exists to assure that the organization’s stated risk tolerance is achieved, due to a systemic problem in the cybersecurity and/or
privacy program.

In the context of a significant deficiency, a systemic problem is a consequence of issues inherent in the overall function (e.g.,
team, department, project, application, service, vendor, etc.), rather than a specific, isolated factor. Systemic errors may require
changing the structure, personnel, technology and/or practices to remediate the significant deficiency.

C|P-RMM STEP 14D. MATERIAL WEAKNESS

This is a negative outcome and indicates the organization is unable to demonstrate conformity with its selected cybersecurity and
data privacy practices, due to deficiencies that make it probable that reasonable-expected threats will not be prevented or
detected in a timely manner that directly, or indirectly, affects assurance that the organization can adhere to its stated risk
tolerance. Material Weakness means:
 The organization/LOB cannot demonstrate conformity with its selected cybersecurity and/or data protection controls due
to deficiencies that make it probable that reasonably expected threats will not be promptly detected or prevented, where:
o One (1), or more, material controls is/are deficient; and/or
o Less than seventy percent (70%) of the assessed controls have reasonable evidence to conclude:
 The controls are met and operational;
 Any control designated as N/A is validated by the assessor and confirmed as such; and/or
 Where applicable, compensating controls are validated by the assessor as being:
• Applicable;
• Reasonable; and
• Implemented and operating properly;
 Assessed controls do not provide reasonable assurance that the organization’s cybersecurity and data protection
program adequately:
o Adheres to a defined and documented risk tolerance;
o Mitigates material cybersecurity and/or data protection risks; and/or
o Possesses the capability to:
 Detect and protect against material cybersecurity and/or data protection threats; and/or
 Respond to material incidents; and
 The organization's cybersecurity and data protection program:
o Cannot perform its stated mission; and
o Drastic changes to people, processes and/or technologies are required to remediate the deficiencies.

Material Weakness is a statement to the organization’s management that (1) the cybersecurity and/or privacy program is
incapable of successfully performing its stated mission and (2) drastic changes to people, processes and/or technology are
necessary to remediate the findings.

C|P-RMM STEP 15. IDENTIFY THE APPROPRIATE MANAGEMENT AUDIENCE

It is critically important that as part of an entity’s program to manage risk that various levels of management are identified with
varying authority, each with a pre-described ability to make risk management decisions. This helps prevent low-level managers
from recklessly accepting risks that should be reserved for more senior management. A common tiered structure for risk
management decisions includes:
 Line Management;
 Senior Management;
 Executive Management; and
 Board of Directors.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 74 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
The organization’s RMP defines the specific risk authority that roles have to make risk management decisions.

C|P-RMM STEP 16. MANAGEMENT DETERMINES RISK TREATMENT

Risk management is a management decision:
 Cybersecurity and IT generally do not “own” identified risk.
 The ultimate responsibility is on the management structure of the team/department/LOB that “owns” the business
process or technology that is in use.

Common risk treatment options include:

 Reduce the risk to an acceptable level;
 Avoid the risk;
 Transfer the risk to another party; and
 Accept the risk.

C|P-RMM STEP 17. IMPLEMENT & DOCUMENT RISK TREATMENT

When managing risk, it should be kept as simple as possible. Realistically, risk treatment is either “open” or “closed” but it can
sometimes be useful to provide more granularity into open items to assist in reporting on risk management activities:
 Open (unacceptable risk);
 Open (acceptable risk); and
 Closed.

CALCULATING RISK: INHERENT RISK VS RESIDUAL RISK

It is possible to use a straightforward method to calculate risk using C|P-RMM. Both Inherent Risk & Residual Risk map into the
C|P-RMM Risk Matrix (graphic shown below):
 For Inherent Risk, find the cell where Occurrence Likelihood (OL) intersects Impact Effect (IE) to determine the risk level.
 For Residual Risk, utilize the calculated Residual Risk values to determine the corresponding risk level.

[graphic download - https://securecontrolsframework.com/content/SCF-Risk-Management-Model-Calculations.pdf]

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 75 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
C|P-RMM CALCULATIONS STEP 1: CALCULATE THE INHERENT RISK
To determine the inherent risk, calculate the Occurrent Likelihood (OL) by the Impact Effect (IE).

C|P-RMM CALCULATIONS STEP 2: ACCOUNT FOR CONTROL WEIGHTING

Not all cybersecurity and data privacy controls are equal, so it is important to apply weighting to the importance of controls. The
SCF contains pre-defined control weightings that can be edited for an entity’s unique requirements. This Control Weighting (CW)
is multiplied by the inherent risk score from Step 1.

C|P-RMM CALCULATIONS STEP 3: ACCOUNT FOR MATURITY LEVEL TARGETS

The next step is meant to determine a weighted maturity score that takes control maturity into account. The more mature a control
is, the greater the risk should be reduced. Maturity Level (ML) is multiplied by the value determined in Step 2.

C|P-RMM CALCULATIONS STEP 4: ACCOUNT FOR MITIGATING FACTORS TO DETERMINE RESIDUAL RISK
The final step is to account for Mitigating Factors (MF), which can be compensating controls or other process/technology
considerations that mitigate risk, specific to the identified threats.

The end calculation to determine residual risk is: OL * IE * CW * ML * MF

Leveraging the by ComplianceForge’s Risk Management Program (RMP) structure, it is straightforward to translate the calculated
value of the residual risk score into a user-friendly risk category:

Risk Category Range

Low 0 <= 36
Moderate >36 <= 108
High >108 <= 198
Severe >198 <= 288
Extreme >288 <= 360

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 76 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 10. SCF CYBERSECURITY & DATA PROTECTION ASSESSMENT STANDARDS (CDPAS)
The Cybersecurity & Data Protection Assessment Standards (CDPAS) is a cohesive, consistent set of standards for performing
cybersecurity and data protection-related Third Party Assessment, Attestation and Certification Services (3PAAC Services). 47 By
following the Cybersecurity & Data Protection Assessment Standards (CDPAS) approach, cybersecurity and data protection
practitioners can improve the currently disjointed approach used to perform assessments of cybersecurity and/or data protection
controls. The CDPAS is a “standard” that normalizes third-party assessment practices.

[CDPAS download – https://securecontrolsframework.com/content/cdpas.pdf]

CDPAS PURPOSE
The CDPAS exists to provide performance standards for cybersecurity and data protection-related 3PAAC Services.

CDPAS INTENT
The CDPAS is not “one-size-fits-all.” Instead, the guidance throughout this document should be adopted and tailored to the
unique size, resources and risk circumstances of each OSA and 3PAO. The CDPAS can be modified, or augmented, with OSA-
specific requirements, policies, or other compliance obligations due to statutory, regulatory and/or contractual requirements.
This publication empowers OSAs to develop cybersecurity and data protection assessment strategies tailored to their specific
mission, business needs, threats and operational environments.

CDPAS STANDARDS
The following are the names of each CDPAS standard. The associate standard, justification and guidance can be found in the
CDPAS document: 48

1. Professional Duty of Care

1.1. Ethical Conduct
1.2. Independence
1.3. Subject Matter Competency
1.4. Conflict of Interest (COI) Avoidance
2. Secure Practices

47
SCF CDPAS - https://securecontrolsframework.com/content/cdpas.pdf
48
SCF CDPAS - https://securecontrolsframework.com/content/cdpas.pdf

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 77 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 2.1. Security & Privacy By Design
2.2. Statement of Work (SOW)
2.3. Assessment-Specific Data Protection Impact Assessment (DPIA)
2.4. Intellectual Property (IP) Protections
2.5. Protection of Assessment Information
2.6. Use of Assessment Information
2.7. Disposal of Assessment Information
3. Due Diligence
3.1. Adherence To Data Protection CDPAS Requirements
3.2. Assessment Boundary Demarcation
3.3. Graphical Representation of Assessment Boundary
3.4. Stakeholder Identification
3.5. Control Reciprocity
3.6. Control Inheritance
3.7. Defined Cybersecurity and/or Data Privacy Controls
3.8. Defined Risk Tolerance
3.9. Defined Maturity Level
3.10. Defined Materiality Threshold
3.11. Material Risk Designation
3.12. Material Threat Designation
3.13. Material Incident Designation
3.14. Internal Assessment
4. Due Diligence – Assessors & 3PAOs
4.1. Formalized Assessment Plan
4.2. Defined Assessment Boundaries
4.3. Validate Control Applicability
4.4. Defined Evidence Request List (ERL)
4.5. Explicit Authorization For Testing
4.6. First-Party Declarations (1PD) - Control Inheritance
4.7. Third-Party Attestations (3PA) - Control Inheritance & Reciprocity
4.8. Stakeholder Validation
5. Due Care - OSAs
5.1. Proactive Governance
5.2. Non-Conformity Oversight
5.3. Annual Affirmation
6. Due Care – Assessors & 3PAOs
6.1. Assessment Methods
6.2. Assessment Rigor
6.3. Assessing Based On Control CDPAS Applicability
6.4. Assessment Objectives (AOs)
6.5. Control Designation
6.6. Objectivity Through Reasonable Interpretation
6.7. Adequate Sampling
6.8. Assessment Tools & Automation
7. Quality Control
7.1. Assessment Findings
7.2. Objective Peer Review
8. Conformity Designation
8.1. Report On Conformity (ROC)
8.2. Assessment Finding Challenges
9. Maintaing Conformity
9.1. Plan of Action & Milestones (POA&M)
9.2. Changes Affecting The Assessment Boundary
9.3. Reassessments Due To Material Change

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 78 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 11. SECURE CONTROLS FRAMEWORK CONFORMITY ASSESSMENT PROGRAM (SCF CAP)
The SCF Conformity Assessment Program (SCF CAP) is an organization-level conformity assessment. The SCF CAP is designed to
utilize tailored cybersecurity and data privacy controls that specifically address the applicable statutory, regulatory and
contractual obligations an Organization Seeking Assessment (OSA) is required to comply with. By using the metaframework
nature of the SCF, an OSA is able to perform conformity assessment that spans multiple cybersecurity and data privacy-specific
laws, regulations and frameworks.

The SCF CAP is focused on using the SCF as the control set to provide a company-level certification. While the SCF-CAP shares
some similarities with other existing, single-focused certifications (e.g., ISO 27001, CMMC, FedRAMP, etc.), the SCF CAP is unique
in its metaframework approach to covering cybersecurity and data protection requirements that span multiple laws, regulations
and frameworks

SCF CAP BODY OF KNOWLEDGE (SCF CAP BOK)

The SCF CAP Body of Knowledge (SCF CAP BoK) is the source of knowledge for the SCF CAP.49

[SCF CAP BoK download - https://securecontrolsframework.com/content/cap/SCF-CAP-BOK.pdf]

ABC’S OF CONFORMITY ASSESSMENT

NIST Special Publication 200-01, ABC’s of Conformity Assessment, is where you should start to understand what a conformity
assessment is and why it is important.50 That document is designed to provide the reader with an introduction to conformity
assessment and information on how the various conformity assessment activities are interlinked.

49
SCF CAP BoK - https://securecontrolsframework.com/content/cap/SCF-CAP-BOK.pdf
50
NIST SP 2000-01 - NIST Special Publication 200-01, ABC’s of Conformity Assessment

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 79 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 12. RISK & THREAT CATALOGS
The SCF contains both a risk and threat catalog as part of the Excel download.

SCF RISK CATALOG

The use case for the SCF’s risk catalog is to identify the applicable risk(s) associated with a control deficiency. (e.g., if the control
fails, what risk(s) is the organization exposed to?). A “risk” is defined as:
Noun: A situation where someone or something valued is exposed to danger, harm or loss.
Verb: To expose someone or something valued to danger, harm or loss.

In the context of this definition of risk, it is important to define underlying components of this risk definition:
 Danger: state of possibly suffering harm or injury
 Harm: material / physical damage
 Loss: destruction, deprivation or inability to use

With this understanding of what risk is, the SCF contains a catalog of thirty-nine (39) risks:

Risk*
Note - Some of these risks may Description of Possible Risk Due To Control Deficiency
Risk Grouping Risk # indicate a deficiency that could
be considered a failure to meet IF THE CONTROL FAILS, RISK THAT THE ORGANIZATION
"reasonable security practices" IS EXPOSED TO IS:

Inability to maintain individual The inability to maintain accountability (e.g., asset

R-AC-1
accountability ownership, non-repudiation of actions or inactions, etc.).

The inability to implement least privileges (e.g., Role-Based

Improper assignment of
R-AC-2 Access Control (RBAC), Privileged Account Management
privileged functions
(PAM), etc.).
Access
Control
R-AC-3 Privilege escalation The inability to restrict access to privileged functions.

The inability to restrict access to only authorized individuals,

R-AC-4 Unauthorized access
groups or services.

R-AM-1 Lost, damaged or stolen asset(s) Lost, damaged or stolen assets.

Asset Loss of integrity through Unauthorized changes that corrupt the integrity of the
R-AM-2
Management unauthorized changes system / application / service.

Emergent properties and/or Emergent properties and/or unintended consequences from

R-AM-3
unintended consequences Artificial Intelligence & Autonomous Technologies (AAT).

Increased latency, or a service outage, that negatively

R-BC-1 Business interruption
impact business operations.
Business
Continuity
The inability to maintain the confidentiality of the data
R-BC-2 Data loss / corruption
(compromise) or prevent data corruption (loss).

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 80 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 R-BC-3 Reduction in productivity Diminished user productivity.

Information loss / corruption or A technical attack that compromises data, systems,

R-BC-4 system compromise due to applications or services (e.g., malware, phishing, hacking,
technical attack etc.).

Information loss / corruption or A non-technical attack that compromises data, systems,

R-BC-5 system compromise due to non‐ applications or services (e.g., social engineering, sabotage,
technical attack etc.).

A negative impact on the ability to generate revenue (e.g., a

R-EX-1 Loss of revenue
loss of clients or an inability to generate future revenue).

A cancelled contract with a client or other entity for cause

R-EX-2 Cancelled contract
(e.g., failure to fulfill obligations for secure practices).

Diminished competitive Diminished competitive advantage (e.g., lose market share,

R-EX-3
advantage internal dysfunction, etc.).

Exposure R-EX-4 Diminished reputation Diminished brand value (e.g., tarnished reputation).

Financial damages due to fines and/or judgements from

R-EX-5 Fines and judgements
statutory / regulatory / contractual non-compliance.

Unmitigated technical vulnerabilities that lack

R-EX-6 Unmitigated vulnerabilities
compensating controls or other mitigation actions.

A compromise of a system, application or service that

R-EX-7 System compromise
affects confidentiality, integrity, availability and/or safety.

Insufficient cybersecurity and/or privacy practices that

Inability to support business
R-GV-1 cannot securely support the organization's technologies &
processes
processes.

Missing or incorrect cybersecurity and/or privacy controls

R-GV-2 Incorrect controls scoping
due to incorrect or inadequate control scoping practices.
Governance
Insufficient cybersecurity and/or privacy roles &
R-GV-3 Lack of roles & responsibilities responsibilities that cannot securely support the
organization's technologies & processes.

Insufficient cybersecurity and/or privacy practices that can

R-GV-4 Inadequate internal practices securely support the organization's technologies &
processes.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 81 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 Insufficient Cybersecurity Supply Chain Risk Management
R-GV-5 Inadequate third-party practices (C-SCRM) practices that cannot securely support the
organization's technologies & processes.

The inability to demonstrate appropriate evidence of due

Lack of oversight of internal
R-GV-6 diligence and due care in overseeing the organization's
controls
internal cybersecurity and/or privacy controls.

The inability to demonstrate appropriate evidence of due

Lack of oversight of third-party
R-GV-7 diligence and due care in overseeing third-party
controls
cybersecurity and/or privacy controls.

Disruptive content or actions that negatively affect business

R-GV-8 Illegal content or abusive action operations (e.g., abusive content, harmful speech, threats
of violence, illegal content, etc.).
Insufficient incident response practices that prevent the
Inability to investigate / organization from investigating and/or prosecuting incidents
R-IR-1
prosecute incidents (e.g., chain of custody corruption, available sources of
evidence, etc.).

The inability to appropriately respond to incidents in a timely

R-IR-2 Improper response to incidents
manner.
Incident
Response
The inability to ensure incident response actions were
R-IR-3 Ineffective remediation actions
correct and/or effective.

Expense associated with Financial repercussions from responding to an incident or

R-IR-4
managing a loss event loss.

Inability to maintain situational The inability to detect cybersecurity and/or privacy incidents
R-SA-1
awareness (e.g., a lack of situational awareness).
Situational
Awareness
Lack of a security-minded The inability to appropriately educate and train personnel to
R-SA-2
workforce foster a security-minded workforce.

Loss of Confidentiality, Integrity, Availability and/or Safety

Third-party cybersecurity (CIAS) from third-party cybersecurity practices,
R-SC-1
exposure vulnerabilities and/or incidents that affects the supply chain
through impacted products and/or services.
Loss of Confidentiality, Integrity, Availability and/or Safety
(CIAS) from physical security exposure of third-party
Third-party physical security
R-SC-2 structures, facilities and/or other physical assets that
exposure
affects the supply chain through impacted products and/or
Supply Chain services.
Loss of Confidentiality, Integrity, Availability and/or Safety
Third-party supply chain
(CIAS) from "downstream" third-party relationships, visibility
R-SC-3 relationships, visibility and
and controls that affect the supply chain through impacted
controls
products and/or services.

Third-party compliance / legal The inability to maintain compliance due to third-party non-
R-SC-4
exposure compliance, criminal acts, or other relevant legal action(s).

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 82 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 The misuse of the product / service in a manner that it was
R-SC-5 Use of product / service
not designed or how it was approved for use.

The inability to continue business operations, due to the

R-SC-6 Reliance on the third-party
reliance on the third-party product and/or service.

SCF THREAT CATALOG

It is necessary to develop a threat catalog that identifies possible natural and man-made threats that affect the entity's
cybersecurity & data privacy controls. The use case for the threat catalog is to identify applicable natural and man-made threats
that affect control execution. (e.g., if the threat materializes, will the control function as expected?) In the context of the C|P-RMM,
“threat” is defined as:
Noun: A person or thing likely to cause damage or danger.
Verb: To indicate impending damage or danger.

This threat catalog is sorted by natural and man-made threats:

NATURAL THREATS
Natural threats are caused by environmental phenomena that have the potential to impact individuals, processes, organizations
or society, as a whole. The SCF’s Threat Catalog contains fourteen (14) natural threats:

Threat
Threat* Threat Description
#

Regardless of geographic location, periods of reduced rainfall are expected. For non-
NT-1 Drought & Water Shortage agricultural industries, drought may not be impactful to operations until it reaches
the extent of water rationing.

Earthquakes are sudden rolling or shaking events caused by movement under the
NT-2 Earthquakes earth’s surface. Although earthquakes usually last less than one minute, the scope
of devastation can be widespread and have long-lasting impact.

Regardless of geographic location or even building material, fire is a concern for

every business. When thinking of a fire in a building, envision a total loss to all
NT-3 Fire & Wildfires
technology hardware, including backup tapes, and all paper files being consumed in
the fire.

Flooding is the most common of natural hazards and requires an understanding of

the local environment, including floodplains and the frequency of flooding events.
NT-4 Floods
Location of critical technologies should be considered (e.g., server room is in the
basement or first floor of the facility).

Hurricanes and tropical storms are among the most powerful natural disasters
Hurricanes & Tropical because of their size and destructive potential. In addition to high winds, regional
NT-5
Storms flooding and infrastructure damage should be considered when assessing
hurricanes and tropical storms.
Landslides occur throughout the world and can be caused by a variety of factors
including earthquakes, storms, volcanic eruptions, fire, and by human modification
NT-6 Landslides & Debris Flow of land. Landslides can occur quickly, often with little notice. Location of critical
technologies should be considered (e.g., server room is in the basement or first floor
of the facility).

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 83 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 Due to the wide variety of possible scenarios, consideration should be given both to
Pandemic (Disease) the magnitude of what can reasonably happen during a pandemic outbreak (e.g.,
NT-7
Outbreaks COVID-19, Influenza, SARS, Ebola, etc.) and what actions the business can be taken
to help lessen the impact of a pandemic on operations.

Severe weather is a broad category of meteorological events that include events that
NT-8 Severe Weather
range from damaging winds to hail.

Space weather includes natural events in space that can affect the near-earth
environment and satellites. Most commonly, this is associated with solar flares from
NT-9 Space Weather
the Sun, so an understanding of how solar flares may impact the business is of
critical importance in assessing this threat.
Thunderstorms are most prevalent in the spring and summer months and generally
occur during the afternoon and evening hours, but they can occur year-round and at
NT-10 Thunderstorms & Lightning all hours. Many hazardous weather events are associated with thunderstorms.
Under the right conditions, rainfall from thunderstorms causes flash flooding and
lightning is responsible for equipment damage, fires and fatalities.
Tornadoes occur in many parts of the world, including the US, Australia, Europe,
Africa, Asia, and South America. Tornadoes can happen at any time of year and
NT-11 Tornadoes occur at any time of day or night, but most tornadoes occur between 4–9 p.m.
Tornadoes (with winds up to about 300 mph) can destroy all but the best-built man-
made structures.
All tsunamis are potentially dangerous, even though they may not damage every
coastline they strike. A tsunami can strike anywhere along most of the US coastline.
NT-12 Tsunamis
The most destructive tsunamis have occurred along the coasts of California, Oregon,
Washington, Alaska and Hawaii.

While volcanoes are geographically fixed objects, volcanic fallout can have
significant downwind impacts for thousands of miles. Far outside of the blast zone,
NT-13 Volcanoes
volcanoes can significantly damage or degrade transportation systems and also
cause electrical grids to fail.

Winter storms is a broad category of meteorological events that include events that
Winter Storms & Extreme range from ice storms, to heavy snowfall, to unseasonably (e.g., record breaking)
NT-14
Cold cold temperatures. Winter storms can significantly impact business operations and
transportation systems over a wide geographic region.

MANMADE THREATS
Manmade threats are caused by an element of human intent, negligence or error, or threat of violence that have the potential to
impact individuals, processes, organizations or society, as a whole. The SCF’s Threat Catalog contains twenty-three (23)
manmade threats:

Threat
Threat* Threat Description
#

Civil or political unrest can be singular or wide-spread events that can be

MT-1 Civil or Political Unrest
unexpected and unpredictable. These events can occur anywhere, at any time.

Unlike physical threats that prompt immediate action (e.g., "stop, drop, and roll" in
Hacking & Other the event of a fire), cyber incidents are often difficult to identify as the incident is
MT-2
Cybersecurity Crimes occurring. Detection generally occurs after the incident has occurred, with the
exception of "denial of service" attacks. The spectrum of cybersecurity risks is

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 84 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 limitless and threats can have wide-ranging effects on the individual, organizational,
geographic, and national levels.

Hazardous materials emergencies are focused on accidental disasters that occur in

Hazardous Materials
MT-3 industrialized nations. These incidents can range from industrial chemical spills to
Emergencies
groundwater contamination.

The use of NBC weapons are in the possible arsenals of international terrorists and it
must be a consideration. Terrorist use of a “dirty bomb” — is considered far more
Nuclear, Biological and
MT-4 likely than use of a traditional nuclear explosive device. This may be a combination of
Chemical (NBC) Weapons
conventional explosive device with radioactive / chemical / biological material and
be designed to scatter lethal and sub-lethal amounts of material over a wide area.

Physical crime includes "traditional" crimes of opportunity. These incidents can

MT-5 Physical Crime range from theft, to vandalism, riots, looting, arson and other forms of criminal
activities.

Armed attacks, regardless of the motivation of the attacker, can impact a business.
Scenarios can range from single actors (e.g., "disgruntled" employee) all the way to a
MT-6 Terrorism & Armed Attacks coordinated terrorist attack by multiple assailants. These incidents can range from
the use of blade weapons (e.g., knives), blunt objects (e.g., clubs), to firearms and
explosives.
Utility service disruptions are focused on the sustained loss of electricity, Internet,
natural gas, water, and/or sanitation services. These incidents can have a variety of
MT-7 Utility Service Disruption
causes but directly impact the fulfillment of utility services that your business needs
to operate.
Dysfunctional management practices are a manmade threat that expose an
organization to significant risk. The threat stems from the inability of weak,
Dysfunctional Management
MT-8 ineffective and/or incompetent management to (1) make a risk-based decision and
Practices
(2) support that decision. The resulting risk manifests due to (1) an absence of a
required control or (2) a control deficiency.

Human error is a broad category that includes non-malicious actions that are
MT-9 Human Error unexpected and unpredictable by humans. These incidents can range from
misconfigurations, to misunderstandings or other unintentional accidents.

Technical /mechanical failure is a broad category that includes non-malicious failure

due to a defect in the technology, materials or workmanship. Technical / mechanical
Technical / Mechanical
MT-10 failures are unexpected and unpredictable, even when routine and preventative
Failure
maintenance is performed. These incidents can range from malfunctions, to
reliability concerns to catastrophic damage (including loss of life).
Laws, regulations and/or contractual obligations that directly or indirectly weaken an
Statutory / Regulatory / organization's security & privacy controls. This includes hostile nation states that
MT-11
Contractual Obligation leverage statutory and/or regulatory means for economic or political espionage
and/or cyberwarfare activities.

Redundant, Redundant, Obsolete/Outdated, Toxic or Trivial (ROTT) data is information an

MT-12 Obsolete/Outdated, Toxic or organization utilizes for business processes even though the data is untrustworthy,
Trivial (ROTT) Data due to the data's currency, accuracy, integrity and/or applicability.

Artificial Intelligence & Autonomous Technologies (AAT) is a broad category that

Artificial Intelligence &
ranges from non-malicious failure due to a defect in the algorithm to emergent
MT-13 Autonomous Technologies
properties or unintended consequences. AAT failures can be due to hardware
(AAT)
failures, inherent biases or other flaws in the underlying algorithm. These incidents

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 85 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
 can range from malfunctions, to reliability concerns to catastrophic damage
(including loss of life).

Willful criminal conduct is a broad category that includes consciously-committed

criminal acts performed by individuals (e.g., mens rea). These incidents can include
Fraud, Corruption and/or
MT-14 a wide-range of activities that includes fraud, corruption, theft and illegal content.
Willful Criminal Conduct
Criminal conduct generally involves one of the following kinds of mens rea: (1) intent,
(2) knowledge, (3) recklessness and/or (4) negligence.
Conflict of Interest (COI) is a broad category but pertains to an ethical
incompatibility. COI exist when (1) the concerns or goals of different parties are
MT-15 Conflict of Interest (COI)
incompatible or (2) a person in a decision-making position is able to derive personal
benefit from actions taken or decisions made in their official capacity.
Macroeconomic factors that can negatively affect the global supply chain.
Macroeconomic factors directly impact unemployment rates, interest rates,
MT-16 Macroeconomics exchange rates and commodity prices. Due to how fiscal and monetary policies can
negatively affect the global supply chain, this can disrupt or degrade an
organization's business operations.
Foreign Ownership, Control, or Influence (FOCI) is a Supply Chain Risk Management
(SCRM) threat category that pertains to the ownership of, control of, or influence
Foreign Ownership, Control, over an organization. Primarily, the concern is if a foreign interest (e.g., foreign
MT-17
or Influence (FOCI) government or parties owned or controlled by a foreign government) has the direct or
indirect ability to influence decisions that affect the management or operations of
the organization.
Geopolitical is a Supply Chain Risk Management (SCRM) threat category that
pertains to a specific geographic location, or region of relevance, that affects the
MT-18 Geopolitical
supply chain. Primarily, the concern is if a foreign state can affect the supply chain
through political intervention within the host nation.

Sanctions is a Supply Chain Risk Management (SCRM) threat category that pertains
to past or present fraudulent activity or corruption. Primarily, the concern is if the
MT-19 Sanctions
third-party is subject to suspension, exclusion or other sanctions that can affect the
supply chain.
Counterfeit / Non-Conforming Products is a Supply Chain Risk Management (SCRM)
threat category that pertains to the integrity of components within the supply chain.
Counterfeit / Non- Counterfeits are products introduced to the supply chain that falsely claim to be
MT-20
Conforming Products produced by the legitimate Original Equipment Manufacturer (OEM), whereas non-
conforming are OEM products / materials that fail to meet the customer
specifications. Both can have a detrimental effect on the supply chain.
Operational Environment is a Supply Chain Risk Management (SCRM) threat
category that pertains to the user environment (e.g., place of performance).
MT-21 Operational Environment
Primarily, the concern is if the operational environment is hazardous that could
expose the organization operationally or financially.

Supply Chain Interdependencies is a Supply Chain Risk Management (SCRM) threat

Supply Chain
MT-22 category pertaining to interdependencies related to data, systems and mission
Interdependencies
functions.

Third-Party Quality Deficiencies is a Supply Chain Risk Management (SCRM) threat

category that provide insights into the ability of the third-party to produce and deliver
Third-Party Quality products and/or services as expected. This includes an understanding of the quality
MT-23
Deficiencies assurance practices associated with preventing mistakes or defects in
manufactured/ developed products and avoiding problems when delivering
solutions or services to customers.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 86 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 13. ASSESSMENT OBJECTIVES (AOS)
The SCF contains an Assessment Objectives (AOs) tab to support the SCF Conformity Assessment Program (SCF CAP), since
assessors must evaluate controls by utilizing AOs, when AOs are available.

An AO is an objective statement that establishes the desired outcome for the assessment for a specific control. There may be
multiple AOs associated with a control.

AO ORIGINS
Each AO is tagged to identify its origin. The AOs may include one, or more, origins due to overlap:
 SCF created;
 NIST SP 800-53A R5;
 NIST SP 800-171A;
 NIST SP 800-171A R3; and
 NIST SP 800-172A.

OBJECTIVE ASSESSMENT CRITERIA

AOs provide objective criteria that each must be satisfied to legitimately determine whether the control is implemented and
operating as intended. A control cannot be designated as Satisfied unless all of the AOs are either:
 Satisfied;
 Not Applicable (N/A); or
 Compensating Control.

In the context of control designations, a designation of:

 Satisfactory is positive, where the criteria are met;
 Deficient is negative, where the criteria are not met;
 Alternative Control is neutral, where another control, or controls, is/are designated as sufficiently reducing the risk(s)
associated with the control; and
 N/A is neutral, where the control, or AO, does not apply.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 87 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 14. EVIDENCE REQUEST LIST (ERL)
The SCF contains an Evidence Request List (ERL) tab to support the SCF Conformity Assessment Program (SCF CAP). The ERL:
 Represents the minimum level of reasonable evidence requests to perform a controls assessment;
 Establishes a finite list of supporting evidence used in an assessment; and
 Standardizes evidence expectations to allow Organizations Seeking Assessment (OSA) to have sufficient time to
accumulate reasonable evidence to determine the adequacy of control design and operation.

REASONABLE ASSESSMENT ARTIFACTS

Assessors and Third-Party Assessment Organizations (3PAOs) operate from a position of trust and authority. Therefore,
minimizing “scope creep” that can increase the duration, cost and personnel commitments associated with an assessment is
essential. As part of due diligence activities, assessors and 3PAOs are expected to:
 Define an authoritative ERL; and
 Before the start of the assessment, provide any artifact requests to the OSA.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 88 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 15. POSSIBLE SOLUTIONS & CONSIDERATIONS
The SCF leveraged the firm size model from the Bureau of Labor Statistics (BLS) to organize possible solutions and considerations for
applicable SCF controls. 51 The SCF consolidated the nine (9) BLS firm sizes into five (5):
1. Micro-Small Business;
2. Small Business;
3. Medium Business;
4. Large Business; and
5. Enterprise.

SOLUTIONS FOR MICRO-SMALL BUSINESS

The micro-small business category is applicable to organization that:
 Have less than ten (10) employees; or
 Are in BLS Firm Size Classes 1-2.

SOLUTIONS FOR SMALL BUSINESS

The small business category is applicable to organization that:
 Have between ten (10) and forty-nine (49) employees; or
 Are in BLS Firm Size Classes 3-4.

SOLUTIONS FOR MEDIUM BUSINESS

The medium business category is applicable to organization that:
 Have between fifty (50) and two hundred forty-nine (249) employees; or
 Are in BLS Firm Size Classes 5-6.

SOLUTIONS FOR LARGE BUSINESS

The large business category is applicable to organization that:
 Have between two hundred fifty (250) and nine hundred ninety-nine (999) employees; or
 Are in BLS Firm Size Classes 7-9.

SOLUTIONS FOR ENTERPRISES

The enterprise category is applicable to organization that:
 Have one thousand or more (1,000+) employees; or
 Are in BLS Firm Size Classes 9.

EXPERT INSIGHT (POSSIBLE SOLUTIONS): For most SCF controls, the solutions would be to have administrative controls such as
documented policies, standards and procedures. It would be highly inefficient and add no value to have that common assumption written
for every control, so the focus was on unique administrative, physical and/or technical solutions that may be applicable for a specific
control, beyond the assumed policies, standards and procedures.

51
BLS Firm Size Classes - https://www.bls.gov/bdm/bdmfirmsize.htm

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 89 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 16. PRE-DEFINED CONTROL SETS
The SCF has several “pre-defined control sets” that contain a subset of the SCF catalog where those controls are specific to a
unique business need.

Those pre-defined control sets are:

 SCF-B (Business Mergers & Acquisitions);
 SCF-I (Cyber Liability Insurance);
 SCF-E (Embedded Technology);
 SCF-M (MSP/MSSP Secure Practices Baseline);
 SCF-R (Ransomware Protection); and
 SCF-Z (Zero Trust Architecture).

These are “good idea fairy” starting points for those who may want a push in the right direction for possible controls to address
these pre-defined topics.

SCF-B (BUSINESS MERGERS & ACQUISITIONS)

The SCF-B control set is specifically designed to identify reasonable controls associated with Mergers & Acquisitions (M&A) due
diligence assessments. Controls are based on:
 COBITv5;
 COSO;
 CSA CCM;
 GAPP;
 ISO 27002;
 ISO 31000;
 ISO 31010;
 NIST 800-160;
 NIST Cybersecurity Framework;
 OWASP Top 10;
 UL 2900-1; and
 EU GDPR.

SCF-I (CYBER LIABILITY INSURANCE)

The SCF-I control set is specifically designed to identify reasonable controls associated with cyber liability insurance underwriting
to help determine appropriate due diligence and due care for insurability. Controls are based on:
 FAR 52.204-21;
 National Association of Insurance Commissioners (NAIC): NIAC Insurance Data Security Model Law (MDL-668);
 Oregon ORS 646A.600 (Consumer Identity Theft Protection Act); and
 Standards for the Protection of PII of Residents of the Commonwealth (MA 201 CMR 17.00).

SCF-E (EMBEDDED TECHNOLOGY)

The SCF-E control set is specifically designed to identify reasonable controls associated with embedded technologies.

SCF-M (MSP/MSSP SECURE PRACTICES BASELINE)

The SCF-M control set is specifically designed to identify reasonable controls associated with Managed Service Providers (MSPs)
/ Managed Security Service Providers (MSSP) to demonstrate reasonable due diligence and due care activities that keep their
clients secure. Controls are based on:
 AICPA / CICA Privacy Maturity Model (GAPP);
 NAIC Insurance Data Security Model Law (MDL-668);
 NIST 800-161 rev 1 C-SCRM Baseline;
 NIST 800-171 rev 3;
 NIST 800-207 (Zero Trust Architecture);
 NIST CSF v2.0 IPD;
 OWASP Top 10 v2021;
 DHS CISA TIC 3.0;
 FAR Section 889;
 GLBA CFR 314 (Dec 2023); and

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 90 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
  SEC Cybersecurity Rule.

SCF-R (RANSOMWARE PROTECTION)

The SCF-E control set is specifically designed to address ransomware protections, based on NIST IR 8374, Cybersecurity
Framework Profile for Ransomware Risk Management. 52

SCF-Z (ZERO TRUST ARCHITECTURE)

The SCF-Z control set is specifically designed to identify reasonable controls associated with Zero Trust Architecture (ZTA).
Controls are based on:
 DoD Zero Trust Reference Architecture.

52
NIST IR 8374 - https://csrc.nist.gov/pubs/ir/8374/final

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 91 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
SECTION 17. FREQUENTLY ASKED QUESTIONS (FAQ)
The SCF is more than just an assortment of cybersecurity and data privacy controls. The SCF is focused on (1) designing, (2)
implementing and (3) maintaining SECURE & COMPLIANT solutions to address all applicable statutory, regulatory and contractual
requirements that an organization faces.

The SCF Council’s is confident is that if an organization properly scopes its cybersecurity and data protection requirements with
security in mind, compliance will often be a natural byproduct of those actions. To properly use the SCF to become secure and
compliant, it requires an organization’s users to understand what the SCF is and how to use it. Therefore, these FAQs are
published for that purpose.

GENERAL FAQ
This section addresses general FAQ associated with the SCF.

GEN-FAQ-001: HOW DO I START USING THE SCF?

Before you dive into the SCF, it is imperative that you understand the fundamentals of what the SCF is and what it is not. Without
that knowledge, you will likely use the SCF incorrectly (e.g., trying to use a screwdriver as a prybar). You can gain this
understanding through reading the SCF Overview & Instructions document. If you do not want to take the time to educate yourself
on the basics, you are advised to avoid using the SCF and find a different solution for your needs or outsource the work to a
competent third-party.

You access the SCF in one (1) of two (2) ways:

1. Download the Excel version from the SCF website; or
2. Use a GRC tool, such as SCF Connect or others listed on the SCF Marketplace.

If you get stuck, there are a few resources available:

1. Re-read the SCF Overview & Instructions to see if you missed something;
2. Sign up for the SCF Discord server to ask questions;
3. Hire a SCF Trainer from the SCF Marketplace to provide individual or group training; and/or
4. Hire a SCF Practitioner from the SCF Marketplace to get 1-1 consulting expertise.

While the SCF Council gives away the SCF for free, if you want a consultant to take you through setting up or operationalizing your
control set, you will have to pay for that service. The SCF Marketplace has a non-exclusive listing of cybersecurity and data privacy
professionals who have the skills and experience to assist you.

GEN-FAQ-002: HOW DO I SELECT CONTROLS SPECIFIC TO MY NEEDS?

The SCF is fundamentally an Excel spreadsheet. Therefore, you can use your Excel skills to manually filter the requirements. If you
are comfortable with Excel, it might take you 5-10 minutes to do this filtering, based on how many requirements you need to map
to. Within the SCF, there is a column labelled “Minimum Security Requirements (MSR) MCR + MSR” that will assist you in this
process.

Follow these steps to tailor the SCF:

1. Either hide or delete all of the columns containing laws, regulations or frameworks that are not
applicable to your organization (e.g., if you only have to comply with ISO 27002, PCI DSS and
EU GDPR, then you can delete or hide all other mapping columns but those).Using the filter
option in Excel (little gray arrow on the top row in each column), you would then filter the
columns to only show cells that contain content (e.g., don’t show blank cells in that column).
2. A selection of either MCR or DSR will automatically select the MSR + DSR column:
a. In the MCR column, simply put an “x” to mark that control as being “must have”
controls.
b. In the DSR column, simply put an “x” to mark that control as being “nice to have”
controls.
3. Unfilter the column you just performed this task on and do it to the next law, regulation or
framework that you need to map.
4. Repeat steps 2 and step 3 until all your applicable laws, regulations and frameworks are
mapped to.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 92 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
The MSR + DSR column will now have an “x” that marks each SCF control that is applicable for your needs, based on what was
selected for MCR and DSR controls. This will leave you with a SCF control set that is tailored for your specific needs.

GEN-FAQ-003: HOW OFTEN IS THE SCF UPDATED?

The general cadence for updates is one (1) update per quarter (e.g., four (4) updates per year). There may be situations where out-
of-cycle updates are released, but the goal is to publish updates on a quarterly basis.

GEN-FAQ-004: WHY IS THE SCF FREE TO USE?

The SCF is free to help fix the broken nature of cybersecurity and data privacy practices that many organizations face. The reality
is that we cannot rely on politicians to fix anything, so it is up to us to provide solutions.

The quality of the SCF could easily justify a costly subscription service, but we know that would exclude most organizations and
defeat our broader goal of improving cybersecurity and data privacy practices on a macro scale. While our contributors are
volunteers, we rely on our generous sponsors to maintain the SCF.

GEN-FAQ-005: WHAT DOES "MECHANISMS EXIST" MEAN?

The controls that make up the SCF were written to (1) be flexible and (2) meet the needs of organizations, regardless of size or
industry. That approach to control structure can make wording a challenge. One solution that SCF architects came to agreement
on is in the approach to normalizing control wording. For example:
 "Mechanisms exist to..."
 "Automated mechanisms exist to..."
 "Physical security mechanisms exist to..."

The use of the term “mechanism” is the best option, since a mechanism can mean (1) a manual process, (2) a technology solution,
(3) outsourced contract or (4) a combination of those that come together to address the needs of the control. Some smaller
companies may lack technology solutions for many controls, so manual processes will likely prevail. However, getting into
Fortune 500 environments, technology solutions will most often exist to address the controls.

GEN-FAQ-006: ARE THERE RESTRICTIONS ON THE USE OF THE SCF?

Yes. The Secure Controls Framework is copyrighted material, but it leverages the Creative Commons Attribution-NoDerivatives
4.0 International Public License to help maintain the integrity of the SCF. Under the SCF Terms & Conditions:
 Attribution - You must give appropriate credit, provide a link to the license and indicate if changes were made. You may
do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. Providing
attribution is as simple as stating SCF controls are used in the solution, such as a GRC platform that includes SCF content
is required to provide attribution that SCF controls are used.
 NoDerivatives - If you remix, transform, or build upon the material, you may not distribute the modified material. For
example, you are prohibited from leveraging SCF material to create a derivative solution (e.g., SCF 2.0). This prohibition
on creating derivative works includes utilizing Artificial Intelligence (AI) (or similar technologies) to leverage SCF content
to generate policies, standards, procedures, metrics, risks, threats or other derivative content.

GEN-FAQ-007: HOW DOES THE CONTROL WEIGHTING WORK IN THE SCF?

The SCF assigns a value on a scale from 1-10, with 1 being the least important and 10 being the most important. These values are
subjective, based on SCF contributor discussion, since control weighting is important to help prioritize controls and assist with
the understanding what really matters from a risk management perspective. For an insight into the thought process, a control
weighting of 10 was framed as “Would you do business with an organization that did not have this control in place?” where certain
controls were identified as an absolute minimum from a risk threshold perspective from a “reasonable person” perspective.
 Those controls designated as a score of 10 should be considered a MATERIAL / KEY CONTROL (e.g., lack of or a deficiency
should be considered a material weakness).
 On the opposite side of the spectrum, a score of 1 was deemed “nice to have” but did not materially affect risk.

GEN-FAQ-008: WHY DOES THE SCF SAY IT IS THE COMMON CONTROLS FRAMEWORK?
The use of Common Controls Framework™ is trademarked by the SCF. The SCF has exclusive rights to say the SCF is the Common

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 93 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
Controls Framework™. Additionally, the following domains point to the SCF’s website:
 common-controls-framework.com; and
 commoncontrolsframework.com

GEN-FAQ-009: WHAT IS THE CYBERSECURITY & DATA PROTECTION ASSESSMENT STANDARDS (CDPAS)?
With the rise of Artificial Intelligence (AI) and autonomous technologies, the traditional Confidentiality, Integrity & Availability "CIA
Triad" is insufficient to address the needs of a modern, digital cybersecurity and data privacy program due to its avoidance of a

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 94 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.
CONFORMITY ASSESSMENT PROGRAM (CAP) FAQ

This section addresses general FAQ associated with the SCF CAP.

CAP-FAQ-001: WHAT IS THE SCF CAP?

The SCF Conformity Assessment Program (SCF CAP) is an organization-level conformity assessment. The SCF CAP is designed to
utilize tailored cybersecurity and data privacy controls that specifically address the applicable statutory, regulatory and
contractual obligations an Organization Seeking Assessment (OSA) is required to comply with. By using the metaframework
nature of the SCF, an OSA is able to perform conformity assessment that spans multiple cybersecurity and data privacy-specific
laws, regulations and frameworks.

The SCF CAP is focused on using the SCF as the control set to provide a company-level certification. While the SCF-CAP shares
some similarities with other existing, single-focused certifications (e.g., ISO 27001, CMMC, FedRAMP, etc.), the SCF CAP is unique
in its metaframework approach to covering cybersecurity and data protection requirements that span multiple laws, regulations
and frameworks

CAP-FAQ-002: WHAT IS A CONFORMITY ASSESSMENT?

NIST Special Publication 200-01, ABC’s of Conformity Assessment, is where you should start to understand what a conformity
assessment is and why it is important. That document is designed to provide the reader with an introduction to conformity
assessment and information on how the various conformity assessment activities are interlinked.

© 2024. Secure Controls Framework Council, LLC. All Rights Reserved. 95 of 95

This guide is for educational purposes only. You are encouraged to work with a competent professional to validate any compliance-related assumptions.