DSP Recommended Practices
DSP Recommended Practices
version 2023.3
Disclaimer: This document is provided for educational purposes only. This document does not render professional services and
is not a substitute for professional services. If you have compliance questions, you are encouraged to consult a competent
cybersecurity and/or data privacy professional.
Table of Contents
Executive Summary ...................................................................................................................................................... 4
Defining What It Means To Be “Secure & Compliant” .................................................................................................... 5
Documentation Included In The DSP ............................................................................................................................. 6
Section 1: Understanding The DSP................................................................................................................................. 8
Understanding The Terminology of the DSP .............................................................................................................................................. 8
Why You Should Care About Terminology ................................................................................................................................................. 8
Hierarchical Cybersecurity Governance Framework (HCGF) ..................................................................................................................... 9
What “Right” Looks Like ............................................................................................................................................................................ 9
What “Wrong” Looks Like ........................................................................................................................................................................ 10
Section 2: High-Level Steps To Using The DSP .............................................................................................................. 11
Step 1: Familiarize Yourself With The DSP & Supplemental Documentation .......................................................................................... 11
Step 2: Identify All Applicable Compliance Requirements ....................................................................................................................... 11
Step 3: Identify Standards That Do Not Apply To Your Business Model .................................................................................................. 11
Step 4: Customize The DSP Based On Your Unique Needs ...................................................................................................................... 11
Step 5: Coordinate With Stakeholders For A Rollout ............................................................................................................................... 11
Step 6: Monitor & Made Changes As Needed ......................................................................................................................................... 12
Section 3: Understanding The SCF ............................................................................................................................... 13
Why Should I Use The SCF?...................................................................................................................................................................... 13
What The SCF Is ....................................................................................................................................................................................... 13
What The SCF Is Not................................................................................................................................................................................. 13
Designing & Building An Audit-Ready Cybersecurity & Data Privacy Program ........................................................................................ 14
Section 4: Adopting “Secure by Design” Principles ....................................................................................................... 15
Secure Practices Are Common Expectations ........................................................................................................................................... 15
Compliance Should Be Viewed As A Natural Byproduct of Secure Practices........................................................................................... 15
Cybersecurity & Data Privacy by Design (C|P) Principles ........................................................................................................................ 16
Steps To Operationalize The C|P Principles ......................................................................................................................................... 16
SCF Domains & C|P Principles .............................................................................................................................................................. 16
Section 5: Understanding What It Means To Adopt “Privacy by Design” Principles ....................................................... 21
Data Privacy Practices Are Common Expectations .................................................................................................................................. 21
Section 6: Tailoring The DSP & SCF For Your Needs ...................................................................................................... 23
Tailoring Is Required - Not All SCF Controls Are Applicable To Your Organization .................................................................................. 23
Statutory Requirements ....................................................................................................................................................................... 23
Regulatory Requirements..................................................................................................................................................................... 24
Contractual Requirements ................................................................................................................................................................... 24
What Are Your Applicable Statutory, Regulatory and Contractual Requirements? ................................................................................ 24
Customizing The Control Set: Use Excel To Manually Filter Controls ................................................................................................... 24
Section 7: Identifying A Target Maturity Level To Define What “Right” Looks Like ........................................................ 26
Cybersecurity & Data Privacy Capability Maturity Model (C|P-CMM) .................................................................................................... 26
C|P-CMM 0 – Not Performed ............................................................................................................................................................... 27
C|P-CMM 1 – Performed Informally .................................................................................................................................................... 27
C|P-CMM 2 – Planned & Tracked ........................................................................................................................................................ 27
C|P-CMM 3 – Well-Defined .................................................................................................................................................................. 28
C|P-CMM 4 – Quantitatively Controlled .............................................................................................................................................. 28
C|P-CMM 5 – Continuously Improving................................................................................................................................................. 28
Summary of CCM vs Organization Size Considerations........................................................................................................................ 30
Use Case #1 – Objective Criteria To Build A Cybersecurity & Privacy Program ....................................................................................... 31
Identifying The Problem ....................................................................................................................................................................... 31
Considerations ..................................................................................................................................................................................... 31
Identifying A Solution ........................................................................................................................................................................... 32
Use Case #2 – Assist Project Teams To Appropriately Plan & Budget Secure Practices .......................................................................... 33
Identifying The Problem ....................................................................................................................................................................... 33
Considerations ..................................................................................................................................................................................... 33
Identifying A Solution ........................................................................................................................................................................... 33
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
Use Case #3 – Provide Objective Criteria To Evaluate Third-Party Service Provider Security ................................................................. 34
Identifying The Problem ....................................................................................................................................................................... 34
Considerations ..................................................................................................................................................................................... 34
Identifying A Solution ........................................................................................................................................................................... 34
Use Case #4 – Due Diligence In Mergers & Acquisitions (M&A) .............................................................................................................. 35
Identifying The Problem ....................................................................................................................................................................... 35
Considerations ..................................................................................................................................................................................... 35
Identifying A Solution ........................................................................................................................................................................... 35
Understanding Key Cybersecurity Terminology............................................................................................................ 37
Policy / Security Policy ............................................................................................................................................................................. 37
Control Objective ..................................................................................................................................................................................... 37
Standard................................................................................................................................................................................................... 38
Guideline / Supplemental Guidance ........................................................................................................................................................ 38
Control ..................................................................................................................................................................................................... 38
Assessment Objective (AO) ...................................................................................................................................................................... 39
Procedure................................................................................................................................................................................................. 39
Threat ....................................................................................................................................................................................................... 39
Risk ........................................................................................................................................................................................................... 40
Metric....................................................................................................................................................................................................... 40
Risk Register / Plan of Action & Milestones (POA&M) ............................................................................................................................ 41
System Security Plan (SSP) / System Cybersecurity & Data Privacy Plan (SSPP)...................................................................................... 41
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
EXECUTIVE SUMMARY
In order to help you maximize the value of the DSP, we want to properly orient you to the documentation you are receiving as part of
this purchase, so that you can easily find what you are looking for.
Keep in mind the DSP is a tool, so just like a hammer or screwdriver there are right ways and wrong ways to use it. We want you to build
something great with this tool, so we are providing this guidance to help you on the right path. If you do get stuck or have some questions,
please reach out to us at support@complianceforge.com since we are happy to help answer any product-related questions you have.
Using the DSP 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 DSP helps implement a holistic approach to protecting the
Confidentiality, Integrity, Availability and Safety (CIAS) of your data, systems, applications and other processes. The DSP 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 & Data Privacy practitioners to gain an understanding of how the DSP and SCF are intended
to be used in their organization. The following topics are addressed:
Level setting what the DSP and Secure Controls Framework (SCF) are and what they are not;
Recommendations to tailor the DSP and SCF for your needs;
Leveraging the Cybersecurity & Data Privacy Capability Maturity Model (C|P-CMM); and
Ways to operationalize the DSP and SCF.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
DEFINING WHAT IT MEANS TO BE “SECURE & COMPLIANT”
It is important 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 needs to categorize its
applicable controls 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.
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 establish
the foundational floor that must be adhered to, DSR are where organizations often achieve improved efficiency, automation
and enhanced security.
ComplianceForge helped develop the Integrated Controls Management (ICM) model to help streamline the traditional “governance, risk
management & compliance” functions. 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
8. Evolve Processes
The ICM is very much worth your time to familiarize yourself with: https://www.complianceforge.com/grc/integrated-controls-
management/
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
DOCUMENTATION INCLUDED IN THE DSP
The following documentation is part of the DSP:
Word Documents
Digital Security Program (DSP)
o This is the core DSP in Microsoft Word format that contains the policies, control objectives, standards and guidelines.
DSP Supplemental - Annexes Forms & References o This contains a lot of useful templates and references.
o Most important in this document are the Annexes that provide invaluable information to implement and maintain the
DSP:
Annex 1: Data Classification & Handling Guidelines
Annex 2: Data Classification Examples
Annex 3: Data Retention Periods
Annex 4: Baseline Security Categorization Guidelines
Annex 5: Rules of Behavior (Acceptable & Unacceptable Use)
Annex 6: Guidelines for Personal Use of Organizational IT Resources
Annex 7: Risk Management Framework (RMF)
Annex 8: System Hardening
Annex 9: Safety Considerations With Embedded Technology
Annex 10: Indicators of Compromise (IoC)
Errata – DSP
o This document contains version change information (errata).
Excel Document
Digital Security Program (DSP) - Framework Mapping-Controls-Metrics-DB Export
o This Excel spreadsheet contains multiple tabs and is where you will find the mapping from the DSP to other frameworks.
o The most important tabs to familiar yourself with are:
DSP Domains & Principles
Authoritative Sources
DSP Framework Mapping
Metrics, KRIs & KPIs
PowerPoint Documents
Cybersecurity Awareness Training o This is an optional reference that can be used to build a training presentation.
Data Classification Icons o This contains editable data classification icons.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
PDF Documents
Posters - How To GRC (Governance, Risk & Compliance)
o This reference contains a wealth of information that is well worth your time to read through.
o If you have a plotter, you can print the pages out as poster-sized documents for user education and awareness.
Instructions & Best Practices For Using The Digital Security Program (DSP)
o This is your place to start.
o This guide helps explain how to use the DSP.
Instructions & Overview - SCF Cybersecurity & Data Privacy Capability Maturity Model (C|P-CMM)
o This guide covers the C|P-CMM.
o The C|P-CMM is included within the Excel spreadsheet.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
SECTION 1: UNDERSTANDING THE DSP
The Digital Security Program (DSP) is a template that is meant to provide the foundation for your cybersecurity program by consolidating
your cybersecurity policies, control objectives, standards and guidelines into one document. This makes managing your cybersecurity
documentation more efficient by reducing “boilerplate text” and also is much easier for users to find the information they are looking
for, as compared to searching multiple, standalone policy documents.
Given the difficult nature of writing templated policies and standards, we aimed for
approximately a "90 to 95% solution" since we feel that customization is absolutely necessary
to make it specific to your organization’s needs. The reason for that is pretty clear - every
organization has different compliance requirements, available resources, technologies in use,
and a unique corporate culture so no one set of templatized policies and standards can be
100% equally applied across multiple organizations.
ComplianceForge did the heavy lifting and it is up to you, as the client, to provide the final
customization that is necessary to make it specific to your organization.
con·trol / kǝn’trōl – According to ISACA, “internal controls” include the policies, standards, procedures and other
organizational structures that are designed to provide reasonable assurance that business objectives will be achieved and
undesired events will be prevented, detected and corrected. Essentially, governance over these controls is the power to
influence or direct people’s behavior or the course of events.
To help visualize that concept, imagine the board of directors of your organization publishing procedural process guidance for how a
security analyst performs daily log review activities. Most would agree that such a scenario is absurd since the board of directors should
be focused on the strategic direction of the company and not day-to-day procedures.
However, in many organizations, the inverse occurs where the task of publishing the entire range of cybersecurity documentation is
delegated down to individuals who might be competent technicians but do not have insights into the strategic direction of the
organization. This is where the concept of hierarchical documentation is vitally important since there are strategic, operational, and
tactical documentation components that have to be addressed to support governance functions.
Please reference the Understanding Key Terminology Section to better understand the leading practices’ definitions of policies,
standards, controls, etc. That understanding is useful when viewing how the DSP is created to make a scalable, hierarchical solution for
cybersecurity and privacy documentation.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
HIERARCHICAL CYBERSECURITY GOVERNANCE FRAMEWORK (HCGF)
ComplianceForge Hierarchical Cybersecurity Governance
Framework™ (HCGF) takes a comprehensive view towards the
necessary documentation components that are key to being able
to demonstrate evidence of due diligence and due care. This
framework addresses the interconnectivity of policies, control
objectives, standards, guidelines, controls, risks, procedures &
metrics. The Secure Controls Framework (SCF) fits into this model
by providing the necessary cybersecurity and privacy controls an
organization needs to implement to stay both secure and
compliant.
A picture is sometimes worth 1,000 words – this concept can be seen here the swim lane diagram shown on the right. This is also included
in the “supplemental documentation” folder.
Note: Procedures are not a part of the DSP, but are available as part of the Cybersecurity Standardized Operating Procedures (CSOP)
product available through ComplianceForge.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
WHAT “WRONG” LOOKS LIKE
All too often, documentation is not scoped properly and this leads to the governance function being more of an obstacle, as compared
to an asset. A multiple-page “policy” document that blends high-level security concepts (e.g., policies), configuration requirements (e.g.,
standards), and work assignments (e.g., procedures) is an example of poor governance documentation that leads to confusion and
inefficiencies across technology, cybersecurity, and privacy operations.
Several reasons why this form of “policy” document is considered poorly-architected documentation include:
Human nature is always the mortal enemy of unclear documentation, as people will not take the time to read it. An ignorant or
ill-informed workforce entirely defeats the premise of having the documentation in the first place.
If the goal is to be “audit ready” with documentation, having excessively-wordy documentation is misguided. Excessive prose
that explains concepts ad nauseum in paragraph after paragraph makes it very hard to understand the exact requirements, and
that can lead to gaps in compliance.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
SECTION 2: HIGH-LEVEL STEPS TO USING THE DSP
The steps below are recommended, based on years of helping companies implement ComplianceForge documentation products:
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
make sense).
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
SECTION 3: UNDERSTANDING THE SCF
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 less
than 750 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.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
DESIGNING & BUILDING AN AUDIT-READY CYBERSECURITY & DATA PRIVACY PROGRAM
Building an audit-ready Cybersecurity & Data 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!
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
SECTION 4: 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 cybersecurity & data 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 over 1,000 cybersecurity & data privacy controls is categorized into thirty-three (33) domains that are
mapped to over 110 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) 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.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
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.
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:
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
Govern the current and future capacities Organizations prevent avoidable business
and performance of technology assets. interruptions caused by capacity and
Capacity & performance limitations by proactively
5 Performance CAP planning for growth and forecasting, as well
Planning 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 and
ongoing manner that involves active business leadership proactively manage
participation from both technology and change, including the assessment,
Change
6 CHG business stakeholders to ensure that only authorization and monitoring of technical
Management
authorized changes occur. changes across the enterprise so as to not
impact production systems uptime and allow
easier troubleshooting of issues.
Govern cloud instances as an extension of Organizations govern the use of private and
on-premise technologies with equal or public cloud environments (e.g., IaaS, PaaS
greater security protections than the and SaaS) to holistically manage risks
7 Cloud Security CLD organization’s own internal cybersecurity associated with third-party involvement and
& data privacy controls. 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 place to
data privacy controls to ensure ensure adherence to applicable statutory,
appropriate evidence required due care regulatory and contractual compliance
8 Compliance CPL
and due diligence exists to meet obligations, as well as internal company
compliance with applicable statutory, standards.
regulatory and contractual obligations.
Enforce secure configurations for systems, Organizations establish and maintain the
applications and services according to integrity of systems. Without properly
vendor-recommended and industry- documented and implemented configuration
Configuration recognized secure practices. management controls, security features can
9 CFG
Management be inadvertently 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 the
centralized collection and analysis of enterprise through the centralized collection
event logs from systems, applications and and review of security-related event logs.
services. Without comprehensive visibility into
Continuous infrastructure, operating system, database,
10 MON
Monitoring 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.
Utilize appropriate cryptographic solutions Organizations ensure the confidentiality and
and industry-recognized key management integrity of its data through implementing
Cryptographic
11 CRY practices to protect the confidentiality appropriate cryptographic technologies to
Protections
and integrity of sensitive/regulated data protect systems, applications, services and
both at rest and in transit. data.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
Enforce a standardized data classification Organizations ensure that technology assets,
methodology to objectively determine the both electronic and physical, are properly
sensitivity and criticality of all data and classified and measures implemented to
technology assets so that proper handling protect the organization’s data from
Data and disposal requirements can unauthorized disclosure, or modification,
12 Classification & DCH be followed. regardless 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 the Organizations specify the development,
risks associated with embedded proactive management and ongoing review
technology, based on the potential of security embedded technologies,
Embedded damages posed from malicious use of the including hardening of the “stack” from the
13 EMB
Technology technology. hardware, 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 devices
against reasonable threats to those are appropriately protected from security
devices and the data those devices store, threats to the device and its data. Applicable
Endpoint transmit and process. statutory, regulatory and contractual
14 END
Security 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 & data
Human ongoing personnel management to privacy-minded workforce and an
15 Resources HRS cultivate a cybersecurity & data privacy- environment that is conducive to innovation,
Security minded workforce. considering issues such as culture, reward
and collaboration.
Enforce the concept of “least privilege” Organizations implement the concept of
consistently across all systems, “least privilege” through limiting access to
Identification & applications and services for individual, the organization’s systems and data to
16 IAC
Authentication group and service accounts through a authorized users only.
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 to viable and tested capability to respond to
recognize and report suspicious activities cybersecurity or data privacy-related
Incident
17 IRO so that trained incident responders can incidents in a timely manner, where
Response
take the appropriate steps to handle organizational personnel understand how to
incidents, in accordance with a detect and report potential incidents.
documented Incident Response Plan (IRP).
Execute an impartial assessment process Organizations ensure the adequately of
to validate the existence and functionality cybersecurity & data privacy controls in
Information of appropriate cybersecurity & data development, testing and production
18 IAO
Assurance privacy controls, prior to a system, environments.
application or service being used in a
production environment.
Proactively maintain technology assets, Organizations ensure that technology assets
according to current vendor are properly maintained to ensure continued
19 Maintenance MNT recommendations for configurations and performance and effectiveness.
updates, including those supported or Maintenance processes apply additional
hosted by third-parties.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
scrutiny to the security of end-of-life or
unsupported assets.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
Execute the delivery of cybersecurity & Organizations ensure appropriate resources
data privacy operations to provide quality and a management structure exists to
Security
27 OPS services and secure systems, applications enable the service delivery of cybersecurity,
Operations
and services that meet the organization's physical security and data privacy
business needs. operations.
Foster a cybersecurity & data privacy- Organizations develop a cybersecurity &
Security minded workforce through ongoing user data privacy-minded workforce through
28 Awareness & SAT education about evolving threats, continuous education activities and practical
Training compliance obligations and secure exercises.
workplace practices.
Develop and test systems, applications or Organizations ensure that cybersecurity &
services according to a Secure Software data privacy principles are implemented into
Technology
Development Framework (SSDF) to reduce any products/solutions, either developed
29 Development & TDA
the potential impact of undetected or internally or acquired, to make sure that the
Acquisition
unaddressed vulnerabilities and design concepts of “least privilege” and “least
weaknesses. functionality” are incorporated.
Execute Supply Chain Risk Management Organizations ensure that cybersecurity &
(SCRM) practices so that only trustworthy data privacy risks associated with third-
Third-Party third-parties are used for products and/or parties are minimized and enable measures
30 TPM
Management service delivery. 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 assets proactively identify and manage technology-
Threat
31 THR and business processes, to determine the related threats to the cybersecurity & data
Management
applicable risk and necessary corrective privacy of the organization’s systems, data
action. and business processes.
Leverage industry-recognized Attack Organizations proactively manage the risks
Vulnerability & Surface Management (ASM) practices to associated with technical vulnerability
32 Patch VPM strengthen the security and resilience management that includes ensuring good
Management systems, applications and services against patch and change management practices are
evolving and sophisticated attack vectors. utilized.
Ensure the security and resilience of Organizations address the risks associated
Internet-facing technologies through with Internet-accessible technologies by
33 Web Security WEB secure configuration management hardening devices, monitoring system file
practices and monitoring for anomalous integrity, enabling auditing, and monitoring
activity. for malicious activities.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
SECTION 5: 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 is 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. 1
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.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
NIST SP 800-53 R4
NIST SP 800-53 R5
NIST Privacy Framework v1.0
Organization for Economic Co-operation and Development (OECD)
Office of Management and Budget (OMB) - Circular A-130
Personal Information Protection and Electronic Documents Act (PIPEDA)
We took these frameworks and looked for similarities and also for gaps. If you download the SCF Data Privacy Management Principles,
you will see the direct mapping to these leading privacy frameworks so you know the origin of the principle we include in our document.
This will be a great tool for organizations that may have to address multiple requirements, since 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
11. Business Environment
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
SECTION 6: TAILORING THE DSP & SCF FOR YOUR NEEDS
Some people freak out and think they have to do 1,000+ 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 1,000+ 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.
Beyond just using compliance terminology properly, understanding which of the three types of compliance is crucial in managing both
cybersecurity and 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 you can present issues of non-compliance in a compelling business context to get the
resources you need to do your job.
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, such as the HITECH Act, which provided updates to the two-
decades-old HIPAA.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
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.
CONTRACTUAL REQUIREMENTS
Contractual obligations are required by legal contract between private parties. This may be as simple as a cybersecurity or privacy
addendum in a vendor contract that calls out unique requirements. It also includes broader requirements from an industry association
that membership brings certain obligations.
From a cybersecurity and privacy perspective, common contractual compliance requirements include:
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)
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!
As previously mentioned, the Integrated Controls Management (ICM) model is a methodology that an organization can use categorize
its applicable controls according to “must have” vs “nice to have” requirements:
Minimum Compliance Criteria (MCR) are the absolute minimum requirements that must be addressed to comply with
applicable laws, regulations and contracts.
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.
Minimum Security Requirements (MSR) is the resulting set of controls necessary to be “compliant and secure” to manage your
organization’s cybersecurity and privacy program.
There is a column that exists in the SCF/DSP to help with this task and is call the “Minimum Security Requirements (MSR) Filter” that will
assist you in this process.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
Follow these steps:
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).
2. 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).
3. In that MCR column, simply put an “x” to mark that control as being
“must have” controls. In the DSR column, simply put an “x” to mark that
control as being “nice to have” controls. A selection of either MCR or DSR
will select MSR. Do this for all the rows shown in that column.
4. Unfilter the column you just performed this task on and do it to the next
law, regulation or framework that you need to map.
5. Repeat step 3 and step 4 until all your applicable laws and regulations are
mapped to.
6. The MSR 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.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
SECTION 7: 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 C|P-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 C|P-CMM 1 and C|P-CMM 2. The reason for this is at C|P-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 C|P-CMM
3. Oversight and process automation can decrease risk, but generally not as noticeably as steps taken to attain C|P-CMM 3.
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 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).
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
The six C|P-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 C|P-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.
C|P-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. C|P-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 C|P-CMM 2 practices focus more on compliance over security. The reason for this is the scoping of C|P-CMM 2
practices are narrowly-focused and are not organization-wide.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
C|P-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 C|P-CMM 2 practices that are narrowly focused, C|P-CMM 3 practices are standardized
across the organization.
It can be argued that C|P-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.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
Continuous process improvement against these goals is enabled by quantitative feedback from performing the defined
processes and from piloting innovative ideas and technologies.
C|P-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 C|P-CMM 5.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
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.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
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.
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 restrictions. One
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
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
Defining a target maturity state is Step 4 in the Integrated Controls Management (ICM) model is 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.
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 Cybersecurity & Data Privacy by Design
Principles (CIP) 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.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
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. 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 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 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 L2-3 for planning purposes.
IDENTIFYING A SOLUTION
While there are over 1,000 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.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
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 data 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 C|P-CMM can be used to obtain more nuanced answers from
TSPs by having those TSPs 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 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 L2-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 C|P-CMM can be an efficient way to provide a level of quality control over TSP 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.
IDENTIFYING A SOLUTION
While there are over 1,000 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. 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 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.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
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.
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)
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
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
ISO 31010
NIST 800-160
NIST Cybersecurity Framework
OWASP Top 10
UL 2900-1
EU GDPR
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
UNDERSTANDING KEY CYBERSECURITY TERMINOLOGY
This section is intended to help standardize cybersecurity and data privacy documentation-related terminology based on definitions from
leading authorities (e.g., NIST, ISO, ISACA, AICPA, etc.). In compliance operations, words have meanings. Therefore, it is important to
provide examples from industry-recognized sources for the proper use of these terms that make up cybersecurity & data privacy
documentation. Simply because an individual has used terminology in a specific manner for past decade (e.g., policy), that does not mean
that is correct terminology usage, based on authoritative sources. ComplianceForge took the time to compile authoritative definitions
from multiple sources to defend the proper usage that ComplianceForge applies to its documentation structure.
Unfortunately, for many IT/cybersecurity professionals, when they refer to a “policy” they really mean “standard.” This common misuse
of critical documentation components can create a significant amount of confusion, since those are not interchangeable terms. Standards
are subordinate to policies and standards address the granular requirements needed to satisfy a policy. Therefore, a 1-3 sentence policy
statement is acceptable to capture a “high-level statement of management intent” for a specific domain.
It is expected to have multiple policies to address cybersecurity and data privacy needs (e.g., access control, data handling, etc.).
Policies address the strategic needs of the organization.
There is never a justifiable reason to have an exception to a policy. Exceptions should only be at the standard or procedure level.
ISACA Glossary:
o A document that records a high-level principle or course of action that has been decided on.
o The intended purpose is to influence and guide both present and future decision making to be in line with the
philosophy, objectives and strategic plans established by the enterprise’s management teams.
o Overall intention and direction as formally expressed by management.
ISO 704:2009:
o Any general statement of direction and purpose designed to promote the coordinated planning, practical acquisition,
effective development, governance, security practices, or efficient use of information technology resources.
ISO 27000:2016:
o Intention and direction of an organization as formally expressed by its top management.
NIST Glossary (Policy):
o Statements, rules or assertions that specify the correct or expected behavior of an entity.
o A statement of objectives, rules, practices or regulations governing the activities of people within a certain context.
NIST Glossary (Security Policy):
o Security policies define the objectives and constraints for the security program. Policies are created at several levels,
ranging from organization or corporate policy to specific operational constraints (e.g., remote access). In general,
policies provide answers to the questions “what” and “why” without dealing with “how.” Policies are normally stated
in terms that are technology-independent.
o A set of rules that governs all aspects of security-relevant system and system element behavior.
Note 1: System elements include technology, machine, and human, elements.
Note 2: Rules can be stated at very high levels (e.g., an organizational policy defines acceptable behavior of
employees in performing their mission/business functions) or at very low levels (e.g., an operating system
policy that defines acceptable behavior of executing processes and use of resources by those processes).
CONTROL OBJECTIVE
Control Objectives are targets or desired conditions to be met. These are statements describing what is to be achieved as a result of the
organization implementing a Control, which is what a Standard is intended to address with organization-specific criteria.
Where applicable, Control Objectives are directly linked to laws, regulations and frameworks to align cybersecurity and data privacy with
reasonably-expected practices. The intent is to establish sufficient evidence of due diligence and due care to withstand scrutiny (e.g.,
external audits/assessments) to disprove potential accusations of negligence.
ISACA Glossary:
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
o A statement of the desired result or purpose to be achieved by implementing control procedures in a particular process.
ISO 27000:2016:
o Statement describing what is to be achieved as a result of implementing controls.
AICPA SSAE No. 18, Attestation Standards Clarification and Recodification:
o The aim or purpose of specified controls at the organization. Control objectives address the risks that controls are
intended to mitigate.
STANDARD
Standards are mandatory requirements regarding processes, actions and configurations that are designed to satisfy Controls and Control
Objectives. Standards are intended to be granular and prescriptive to ensure systems, applications and services are designed and
operated to include appropriate cybersecurity and data privacy protections.
ISACA Glossary:
o A mandatory requirement.
NIST Glossary:
o A published statement on a topic specifying the characteristics, usually measurable, that must be satisfied or achieved
to comply with the standard.
o A rule, condition, or requirement describing the following information for products, systems, services or practices:
Classification of components.
Specification of materials, performance, or operations; or
Delineation of procedures.
ISACA Glossary:
o A description of a particular way of accomplishing something that is less prescriptive than a procedure.
ISO 704:2009:
o Recommendations suggesting, but not requiring, practices that produce similar, but not identical, results.
o A documented recommendation of how an organization should implement something.
NIST Glossary:
o Statements used to provide additional explanatory information for security controls or security control enhancements.
CONTROL
Controls are technical, administrative or physical safeguards. Controls are the nexus used to manage risks through preventing, detecting
or lessening the ability of a particular threat from negatively impacting business processes.
Controls directly map to Standards, Procedures and Control Objectives. Control testing is designed to measure specific aspects of how
Standards are actually implemented and if the Control / Control Objective is sufficiently addressed.
ISACA Glossary:
o The means of managing risk, including policies, procedures, guidelines, practices or organizational structures, which
can be of an administrative, technical, management, or legal nature.
ISO 27000:2016:
o The policies, procedures, practices and organizational structures designed to provide reasonable assurance that
business objectives will be achieved and undesired events will be prevented or detected and corrected.
o Measure that is modifying risk:
Controls include any process, policy, device, practice, or other actions which modify risk.
Controls may not always exert the intended or assumed modifying effect.
NIST Glossary:
o Measure that is modifying risk. (Note: controls include any process, policy, device, practice, or other actions which
modify risk.)
NIST SP 800-53 R5:
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
o The safeguards or countermeasures prescribed for an information system or an organization to protect the
confidentiality, integrity, and availability of the system and its information [security control].
o The administrative, technical, and physical safeguards employed within an agency to ensure compliance with
applicable data privacy requirements and manage data privacy risks [privacy control].
NIST Glossary:
o A set of determination statements that expresses the desired outcome for the assessment of a security control, privacy
control, or control enhancement.
PROCEDURE
Procedures are a documented set of steps necessary to perform a specific task or process in conformance with an applicable standard.
Procedures help address the question of how the organization actually operationalizes a Policy, Standard or Control.
Without documented procedures, there can be defendable evidence of due care practices. Procedures are generally the responsibility
of the process owner / asset custodian to build and maintain but are expected to include stakeholder oversight to ensure applicable
compliance requirements are addressed. The result of a procedure is intended to satisfy a specific control. Procedures are also commonly
referred to as “control activities.”
ISACA Glossary:
o A document containing a detailed description of the steps necessary to perform specific operations in conformance
with applicable standards. Procedures are defined as part of processes.
ISO 704:2009:
o A detailed description of the steps necessary to perform specific operations in conformance with applicable standards.
o A group of instructions in a program designed to perform a specific set of operations.
NIST Glossary:
o A set of instructions used to describe a process or procedure that performs an explicit operation or explicit reaction to
a given event.
THREAT
Threats represents a person or thing likely to cause damage or danger.
Natural and man-made threats affect control execution (e.g., if the threat materializes, will the control function as expected?). Threats
exist in the natural world that can be localized, regional or worldwide (e.g., tornados, earthquakes, solar flares, etc.). Threats can also be
man-made (e.g., hacking, riots, theft, terrorism, war, etc.).
ISACA Glossary:
o Anything (e.g., object, substance, human) that is capable of acting against an asset in a manner that can result in harm.
ISO 13335-1:
o A potential cause of an unwanted incident.
NIST Glossary:
o Threat: Any circumstance or event with the potential to adversely impact organizational operations (including mission,
functions, image, or reputation), organizational assets, or individuals through an information system via unauthorized
access, destruction, disclosure, modification of information, and/or denial of service. Also, the potential for a threat-
source to successfully exploit a particular information system vulnerability.
o Cyberthreat: Any circumstance or event with the potential to adversely impact organizational operations (including
mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through
an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of
service.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
RISK
Risks represents a potential exposure to danger, harm or loss.*
Risk is associated with a control deficiency (e.g., If the control fails, what risk(s) is the organization exposed to?). Risk is often calculated
by a formula of the Occurrence Likelihood (OL) (e.g., probability of the event) x the Impact Effect (IE) (e.g., potential, negative
consequences) in an attempt to quantify the potential magnitude of a risk instance materializing.
While it is not possible to have a totally risk-free environment, it may be possible to manage risks by avoiding, reducing, transferring, or
accepting the risks.
ISACA Glossary:
o The combination of the probability of an event and its consequence.
ISO 704:2009:
o The level of impact on organizational operations (including mission, functions, image, or reputation), organizational
assets, individuals, other organizations, or the Nation resulting from the operation of an information system given the
potential impact of a threat and the likelihood of that threat occurring.
NIST SP 800-53 R5:
o A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically is a function
of:
The adverse impact, or magnitude of harm, that would arise if the circumstance or event occurs; and
The likelihood of occurrence.
NIST Glossary:
o A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function
of:
The adverse impacts that would arise if the circumstance or event occurs; and
The likelihood of occurrence. Information system-related security risks are those risks that arise from the loss
of confidentiality, integrity, or availability of information or information systems and reflect the potential
adverse impacts to organizational operations (including mission, functions, image, or reputation),
organizational assets, individuals, other organizations, and the Nation.
METRIC
Metrics provide a “point in time” view of specific, discrete measurements, unlike trending and analytics that are derived by comparing a
baseline of two or more measurements taken over a period of time.
Analytics are generated from the analysis of metrics. Analytics are designed to facilitate decision-making, evaluate performance and
improve accountability through the collection, analysis and reporting of relevant performance related metrics.
ISACA Glossary:
o A quantifiable entity that allows the measurement of the achievement of a process goal.
ISO 704:2009:
o A thing that is measured and reported to help with the management of processes, services, or activities.
NIST Glossary:
o Tools designed to facilitate decision making and improve performance and accountability through collection, analysis,
and reporting of relevant performance-related data.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.
SECURE BASELINE CONFIGURATIONS / HARDENING STANDARD
Secure baseline configurations (e.g., hardening standard) are technical in nature and specify the required configuration settings for a
defined technology platform.
NIST Glossary:
o A documented set of specifications for an information system, or a configuration item within a system, that has been
formally reviewed and agreed on at a given point in time, and which can be changed only through change control
procedures.
o A set of specifications for a system, or Configuration Item (CI) within a system, that has been formally reviewed and
agreed on at a given point in time, and which can be changed only through change control procedures. The baseline
configuration is used as a basis for future builds, releases, and/or changes.
NIST Glossary:
o Risk Register: A repository of risk information including the data understood about risks over time.
o Risk Register: A central record of current risks, and related information, for a given scope or organization. Current risks
are comprised of both accepted risks and risk that are have a planned mitigation path (e.g., risks to-be-eliminated as
annotated in a POA&M).
o POA&M: A document that identifies tasks that need to be accomplished. It details resources required to accomplish
the elements of the plan, milestones for meeting the tasks, and the scheduled completion dates for the milestones.
SYSTEM SECURITY PLAN (SSP) / SYSTEM CYBERSECURITY & DATA PRIVACY PLAN (SSPP)
A SSP/SSPP is a “living document” that summarizes protection mechanisms for a system or project. It is a documentation method used
to capture pertinent information in a condensed manner so that personnel can be quickly educated on the “who, what, when, where,
how & why” concepts pertaining to the security of the system or project. A SSP/SSPP is meant to reference an organization’s existing
policies, standards and procedures and is not a substitute for that documentation.
NIST Glossary:
o Formal document that provides an overview of the security requirements for an information system and describes the
security controls in place or planned for meeting those requirements.
Disclaimer: This document is provided for reference purposes only. This document does not render professional services and is not a
substitute for professional services. If you have compliance questions, you are encouraged to consult a cybersecurity professional.