0% found this document useful (0 votes)
179 views

DSP Recommended Practices

Uploaded by

eser
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
179 views

DSP Recommended Practices

Uploaded by

eser
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 41

GETTING STARTED WITH THE DIGITAL

SECURITY PROGRAM (DSP) & SECURE


CONTROLS FRAMEWORK (SCF)

version 2023.3

Copyright © 2023. Compliance Forge, LLC (ComplianceForge). All rights reserved.

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.

It is recommended that you start off with the following steps:


 Familiarizing yourself with the various documents listed below to gain a basic understanding of what they are (components are
listed on the next page)
 Read through the “Integrated Controls Management (ICM) Overview” PDF to get an understanding for “what right looks like”
from a documentation governance perspective since the structure described in the document is particular to how the DSP was
developed and how it is intended to be used for Governance, Risk & Compliance (GRC) operations (it is included in the
supplemental documentation & graphics folder).
 From there, follow the steps in this guide to identify how to scope / customize the DSP 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.
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/

[graphic can be downloaded from https://content.complianceforge.com/Plan-Do-Check-Act.pdf]

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)

 DSP Supplemental – Educational Reference On DSP Policies


o This is an optional reference/tool that you can use to help educate users on the DSP’s policies.
o The intent is this can be used as a handout or made into an Intranet webpage to educate all users on the policies.

 DSP Supplemental - Cybersecurity Roles & Responsibilities


o This is an optional reference for cybersecurity and privacy roles & responsibilities.
o This is based on the NIST NICE Cybersecurity Workforce Framework, the closest thing to a “best practice” for roles and
responsibilities.

 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.

 Best Practices for Using The Secure Controls Framework (SCF)


o This guide covers how to use the SCF.
o The SCF is included within the Excel spreadsheet.

 Guide To Writing Procedures


o This guide helps explain how to write procedures.
o If you need procedures, ComplianceForge sells the Cybersecurity Standardized Operating Procedures (CSOP).

 Unified Scoping Guide (USG)


o This guide is for organizations that need to address a wide range of sensitive / regulated data scoping considerations.

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.

UNDERSTANDING THE TERMINOLOGY OF THE DSP


Cybersecurity, IT professionals and legal professionals routinely abuse the terms “policy” and “standard” as if these words are
synonymous. In reality, these terms have quite different implications, and those differences should be kept in mind since the use of
improper terminology has cascading effects that can negatively impact the internal controls of an 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.

WHY YOU SHOULD CARE ABOUT TERMINOLOGY


Governance is built on words. Beyond just using terminology properly, understanding the meaning of these concepts is crucial in being
able to properly implement cybersecurity and privacy governance within an organization. An indicator of a well-run governance program
is the implementation of hierarchical documentation since it involves bringing together the right individuals to provide appropriate
direction based on the scope of their job function.

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.

ComplianceForge has simplified the concept of the hierarchical


nature of cybersecurity and privacy documentation in the
following downloadable diagram to demonstrate the unique
nature of these components, as well as the dependencies that exist.

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.

WHAT “RIGHT” LOOKS LIKE


Based on the hierarchical nature of documentation as shown in the HCGF, we believe the most efficient form of cybersecurity and privacy
documentation is scalable and concise. We avoid “rambling prose” that makes it difficult for users to find the exact requirements they
are looking for, since it is both efficient and provides a more accurate answer for the user.

Well-designed documentation is generally comprised of six (6) main parts:


1. Policies establish management’s intent;
2. Control Objectives identify leading practices (mapped to requirements from laws, regulations and frameworks);
3. Standards provide quantifiable requirements;
4. Controls identify desired conditions that are expected to be met (requirements from laws, regulations and frameworks);
5. Procedures / Control Activities establish how tasks are performed to meet the requirements established in standards and to
meet controls; and
6. Guidelines are recommended, but not mandatory.

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:

STEP 1: FAMILIARIZE YOURSELF WITH THE DSP & SUPPLEMENTAL DOCUMENTATION


 Make a pot of coffee (or your beverage of choice) and start reading through the documentation at a HIGH LEVEL so you can
