SCF Secure Controls Framework Guide
SCF Secure Controls Framework Guide
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 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 www.SecureControlsFramework.com
Table of Contents
2 of 23
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.
EXECUTIVE SUMMARY
The Secure Controls Framework™ (SCF) focuses on internal controls. These are the cybersecurity and privacy-related policies, standards,
procedures and other processes that are designed to provide reasonable assurance that business objectives will be achieved and
undesired events will be prevented, detected and corrected.
Using the SCF should be viewed as a long-term tool to not only help with compliance-related efforts but to ensure security and 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.
This document is designed for cybersecurity & privacy practitioners to gain an understanding of how the SCF is intended to be used in
their organization.
3 of 23
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.
SECTION 1: LEVEL SETTING WHAT THE SCF IS AND IT IS NOT
It is important for users of the SCF to understand what the SCF is and what it is not. We are very transparent on what the SCF offers and
we want to help ensure that SCF users understand their role in using the SCF in their efforts to secure their organization.
In developing the SCF, we identified and analyzed over 100 statutory, regulatory and contractual
frameworks. Through analyzing these thousands of legal, regulatory and framework requirements, we
identified commonalities and this allows several thousand unique controls to be addressed by the
approximately 870 controls that makeup 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.
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 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.
4 of 23
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.
DESIGNING & BUILDING AN AUDIT-READY CYBERSECURITY & PRIVACY PROGRAM
Building an audit-ready cybersecurity & privacy program requires addressing the holistic nature of
security and privacy concerning how people, processes and technology impact security practices.
Building a security program that routinely incorporates security and privacy practices into daily
operations requires a mastery of the basics. A useful analogy is with the children's toy, LEGO®. With
LEGO® you can build nearly anything you want — either through following directions or using your
own creativity. However, it first requires an understanding of how various LEGO® shapes either snap
together or are incompatible.
Once you master the fundamentals with LEGO®, it is easy to keep building and become immensely creative since you know how
everything interacts. However, when the fundamentals are ignored, the LEGO® structure will be weak and include systemic flaws.
Security and privacy really are not much different, 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 security or privacy “best practice” is a LEGO® block, it is possible to conceptualize
how certain requirements are the foundation that form the basis for others components to attach to. Only when the 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 and privacy
principles are designed, implemented and managed by default!
5 of 23
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.
SECTION 2: ADOPTING “SECURE BY DESIGN” PRINCIPLES
For an organization that 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 has to address SOC2, ISO 27002, CCPA, EU GDPR, PCI DSS and NY DFS? In these complex
cases that involve multiple frameworks, ISO 27002 principles alone do not cut it. 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 security and privacy processes, but lack the knowledge and experience to undertake
such documentation efforts. That means organizations are faced to either outsource 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.
The SCF’s comprehensive listing of approximately 870 cybersecurity and privacy controls is
categorized into 32 domains that are mapped to over 100 statutory, regulatory and contractual
frameworks. Those applicable SCF controls can operationalize the security & privacy principles
to help an organization ensure that secure practices are implemented by design and by default.
You may be asking yourself, “What security & privacy principles should I be using?” and that is a great question. The SCF helped with this
common question by taking the 32 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.
The S|P is a set of 32 security and privacy principles that leverage the SCF's extensive cybersecurity and privacy control set. You can
download the free poster by clicking the image to the right.
The “S 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
6 of 23
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.
“piped” with privacy principles to create secure processes in an efficient manner.
The S|P establishes 32 common-sense principles to guide the development and oversight of a modern security and privacy program.
Those 32 S|P principles are listed below:
7 of 23
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.
configuration management controls, security features can be inadvertently or deliberately omitted or rendered inoperable,
allowing processing irregularities to occur or the execution of malicious code.
9) Continuous Monitoring (MON)
▪ Principle: Maintain situational awareness of security-related events through the centralized collection and analysis of event logs
from systems, applications and services.
▪ Intent: Organizations establish and maintain ongoing situational awareness across the enterprise through the centralized
collection and review of security-related event logs. Without comprehensive visibility into infrastructure, operating system,
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.
10) Cryptographic Protections (CRY)
▪ Principle: Utilize appropriate cryptographic solutions and industry-recognized key management practices to protect the
confidentiality and integrity of sensitive data both at rest and in transit.
▪ Intent: Organizations ensure the confidentiality of the organization’s data through implementing appropriate cryptographic
technologies to protect systems and data.
11) Data Classification & Handling (DCH)
▪ Principle: Publish and enforce a data classification methodology to objectively determine the sensitivity and criticality of all data
and technology assets so that proper handling and disposal requirements can be followed.
▪ Intent: Organizations ensure that technology assets, both hardware and media, are properly classified and measures
implemented to protect the organization’s data from unauthorized disclosure, regardless if it is being transmitted or stored.
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.
12) Embedded Technology (EMB)
▪ Principle: Provide additional scrutiny to the risks associated with embedded technology, based on the potential damages posed
when used maliciously.
▪ Intent: Organizations specify the development, proactive management and ongoing review of security embedded technologies,
including hardening of the “stack” from the hardware, to firmware, software, transmission and service protocols used for
Internet of Things (IoT) and Operational Technology (OT) devices.
13) Endpoint Security (END)
▪ Principle: Harden endpoint devices to protect against reasonable threats to those devices and the data they store, transmit and
process.
▪ Intent: Organizations ensure that endpoint devices are appropriately protected from security threats to the device and its data.
Applicable statutory, regulatory and contractual compliance requirements dictate the minimum safeguards that must be in
place to protect the confidentiality, integrity, availability and safety considerations.
14) Human Resources Security (HRS)
▪ Principle: Foster a security and privacy-minded workforce through sound hiring practices and ongoing personnel management.
▪ Intent: Organizations create a security and privacy-minded workforce and an environment that is conducive to innovation,
considering issues such as culture, reward and collaboration.
15) Identification & Authentication (IAC)
▪ Principle: Implement an Identity and Access Management (IAM) capability to ensure the concept of “least privilege” is
consistently implemented across all systems, applications and services for individual, group and service accounts.
▪ Intent: Organizations implement the concept of “least privilege” through limiting access to the organization’s systems and data
to authorized users only.
16) Incident Response (IRO)
▪ Principle: Maintain a practiced incident response capability that trains all users on how to recognize and report suspicious
activities so that trained incident responders can take the appropriate steps to handle incidents, in accordance with an Incident
Response Plan (IRP).
▪ Intent: Organizations establish and maintain a capability to guide the organization’s response when security or privacy-related
incidents occur and to train users how to detect and report potential incidents.
17) Information Assurance (IAO)
▪ Principle: Utilize an impartial assessment process to validate the existence and functionality of appropriate security and privacy
controls, prior to a system, application or service being used in a production environment.
▪ Intent: Organizations ensure the adequately of security and controls are appropriate in both development and production
environments.
18) Maintenance (MNT)
▪ Principle: Utilize secure practices to maintain technology assets, according to current vendor recommendations for
configurations and updates, including those supported or hosted by third-parties.
8 of 23
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.
▪ Intent: Organizations ensure that technology assets are properly maintained to ensure continued performance and
effectiveness. Maintenance processes apply additional scrutiny to the security of end-of-life or unsupported assets.
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.
developed internally or acquired to make sure that the concepts of “least privilege” and “least functionality” are incorporated.
10 of 23
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.
SECTION 3: TAILORING THE SCF FOR YOUR NEEDS
Some people freak out and think they have to do all 870+ controls in the SCF and that is just not the case. It is best to visualize the SCF
as a “buffet of cybersecurity and privacy controls,” where there is a selection of 870+ controls available to you. You 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.
TAILORING IS REQUIRED - NOT ALL SCF CONTROLS ARE APPLICABLE TO YOUR ORGANIZATION
Understanding the requirements for both cybersecurity and 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.
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.
To make sure 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 that list of requirements then makes it simple to go through and customize the SCF for your specific needs!
Based on the business processes, vendor requirements and locations your organization operates, it has to comply with SOC 2 (ISACA
TSC), Cloud Security Alliance Cloud Controls Matrix (CSA CCM), ISO 27002, ISO 29100, PCI DSS, Oregon Identity Theft Protection Act &
the European Union General Data Protection Regulation (EU GDPR). The SCF helps pare this down 454 unique SCF controls that address
the needs of those 7 laws, regulations and frameworks.
However, if the user doing the scoping is unaware of the complete picture for the organization’s obligations and only filters on SOC 2
and ISO 27002, there will only be 335 unique controls. While there will be a lot of overlap, in this specific case there are over 100 unique
controls that are not being addressed. Without any type of follow-up internal or external audit processes that confirm the scoping of the
controls, that error in mapping could lead to significant legal and financial exposure to the company from ignoring applicable controls it
is obligated to perform.
Properly Scoped Example = 454 Controls Improperly Scoped Example = 335 Controls
In this example listed above, the SCF worked just fine since it provided the controls that are applicable to the laws, regulations and
frameworks selected by the user. What was broken is the organization’s due diligence practices, where there was no clear oversight of
the applicable cybersecurity and privacy requirements that the organization has to address. This is why knowing your organization’s
applicable statutory, regulatory and contractual obligations are vital to using the SCF (or any control set for that matter).
11 of 23
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.
CUSTOMIZING THE SCF OPTION 1: USE THE “CUSTOMIZE THE SCF” ONLINE TOOL
The most efficient way to tailor the SCF’s control set for your needs is to use the SCF’s “customize the SCF” tool that is available online
at https://www.securecontrolsframework.com/customize-the-scf.
The end result is going to give you all the applicable SCF controls to meet your specific needs.
There is a column that exists in the SCF to help with this task and is call the “Minimum Security Requirements
(MSR) Filter” that will assist you in this process.
12 of 23
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.
SECTION 4: IDENTIFYING A TARGET MATURITY LEVEL TO DEFINE WHAT “RIGHT” LOOKS LIKE
The SCF contains maturity criteria for its controls catalog to help organizations both build to and assess against quantifiable targets for
maturity. For most organizations, the “sweet spot” for maturity targets is between CMM 2 and 4 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
privacy teams dictating targets. Identifying maturity targets is meant to be a team effort between both technologists and business
stakeholders.
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 CMM 1 and CMM 2. The reason for this is at CMM 2, 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 CMM 3.
Oversight and process automation can decrease risk, but generally not as noticeably as steps taken to attain CMM 3.
The SP-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 people, processes and technology 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).
13 of 23
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.
The six SP-CMM levels are:
CMM 0 – Not Performed
CMM 1 – Performed Informally
CMM 2 – Planned & Tracked
CMM 3 – Well-Defined
CMM 4 – Quantitatively Controlled
CMM 5 – Continuously Improving
CMM 0 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 would be 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).
CMM 1 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 CMM 1 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 staff but there is no management focus to spend time on the control.
CMM 2 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. CMM 2 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, NIST 800-171, etc.).
It can be argued that CMM 2 practices focus more on compliance over security. The reason for this is the scoping of CMM 2 practices are
narrowly-focused and are not organization-wide.
14 of 23
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.
CMM 3 – WELL-DEFINED
This level of maturity is defined as “enterprise-wide standardization,” where the practices are well-defined and standardized across the
organization.
Base practices are performed according to a well-defined process using approved, tailored versions of standard, documented
processes.
Process is planned and managed using an organization-wide, standardized process.
CMM 3 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 CMM 2 practices that are narrowly focused, CMM 3 practices are standardized across
the organization.
It can be argued that CMM 3 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.
CMM 4 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.
15 of 23
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.
processes and from piloting innovative ideas and technologies.
CMM 5 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 requirements to be CMM 5.
16 of 23
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.
SUMMARY OF CCM VS ORGANIZATION SIZE CONSIDERATIONS
The following table summarizes the high-level expectations for small/medium/large organizations to meet each level of maturity.
17 of 23
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.
SP-CMM 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 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 SP-CMM.
Prioritization of capability maturities may be based on risk assessments, audits, compliance obligations or management direction.
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.
18 of 23
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.
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 restrictions. One
good rule of thumb when deciding between CMM 3 and CMM 4 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?” CMM 3 maturity is generally considered “an environment that is
in control” where it is well-managed, whereas being in a CMM 4 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 CMM 3 as the
highest-level of maturity targets. Additionally, the cost to mature from a CMM 3-4 or CMM 4-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
Defining a target maturity state is Step 4 in the “7 Steps To Building An Audit-Ready Cybersecurity & Privacy Program,” 1 a free resource
from the SCF. That guide can be useful, since it helps establish two key pre-requisites to identifying CMM targets:
1. Prioritization of efforts (including resourcing); and
2. Identification of applicable statutory, regulatory and contractual obligations.
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.
Once a CISO/CIO/CPO has defined the prioritization and applicable compliance requirements, it is necessary to parse the SCF’s controls
catalog and then identify maturity targets for those applicable controls:
The most efficient manner we can recommend would be to first look at the thirty-two domains that make up the SCF and assign a high-
level CMM level target for each domain. These domains are well-summarized in the SCF’s free Security & Privacy by Design Principles
(SIP) document and can be used by a CISO/CIO/CPO to quickly align a maturity target to each domain, in accordance with previously-
established prioritization and business needs.
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.
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.
SP-CMM 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 privacy by default and by design. In order to determine what is
appropriate and to evaluate it prior to “go live” it necessitates expectations for control maturity to be defined.
Considerations
Referencing back to the SP-CMM Overview section of this document, CMM 0-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
CMM 2-4 to identify the reasonable people, processes and technologies that need to be incorporated into the solution.
As previously-covered, 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 the expectations are that security and
privacy controls are applied throughout the SDLC.
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 CMM 2-3 for planning purposes.
Identifying A Solution
While there are approximately 870 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 and it can be easily done on the Customize The SCF page on the SCF website. 3 Additionally, this step can also be
done within Excel or within a GRC solution. In the end, the result is a tailored set of controls that meet 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.
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.
SP-CMM USE CASE #3 – PROVIDE OBJECTIVE CRITERIA TO EVALUATE THIRD-PARTY SERVICE PROVIDER SECURITY
It is now commonplace for Third-Party Service Providers (TSPs), including vendors and partners, to be contractually bound to implement
and manage a baseline set of cybersecurity and privacy controls. This necessitates oversight of TSPs to ensure controls are properly
implemented and managed.
One of the issues with managing TSPs 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 TSP. The SP-CMM can be used to obtain more nuanced answers from
TSPs by having those TSPs select from CMM 0-5 to answer if the control is implemented and how mature the process is.
Considerations
Referencing back to the SP-CMM Overview section of this document, CMM 0-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
CMM 2-4 to identify the reasonable people, processes and technologies that need TSPs 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 a TSP management
perspective, this is often going to limit target CMM levels to CMM 2-3 for most organizations.
TSP controls are expected to cover both your internal requirements, as well as external requirements from applicable laws, regulations
and contracts. Using the SP-CMM can be an efficient way to provide a level of quality control over TSP practices. Being able to
demonstrate proper cybersecurity and privacy practices is built upon the security principles of protecting the confidentiality, integrity,
availability and safety of your assets, including data.
Identifying A Solution
While there are approximately 870 controls in the SCF’s controls catalog, it is necessary to pare down that catalog to only what is
applicable to that specific TSP’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 and it can be easily done on the Customize The SCF page
on the SCF website. 4 Additionally, this step can also be done within Excel or within a GRC solution. In the end, the result is a tailored set
of controls that address the TSP’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 TSP. Ideally, the TSP 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 TSP-specific controls is appropriate.
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.
SECTION 5: WAYS TO OPERATIONALIZE A CONTROL SET
We want companies to really get the maximum use from the SCF. We know that organizations from the Fortune 500 down to small
businesses use the SCF, so it is very scalable and is flexible enough to support nearly any industry’s cybersecurity and privacy needs.
The biggest issue comes down to the “Now what?” question, once an organization has a wonderful control set that provides a
comprehensive list of their cybersecurity and privacy requirements.
NOW WHAT? I’VE GOT A CONTROL SET, BUT WHAT DO I DO WITH IT?
If you are a small company with a limited budget and staff, it makes the most sense to work from the Excel version of the SCF. We’ve
seen people import it into Microsoft Access databases and even turn it into internally-facing intranet webpages. This really comes down
to the creativity and time you have to make it fit your needs.
For medium and large organizations, it really doesn’t make sense to use Excel. This is where buying a Governance, Risk & Compliance
(GRC) or Integrated Risk Management (IRM) solution makes the most sense.
If you currently use a GRC/IRM, then your next step would be talking with your GRC/IRM admin to import the SCF into your
instance.
If you do not currently have a GRC/IRM but are in the process of getting one, your next step would be talking with the
professional services or pre-sales engineering team about importing the SCF into your future instance.
We’ve had SCF users report using the SCF with nearly all of the well-known GRC/IRM platforms, since it is expected for these tools to
allow for the importing of a customized control set. Several of those GRC/IRM platforms are listed here:
https://www.securecontrolsframework.com/scf-solution-providers
ComplianceForge
https://www.complianceforge.com
support@complianceforge.com
+1-855-205-8437
23 of 23
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.