familiarize yourself with the structure and content of the DSP. There is no getting around this step.
 Within the Supplemental Documentation folder that comes with the DSP, you will find several useful resources. Most
importantly, you will find an Excel spreadsheet that contains a mapping from the DSP’s standards to leading frameworks. This
spreadsheet will be important in the next step.

STEP 2: IDENTIFY ALL APPLICABLE COMPLIANCE REQUIREMENTS


 If you do no already have a crystal-clear understanding of the statutory, regulatory and contractual obligations that are
applicable to your organization, set up a meeting with your procurement and legal experts since those two stakeholders
generally know what requirements your organization is required to address.
 In the following section of this guide, there is a review on the differences between statutory, regulatory and contractual
requirements. This is important, since it can help you prioritize your efforts.

STEP 3: IDENTIFY STANDARDS THAT DO NOT APPLY TO YOUR BUSINESS MODEL


 When you know what is applicable to your organization, it is also possible to identify all those other standards in the DSP that
might not currently be applicable to your organization.
 For all the standards that are not required for a business need (e.g., meeting a statutory, regulatory or contractual obligation),
there are two main options:
o Option 1: Delete the standard that is not applicable (NOTE - this is NOT the preferred method)
o Option 2: Preface the standard that is not applicable to remove the standard from the general scope of requirements.
o with a statement such as:
 “As required to meet a business obligation, …”
 “Where technically feasible, …”
 “When sensitive/regulated data is being processed, stored and/pr transmitted, …”
 ComplianceForge’s opinion is that Option 2 is the preferred method, based on these reasons:
o If your requirements change, you simply remove the prefaced statement vs reworking the entire DSP.
o You maintain the structure and mapping of the DSP and SCF.

STEP 4: CUSTOMIZE THE DSP BASED ON YOUR UNIQUE NEEDS


 This is where you really get into the details to make the DSP specific to your organization.
 The DSP is an editable Word document – you can edit it for your needs.
 Given the understanding that out of the box the DSP is not customized specific to your organization, there is an expectation
that key stakeholders within your organization will want to review and make recommendations for edits to the DSP.
 Reviewing and editing the policies and standards is just part of good cybersecurity governance.

STEP 5: COORDINATE WITH STAKEHOLDERS FOR A ROLLOUT


 Once the policies and standards are reviewed and accepted, the next hurdle is rolling out the DSP.
 There are several options to rolling out the DSP:
o Option 1: Phased rollout (portions of the DSP are made applicable over time)
o Option 2: Direct rollover (at a certain date, the DSP is effective and replaces existing policies & standards)
o Option 3: Direct rollover with phased deadlines (similar to Option 2, but only “critical” standards are made effective
immediately and a phased timeline for compliance with other standards is established, where those pending standards
are viewed as guidance).
o Note: Generally, Option 2 is the most efficient and least-confusing way to roll out the DSP.
 A key point to remember is that the DSP should not be seen as punitive. On the contrary, rolling out the DSP should be seen as
a benefit to technology teams to help justify budget for new technology, processes and/or personnel.
 With any rollout, any standard that cannot be complied with needs to have a risk assessment performed and someone needs
to accept the risk associated with a standard not being met. This is a common governance process for evaluating requests for
exceptions to standards.
 There should NEVER be an exception to a POLICY, just a STANDARD (please review the section on terminology if that does not

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).

STEP 6: MONITOR & MADE CHANGES AS NEEDED


 There should be some form of annual review of policies and standards as part of your organization’s governance process.
 Ideally, Key Performance Indicators (KPIs) or other metrics will be used as part of the evaluation process to understand what
aspects are working well and others that need improvements.

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.

WHY SHOULD I USE THE SCF?


There is no sales pitch for using the SCF – it is a free resource so there is no financial incentive for us
to make companies use it. For companies that have just one 1-2 compliance requirements, the SCF
might be considered overkill for your needs. However, for companies that have 3+ compliance
requirements (e.g., organization that has requirements to address ISO 27002, SOC 2, PCI DSS and
GDPR), then the SCF is a great tool to streamline the management of cybersecurity and privacy
controls.

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.

WHAT THE SCF IS


The SCF is a comprehensive catalog of controls that is designed to enable companies to design, build and maintain secure processes,
systems and applications. The SCF addresses both cybersecurity and privacy, so that these principles are designed to be “baked in” at
the strategic, operational and tactical levels.

The SCF is:


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

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

WHAT THE SCF IS NOT


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

The SCF is not:


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

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.

SECURE PRACTICES ARE COMMON EXPECTATIONS


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

COMPLIANCE SHOULD BE VIEWED AS A NATURAL BYPRODUCT OF SECURE PRACTICES


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

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.

STEPS TO OPERATIONALIZE THE C|P PRINCIPLES


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

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

SCF DOMAINS & C|P PRINCIPLES


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

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.

Implement measures to restrict mobile Organizations govern risks associated with


device connectivity with critical mobile devices, regardless of ownership
infrastructure and sensitive/regulated (organization-owned, employee-owned or
Mobile Device
20 MDM data that limit the attack surface and third-party owned). Wherever possible,
Management
potential data exposure from mobile technologies are employed to centrally
device usage. manage mobile device access and data
storage practices.
Architect and implement a secure and Organizations ensure sufficient cybersecurity
resilient defense-in-depth methodology & data privacy controls are architected to
that enforces the concept of “least protect the confidentiality, integrity,
Network
21 NET functionality” through restricting network availability and safety of the organization’s
Security
access to systems, applications and network infrastructure, as well as to provide
services. situational awareness of activity on the
organization’s networks.
Protect physical environments through Organizations minimize physical access to
layers of physical security and the organization’s systems and data by
environmental controls that work addressing applicable physical security
Physical &
together to protect both physical and controls and ensuring that appropriate
22 Environmental PES
digital assets from theft and damage. environmental controls are in place and
Security
continuously monitored to ensure
equipment does not fail due to
environmental threats.
Align data privacy practices with industry- Organizations align data privacy engineering
recognized data privacy principles to decisions with the organization’s overall data
implement appropriate administrative, privacy strategy and industry-recognized
23 Data Privacy PRI technical and physical controls to protect leading practices to secure Personal Data
regulated personal data throughout the (PD) that implements the concept of data
lifecycle of systems, applications and privacy by design and by default.
services.
Operationalize a viable strategy to achieve Organizations ensure that security-related
cybersecurity & data privacy objectives projects have both resource and
Project &
that establishes cybersecurity as a key project/program management support to
24 Resource PRM
stakeholder within project management ensure successful project execution.
Management
practices to ensure the delivery of
resilient and secure solutions.
Proactively identify, assess, prioritize and Organizations ensure that the business
remediate risk through alignment with unit(s) that own the assets and / or
industry-recognized risk management processes involved are made aware of and
principles to ensure risk decisions adhere understand all applicable cybersecurity &
Risk
25 RSK to the organization's risk threshold. data privacy-related risks. The cybersecurity
Management
& data privacy teams advise and educate on
risk management matters, while it is the
business units and other key stakeholders
that ultimately own the risk.
Utilize industry-recognized secure Organizations align cybersecurity
engineering and architecture principles to engineering and architecture decisions with
Secure
deliver secure and resilient systems, the organization’s overall technology
26 Engineering & SEA
applications and services. architectural strategy and industry-
Architecture
recognized leading practices to secure
networked environments.

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.

DATA PRIVACY PRACTICES ARE COMMON EXPECTATIONS


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

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

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.

The most common types of compliance requirements are:


 Statutory
 Regulatory
 Contractual

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.

From a cybersecurity and privacy perspective, statutory compliance requirements include:


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

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.

From a cybersecurity and privacy perspective, regulatory compliance examples include:


 US Regulations
o Defense Federal Acquisition Regulation Supplement (DFARS) (NIST 800-171)
o Federal Acquisition Regulation (FAR)
o Federal Risk and Authorization Management Program (FedRAMP)
o DoD Information Assurance Risk Management Framework (DIARMF)
o National Industrial Security Program Operating Manual (NISPOM)
o New York Department of Financial Services 23 NYCRR 500
 International Regulations
o European Union General Data Protection Regulation (EU GDPR)

CONTRACTUAL REQUIREMENTS
Contractual obligations are required by legal 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)

WHAT ARE YOUR APPLICABLE STATUTORY, REGULATORY AND CONTRACTUAL REQUIREMENTS?


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

To make sure scoping is done properly, it is imperative for you to speak with your legal, IT, project management, cybersecurity and
procurement teams. 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!

CUSTOMIZING THE CONTROL SET: USE EXCEL TO MANUALLY FILTER CONTROLS


The Secure Controls Framework (SCF), the controls within the DSP, is fundamentally an Excel spreadsheet. Therefore, you can use your
Excel skills to manually filter the requirements. If you are comfortable in Excel, it might take you 5-10 minutes to do this filtering, based
on how many requirements you need to map to.

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.

CYBERSECURITY & DATA PRIVACY CAPABILITY MATURITY MODEL (C|P-CMM)


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

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.

Process Review Lag Considerations


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

Stakeholder Value Considerations


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

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

C|P-CMM 0 – NOT PERFORMED


This level of maturity is defined as “non-existence practices,” where the control is not being performed.
 There are no identifiable work products of the process.

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).

C|P-CMM 1 – PERFORMED INFORMALLY


This level of maturity is defined as “ad hoc practices,” where the control is being performed, but lacks completeness & consistency.
 Base practices of the process area are generally performed.
 The performance of these base practices may not be rigorously planned and tracked.
 Performance depends on individual knowledge and effort.
 There are identifiable work products for the process.

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 – PLANNED & TRACKED


This level of maturity is defined as “requirements-driven practices,” where the expectations for controls are known (e.g., statutory,
regulatory or contractual compliance obligations) and practices are tailored to meet those specific requirements.
 Performance of the base practices in the process area is planned and tracked.
 Performance according to specified procedures is verified.
 Work products conform to specified standards and requirements.

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.

Note – The reality with a C|P-CMM 2 level of maturity is often:


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

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.

Note – The reality with a C|P-CMM 3 level of maturity is often:


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

C|P-CMM 4 – QUANTITATIVELY CONTROLLED


This level of maturity is defined as “metrics-driven practices,” where in addition to being well-defined and standardized practices across
the organization, there are detailed metrics to enable governance oversight.
 Detailed measures of performance are collected and analyzed. This leads to a quantitative understanding of process capability
and an improved ability to predict performance.
 Performance is objectively managed, and the quality of work products is quantitatively known.

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.

Note – The reality with a C|P-CMM 4 level of maturity is often:


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

C|P-CMM 5 – CONTINUOUSLY IMPROVING


This level of maturity is defined as “world-class practices,” where the practices are not only well-defined and standardized across the
organization, as well as having detailed metrics, but the process is continuously improving.
 Quantitative performance goals (targets) for process effectiveness and efficiency are established, based on the business goals
of the organization.

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.

Note – The reality with a C|P-CMM 5 level of maturity is often:


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

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.

Maturity Small Medium Large


Level Organizations Organizations Organizations
 Lack of processes would be considered negligent behavior. This is generally due to a lack of a It is unlikely for a large organization to
C|P-CMM
cybersecurity and privacy program. completely ignore cybersecurity and privacy
0  [NEGLIGENT] requirements.
 IT support focuses on reactionary “break /  Internal IT staff exists, but there is no management support to spend time or budget on security /
fix” activities and are ad hoc in nature. privacy controls that leads to ad hoc control implementation.
C|P-CMM
 IT support is likely outsourced with a  Focus is on general IT operations without clear standards that implement secure systems and
1 limited support contract. processes.
 [LIKELY NEGLIGENT]  [LIKELY NEGLIGENT]
 Internal IT role(s) has clear requirements  IT staff have clear requirements to meet applicable compliance obligations.
and is supported to meet applicable  There is most likely a dedicated cybersecurity role or a small cybersecurity team.
cybersecurity / privacy compliance
C|P-CMM
obligations; or
2  The outsourced IT provider is properly
scoped in its support contract to address
applicable compliance obligations.
 There is a small IT staff that has clear  IT staff have clear requirements to meet applicable compliance obligations.
requirements to meet applicable  In addition to the existence of a dedicated cybersecurity team, there are specialists (e.g., engineers,
compliance obligations. SOC analysts, GRC analysts, privacy, etc.).
C|P-CMM  There is likely a very competent leader  There is a very competent leader (e.g., CISO) with solid cybersecurity experience who has the
3 (e.g., security manager / director) with solid authority to direct resources to enact secure practices across the organization.
cybersecurity experience who has the
authority to direct resources to enact
secure practices across the organization.
 IT staff have clear requirements to meet applicable compliance obligations.
 In addition to the existence of a dedicated cybersecurity team, there are specialists (e.g., engineers,
SOC analysts, GRC analysts, privacy, etc.).
C|P-CMM It is unrealistic for a small organization to  There is a very competent leader (e.g., CISO) with solid cybersecurity experience who has the
4 attain this level of maturity. authority to direct resources to enact secure practices across the organization.
 Business stakeholders are made aware of the status of the cybersecurity and privacy program (e.g.,
quarterly business reviews to the CIO/CEO/board of directors). Situational awareness is made
possible through detailed metrics.
 IT staff have clear requirements to meet
applicable compliance obligations.
 In addition to the existence of a dedicated
cybersecurity team, there are specialists (e.g.,
engineers, SOC analysts, GRC analysts, privacy,
etc.).
 There is a very competent leader (e.g., CISO)
with solid cybersecurity experience who has
the authority to direct resources to enact
secure practices across the organization.
 Business stakeholders are made aware of the
status of the cybersecurity and privacy
C|P-CMM program (e.g., quarterly business reviews to
It is unrealistic for a small or medium organization to attain this level of maturity.
5 the CIO/CEO/board of directors). Situational
awareness is made possible through detailed
metrics.
 The organization has a very aggressive
business model that requires not only IT, but
its cybersecurity and privacy practices, to be
innovative to the point of leading the industry
in how its products and services are designed,
built or delivered.
 The organization invests heavily into
developing AI/ML technologies to made near
real-time process improvements to support
the goal of being an industry leader.

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.

IDENTIFYING THE PROBLEM


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

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

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

IDENTIFYING THE PROBLEM


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

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

As 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.

IDENTIFYING THE PROBLEM


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

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.

IDENTIFYING THE PROBLEM


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

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

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

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

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

POLICY / SECURITY POLICY


Policies are high-level statements of management intent from an organization’s executive leadership that are designed to influence
decisions and guide the organization to achieve the desired outcomes. Policies are enforced by standards and further implemented by
procedures to establish actionable and accountable requirements.

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.

GUIDELINE / SUPPLEMENTAL GUIDANCE


Guidelines are recommended practices that are based on industry-recognized secure practices. Guidelines help augment Standards when
discretion is permissible. Unlike Standards, Guidelines allow individuals / teams to apply discretion or leeway in interpretation,
implementation, or use.

 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].

ASSESSMENT OBJECTIVE (AO)


Assessment Objectives (AOs) are a set of determination statements that express the desired outcome for the assessment of a Control.
AOs are the authoritative source of guidance for assessing Controls to generate evidence that can support an assertion that the
underlying Control has been satisfied. Generally, all AOs must be satisfied to legitimately conclude a Control is properly implemented.

 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.

* Danger: state of possibly suffering harm or injury


* Harm: material / physical damage
* Loss: destruction, deprivation or inability to use

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.

Leading guidance on secure configurations tend to come from:


 Center for Internet Security (CIS) Benchmarks;
 Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs); and/or
 Original Equipment Manufacturer (OEM) recommendations.

 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.

RISK REGISTER / PLAN OF ACTION & MILESTONES (POA&M)


A POA&M is a “living document” that summarizes control deficiencies from identification through remediation. A POA&M is essentially
a risk register that tracks the assignment of remediation efforts to individuals or teams, as well as identifying the tasks and resources
necessary to perform the remediation.

 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.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy