Introduction

Here at TrustedSec, we help our clients achieve and maintain compliance with a variety of Information Security and privacy frameworks. We often receive requests for compliance assistance with frameworks that don't make sense when considering the type of organization making the request. We always seek to understand our clients' needs before proposing an engagement, especially when a request raises some concerns, and have determined that most of these requests fall into one (1) of two (2) categories:

1. The client is attempting to improve their security program and has selected a framework without understanding the framework's intent.
2. The client has received a request to comply with a specific framework from a potential customer or partner, often because the customer or partner does not understand the framework's intent.

The first scenario is easy to deal with: we can steer our clients toward a more appropriate framework for their organization. The second scenario is often more difficult: our client doesn't necessarily have control over which framework they are being requested to comply with, so we must try to adapt the framework to the client.

This post is an attempt to describe the intent and nuances of common Information Security frameworks so that organizations can choose appropriate frameworks when they have the option. It is also designed to help organizations understand what is being requested of them when they find themselves in the unenviable position of receiving an inappropriate compliance request from a potential customer or partner. This post will also discuss how some of the frameworks that often show up in third-party requests can be adapted to fit organizations that are not the intended targets of those frameworks.

About Compliance Frameworks

Before we go into detail on specific frameworks, we should describe why compliance frameworks exist to help us understand how the requirements are defined and applied.

The creation of an Information Security framework typically starts with a risk assessment process: a government agency or private standards body considers what type of information needs to be protected and what likely threats the information must be protected from. Once the threats and their resulting risks are understood, a set of security controls can be defined that should reduce the impact or likelihood of these threats. Controls can be policy-based (e.g., a clean-desk policy) or technical (e.g., lock out an account after a certain number of incorrect password attempts). The controls are documented, the framework is published, and the rest of us are left to reconcile our Information Security programs with the published control definitions.

These frameworks can be created, published, and enforced via contract by private organizations, e.g., payment card brands trying to protect payment card data from theft and subsequent fraudulent use via the Payment Card Industry Data Security Standard (PCI DSS) framework. More often, these frameworks are the result of government legislative and regulatory action, e.g., the United States federal government trying to protect sensitive defense-related information from disclosure to international competitors via the Cybersecurity Maturity Model Certification (CMMC) framework. Some of these frameworks may include a combination of Information Security, privacy, and breach reporting components, e.g., Health Insurance Portability and Accountability Act (HIPAA) regulations.

A common refrain in the Information Security field is that 'compliance is not security.' To explain this concept, consider that a framework is created with its author's concerns in mind, not the concerns of the organizations that the frameworks will apply to. For example, PCI DSS is focused on forcing organizations to implement controls to maintain the confidentiality of payment card data. This is because PCI DSS was created to protect the card brands and banks from fraud losses. PCI DSS does not concern itself with the availability of card data and, as a result, contains no controls to prevent the unauthorized destruction of card data—e.g., a requirement to have redundant systems or take backups. Your entire datacenter could burn to the ground, and you would remain PCI DSS compliant—there is no longer any data for fraudsters to steal. From your perspective, however, this event would likely have a catastrophic impact on your business and should be mitigated. Organizations should keep the intent of compliance framework authors in mind when selecting and relying on a framework in place of risk-based decision making.

There is another type of compliance framework that takes a very different approach, as exemplified by the International Standards Organization and International Electrotechnical Commission Information Security Management Systems Requirements (ISO 27001) and System and Organization Controls 2 (SOC 2) frameworks. These frameworks are intended to support the needs of an organization regardless of the type of information they handle. Instead of defining a rigid set of controls, they ask each organization to select appropriate controls of their own. Essentially, each organization designs its own unique requirements and is then audited on their compliance with their self-imposed requirements. This is described in more detail below.

Common Frameworks

NIST (or NIST 800)

TrustedSec has recently seen an increase in organizations inquiring about “NIST” or “NIST 800” compliance without any further detail. Usually, these requests are the result of guidance from recently completed security assessments or a result of questions from third-parties including potential customers or partners.

Whenever these queries come in, our question is always “which NIST framework?” NIST is the National Institute of Standards and Technology, a United States Federal Agency that publishes many different standards on many different topics ranging from a 573 page document on weighing and measuring devices that includes details on the proper construction of berry baskets to the calibration of x-ray and gamma-ray measuring instruments.

It’s highly unlikely that anyone is asking TrustedSec how to build berry baskets, so that brings us to NIST’s Federal Information Processing Standards (FIPS) and Special Publications (SP). Both the FIPS and SP categories contain a variety of documents intended to apply to information systems of the Federal Government and its contractors (FIPS documents are standards while SP documents are guidance). There are currently 10 FIPS and 250 SP documents, of which 180 are in the SP 800 series on computer and Information Security. Other documents outside the FIP and SP 800 series, like the NIST Cybersecurity Framework (covered separately below), are also a possibility. With such a large number of documents, knowing that our clients are asking about Information Security in general or the NIST SP 800 series security standards in particular does not narrow the field quite enough.

If an organization wants to align with a NIST framework, we must know what the organization is trying to protect and why they are trying to protect it. This can help identify a specific framework that is applicable to the organization such as NIST SP 800-171 for federal contractors that are handling controlled unclassified information, or NIST SP 800-66 for implementing the HIPAA security rule.

A few of the NIST SP 800 series frameworks are covered in more detail below, as they are often misapplied by organizations unaware of their intended use. If an organization is not managing critical infrastructure or is not part of, contracting for, or handling information protected by the United States Federal Government, it is unlikely that any of the NIST frameworks are a good fit.

NIST SP 800-53

Many of the compliance requests we deal with are in some way related to National Institute of Standards and Technology Special Publication 800-53 (NIST SP 800-53). NIST SP 800-171, the NIST Cybersecurity Framework (NIST CSF), the NIST Privacy Framework (NIST PF), and CMMC are all derived from NIST SP 800-53.

The Federal Information Security Modernization Act (FISMA) is a law that requires United States Federal Government agencies to secure their systems. NIST SP 800-53 was created as the security standard that these Federal Agencies must align with. A private organization inquiring about NIST SP 800-53 compliance is always a red flag for us, as this framework was created exclusively for the purpose of securing United States Federal Government systems subject to FISMA.

Some private organizations have tried to voluntarily align themselves with NIST SP 800-53, but this is a difficult task, as some of the controls contain concepts that are very specific to the way the federal government operates, and there is no simple way to adapt them to a private organization. For example, requirement PT-6 requires submitting System of Records notices to the Office of Management and Budget and publishing notices in the Federal Register.

NIST SP 800-53 is also designed to be tailored to each agency, a nuance that is often lost on private organizations trying to 'comply with' the framework. Attempting to implement every NIST SP 800-53 control is not how the framework was meant to be used and will only result in frustration. NIST SP 800-53B defines three (3) levels of security baselines, a privacy baseline, and a set of organization-wide controls to support the security baselines. Federal Information Processing Standards 199 and 200 (FIPS 199 and FIPS 200) define the process for selecting the appropriate baseline(s) using a risk-based process. The risk-based process should also be used to further tailor the selected baseline by removing controls from the baselines that are deemed unnecessary and adding controls to the baseline, if they are needed, to address risks that are not adequately addressed by other controls in the baseline.

Implementing NIST SP 800-53 within a private organization is almost always a difficult process due to the risk-based process required to select an appropriate baseline and the effort required to adapt the framework to a private organization. When possible, other frameworks that are more appropriate to a private organization and the type of information being handled should be used instead. ISO 27001 would be a good choice for an adaptable framework.

A private organization that is forced to align with NIST SP 800-53 due to a third-party request should attempt to reduce the scope as much as possible by asking the third party what information requires protection and limiting the NIST SP 800-53 applicability to the systems that handle that information. The third party should also be asked about which NIST SP 800-53 baseline(s) they require or, if they do not specify baseline(s), about the sensitivity of the information to assist in the process of selecting appropriate baselines using the processes described in FIPS 199, FIPS 200, and NIST SP 800-53B.

Appendix E of NIST SP 800-171r2 can be used to help determine which controls apply only to federal agencies. This appendix lists the NIST SP 800-53 controls and indicates why they were included in or excluded from NIST SP 800-171. Controls flagged with 'FED' were determined to be 'UNIQUELY FEDERAL, PRIMARILY THE RESPONSIBILITY OF THE FEDERAL GOVERNMENT' and can likely also be excluded by any private organization aligning with NIST SP 800-53. Keep in mind, some further adaptation will be required—as of this post, the current version of NIST SP 800-171 (revision 2) is based on NIST SP 800-53 revision 4, which has been withdrawn in favor of NIST SP 800-53 revision 5.

FedRAMP

The use of cloud services by United States Federal Agencies does not exempt the agencies from FISMA security obligations, so the Federal Risk and Authorization Management Program (FedRAMP) was created as a way to get cloud services authorized for use by federal agencies. FedRAMP is heavily based on NIST SP 800-53 and can be thought of as NIST SP 800-53 for private-sector cloud providers hosting Federal Government systems.

FedRAMP compliance inquiries from organizations that are not cloud service providers and/or are not providing services to the United States Federal Government also raise red flags, as FedRAMP has very specific use applicability and strict requirements. Cloud providers that are not contracting with Federal Agencies would be better off using a cloud security framework like the Cloud Security Alliance Cloud Controls Matrix (CSA CCM) or the Center for Internet Security (CIS) Controls Cloud Companion Guide.

Some organizations inquire about FedRAMP certification because they want to be able to provide cloud services to Federal Agencies. Organizations cannot just align with the framework and get certified the way they can with many other compliance frameworks. There are only two (2) paths to FedRAMP certification:

1. Sponsorship by a specific federal agency
2. Approval by the Joint Authorization Board (JAB)

In the agency authorization track, the cloud provider will need to work closely with a sponsoring agency to understand the security level of the information they will be handling, according to FIPS 199 and FIPS 200 processes as described for NIST SP 800-53, to build an appropriate system. This generally requires an agency to already be interested in the organization’s cloud offerings.

The JAB process does not require agency sponsorship but does require an application and the process is highly selective. Only about 12 cloud providers are accepted via JAB each year. Organizations should understand whether they meet the prioritization criteria before they apply.

Regardless of the path used, assessments must be conducted by an accredited Third Party Assessment Organization (3PAO).

NIST SP 800-171

The National Institute of Standards and Technology Special Publication 800-171 (NIST SP 800-171) is derived from NIST SP 800-53 and is intended to apply to federal contractors handling Controlled Unclassified Information (CUI). CUI is defined in Executive Order 13556, and a list of the types of CUI is maintained by the National Archives and Records Administration.

Private federal contractors and subcontractors often have legitimate NIST SP 800-171 compliance obligations, but many state and private organizations include NIST SP 800-171 compliance clauses in contracts that have nothing to do with federal contracts or CUI. Some third parties include NIST SP 800-171 clauses in every contract by default and may remove the clause if the lack of any nexus to federal contracts and CUI is pointed out. In other cases, third parties are misusing NIST SP 800-171 clauses as a low-effort attempt to impose security best practices with an inappropriate framework.

The misuse of NIST SP 800-171 as a set of general security best practices presents a problem for private organizations that are not handling CUI: The applicability to CUI is explicitly written into many of the NIST SP 800-171 controls. Consider NIST SP 800-171 requirement 3.8.8: 'Sanitize or destroy system media containing CUI before disposal or release for reuse.' A strict reading of this control would allow an organization to say they are compliant with this control, even if they do not sanitize or destroy any system media, because they have no media containing CUI. The organization that attempted to impose the NIST SP 800-171 compliance obligation may not appreciate or accept this type of response.

Attempting to align an organization with NIST SP 800-171 in a non-CUI environment typically requires inquiring with the organization that is imposing the obligation to determine what information they expect NIST SP 800-171 to apply to. This information can then be used as a stand-in for CUI in each of the NIST SP 800-171 controls. As with NIST SP 800-53, organizations will find that they have an easier time aligning with NIST SP 800-171 if they limit their efforts to the systems that handle the information that the third party is concerned with.

CMMC

The Cybersecurity Maturity Model Certification (CMMC) framework is a relatively new framework published by the federal government to protect defense-related CUI handled by private defense contractors. This is the same CUI that NIST SP 800-171 addresses. A draft of the framework has been published but has not come into effect as of this post. It is expected to come into effect in 2024 or 2025.

CMMC is an evolution of NIST SP 800-171, and nearly all the advice provided above for NIST SP 800-171 applies here as well. The main change from NIST SP 800-171 to CMMC is the addition of levels, where Level 1 is a subset of NIST SP 800-171 controls, Level 2 includes all NIST SP 800-171 controls, and Level 3 will include new controls from NIST SP 800-172. The self-assessment process used for NIST SP 800-171 has also changed under CMMC, and some organizations will require third-party audits under CMMC.

CMMC compliance obligations will be written into contracts by the Department of Defense (DoD). These contracts will, in turn, obligate prime contractors to impose CMMC compliance obligations on any subcontractors or other organizations that CUI is shared with. The contracts will define the information that is considered CUI under the contract, the CMMC level the information must be protected to, and whether the organization is required to have a third-party audit or can self-assess compliance.

Large defense contractors are already including generic CMMC clauses in their contracts, even though CMMC has not been finalized and the DoD has not issued any contracts containing CMMC clauses. This can be frustrating for subcontractors, as they are being asked to comply with a draft framework that may still change. In addition, the generic contract clauses fail to describe the CUI that needs to be protected, the level it must be protected to, and whether compliance can be self-assessed or must be independently audited. This makes it impossible to accurately scope and assess compliance.

As with NIST SP 800-171, organizations that receive contracts with CMMC clauses that are potentially unnecessary due to a lack of CUI should inquire as to whether the clauses can be removed. If the third party refuses to remove the clause, the organization should ask relevant questions to determine what information needs to be protected and to what level.

In the interim, organizations in the defense industrial base should begin efforts to prepare their environment for CMMC compliance, as they will not be able to accept new contracts once the DoD starts including legitimate CMMC clauses. Organizations should begin by determining what will likely be considered CUI under CMMC, working to isolate that data from unnecessary systems and processes to reduce scope, and implementing NIST SP 800-171 controls on systems that are expected to be in scope. Limiting scope is key to efficient CMMC compliance, and, unlike most other compliance frameworks, CMMC is very specific about how the compliance scope is defined so this will require close attention.

NIST CSF

The NIST Cybersecurity Framework (NIST CSF) is yet another framework derived from NIST SP 800-53 by the United States government. NIST CSF is a voluntary framework for the purpose of improving cybersecurity for critical infrastructure. In this context, critical infrastructure refers to systems and assets that would have a debilitating national impact if compromised—e.g., power grids.

Despite its intended purpose, NIST CSF is often used by organizations that do not manage critical infrastructure but are seeking to voluntarily align with a framework in order to improve their Information Security program. NIST CSF may also be seen as a contractual obligation imposed by a third party, but this is rare.

Much like the problem with applying NIST SP 800-171 to non-CUI environments, some NIST CSF controls explicitly refer to critical infrastructure that an organization attempting to align with it may not be associated with, e.g., NIST CSF control ID.RM-3: ' The organization’s determination of risk tolerance is informed by its role in critical infrastructure and sector specific risk analysis'. Organizations that do not manage critical infrastructure but would like to implement NIST CSF should determine an appropriate stand-in for critical infrastructure, typically the systems that are most critical to their own business.

NIST CSF is much shorter and vaguer than most other compliance frameworks. This can be an advantage for organizations that have NIST CSF imposed on them, as it takes much less effort to comply with such a short list of non-specific controls. On the other hand, this may be a detriment to organizations that are voluntarily seeking to improve their Information Security and would benefit from more detailed guidance provided in alternative frameworks like ISO 27001.

PCI DSS

The PCI DSS, as mentioned earlier in this post, is a private framework created by a consortium of payment card brands to protect payment card data. Much like CMMC, PCI DSS compliance requirements originate in contracts, in this case when an organization signs up to process payment cards via a bank or other processor. Organizations that are contractually obligated to comply with PCI DSS in this manner are, in turn, required to pass PCI DSS compliance obligations on to other organizations that they involve in their payment card processes and track those organizations' compliance status. This includes:

• Any organization they share payment card data with, e.g., a targeted marketing company analyzing transactions
• Any organization that handles card data on their behalf, e.g., a billing management company
• Any organization that can otherwise affect the security of the payment card data, e.g., a managed service provider with access to internal networks and systems

Organizations that are subject to PCI DSS compliance are required to annually assess and report their compliance status. Many organizations looking into PCI DSS compliance get hung up on the concept of levels, which are determined by whether the organization is a merchant or service provider and how many transactions they handle per year. The levels determine what type of annual compliance reporting is required and do not change the scope or applicability of the PCI DSS controls in any way.

Many organizations that should be subject to PCI DSS compliance slip through the cracks, as small organizations don't realize they must pass compliance obligations onto and monitor the compliance of their service providers. There are also organizations that take an overzealous approach and demand evidence of PCI DSS compliance from their service providers when there is no payment card data being handled.

Organizations that receive requests for evidence of PCI DSS compliance, typically provided on a form known as an Attestation of Compliance (AoC) that is completed during the annual assessment, should review whether and how they handle payment card data on behalf of the requesting organization or can otherwise affect the security of payment card data. If there is no way the organization can store, process, transmit, or otherwise affect the security of payment card data, then there is no PCI DSS scope, and they should inform the third party of this finding.

It is clear that compliance is required in cases where a service provider is intentionally storing, processing, or transmitting payment cardholder data on behalf of another organization. Other cases are not as clear—a customer may be storing call recordings that contain payment card numbers on a cloud service that otherwise has nothing to do with payment cards, thereby bringing the cloud service provider into scope for PCI DSS compliance because their service is storing card data. Or, a managed service provider may have control over a firewall that protects an eCommerce website, thereby bringing the managed service provider into scope because their control of the firewall can affect the security of card data on the eCommerce website.

Service provider organizations that are handling payment card data on behalf of other organizations have three (3) basic options:

• Align with PCI DSS, assess, and attest to compliance:
  • Determine which PCI DSS controls will be the responsibility of the service provider and which will remain the responsibility of the customer
  • Provide this list of responsibilities to the customer
  • Implement PCI DSS controls that are the responsibility of the service provider
  • Conduct annual PCI DSS assessments
  • Provide evidence of compliance to the customer
• Provide the service as-is, leaving compliance responsibility on the customer:
  • Allow the other organization's assessor to review the controls for PCI DSS compliance as part of the other organization's assessment and attestation process
• Eliminate PCI DSS compliance obligations:
  • Prohibit any activity involving payment card data in new contracts
  • Terminate or alter contracts with organizations that use the service for payment card activities

While providing the service as-is and leaving all compliance responsibility with the customer may seem like a tempting, low-effort option, it is often more difficult in practice—the customer(s) will not be able to achieve compliance unless they can demonstrate that their service provider's controls are compliant. Each customer with PCI DSS obligations will likely ask to have their assessors review the service provider's controls for compliance and will request remediation of any non-compliant controls. A service provider refusing to allow the assessments or remediate controls will prevent the customer from achieving compliance and will usually drive the customer to another service provider. Formally aligning with PCI DSS or refusing business related to payment cards are typically the only realistic options.

PCI DSS also has very specific rules for determining scope. As recommended for some of the other frameworks above, making efforts to limit the applicability of PCI DSS to the systems that handle payment card data can reduce the effort required to achieve and maintain compliance and is always recommended.

HIPAA, GDPR, CPRA, and Other Privacy-Driven Frameworks

There are a variety of federal, state, and international frameworks dealing with privacy. Each is unique, but there are some common themes, described here.

Privacy frameworks typically have strict definitions of the information they cover—often the personally identifiable information of individuals who live within a certain jurisdiction— and apply to organizations handling that information, regardless of whether the organization is in the same jurisdiction as the individual. Privacy frameworks also typically have some exemptions for certain types of organizations or information, but these vary between frameworks.

Some of these frameworks require organizations subject to their jurisdiction, that are sharing covered information outside their jurisdiction, to include contract clauses obligating other organizations outside the jurisdiction to comply as well. Organizations receiving contracts with clauses related to privacy regulations should closely scrutinize the frameworks to determine what information they apply to and if there are any applicable exemptions. Organizations may want to consider refusing to accept certain types of information, or information from certain jurisdictions, to avoid compliance obligations.

Although these frameworks are privacy-focused, they usually have some Information Security and breach reporting components as well. The Information Security portions of these frameworks are typically very short and very vague when compared to the dedicated Information Security frameworks described above. This is an advantage for organizations attempting to quickly align with the privacy framework, but organizations that take security seriously may consider voluntarily aligning with another more detailed Information Security framework to supplement the privacy framework obligations.

ISO 27001 and SOC 2

Both International Standards Organization and International Electrotechnical Commission Information Security Management Systems Requirements (ISO 27001) and System and Organization Controls 2 (SOC 2) are voluntary frameworks created by private organizations to help improve Information Security. SOC 2 is intended for use by service providers, while ISO 27001 is suitable for use by any organization.

Many organizations receive requests from potential customers or partners to attest to either ISO 27001 or SOC 2 compliance as a way of demonstrating they have a mature Information Security program. These frameworks are both covered in this section to help organizations contrast them and determine which is more appropriate.

As alluded to earlier in this post, ISO 27001 and SOC 2 are very different from the other compliance frameworks described in this post. The other frameworks can be thought of as checklists of controls that must be implemented as written. ISO 27001 and SOC 2 both allow organizations to choose their own controls, which the organization is then audited against.

Both ISO 27001 and SOC 2 require outside audits to confirm compliance. As these are maturity-based frameworks rather than checklists of controls, an organization needs to be able to demonstrate the maturity of their organization's Information Security program. Simply implementing the controls is not enough to achieve compliance—audits will be primarily concerned with the formal risk-based process used to select appropriate controls. It can take a year or more to design the program, implement the controls, and generate enough evidence of ongoing security practices to demonstrate maturity to an auditor.

The ISO 27001 model is based around the concept of risk management and continuous improvement. The core clauses of ISO 27001 describe a process of defining scope, performing a risk assessment, selecting appropriate controls to treat risks identified during the risk assessment, monitoring those controls for effectiveness, and using the results of that monitoring to determine what further improvements can be made. This process is intended to be repeated in perpetuity. ISO 27001 also contains a menu of security controls that can be selected from or omitted as part of the risk treatment process. Various other documents in the ISO 27000 series provide additional specialized controls to select from, detailed guidance for conducting the risk assessment, guidance for implementing controls, etc. Organizations are assessed against the core ISO 27001 clauses and their implementation of controls that they have selected as part of the risk assessment process.

The SOC 2 model is based on the concept of defined service commitments, i.e., what level of service the provider agrees to provide to customers. The assessor will determine whether the service provider’s system and security designs are sufficient to meet these commitments. The result of this assessment is a SOC 2 Type I report. The assessor can then go on to determine whether the system and its security controls are being operating as designed. The result of this second-stage assessment is a SOC 2 Type II report. As with ISO 27001, an organization must operate their controls as designed for a period of time to generate enough evidence to support a SOC 2 Type II report.

A common mistake organizations make is to treat ISO 27001 or SOC 2 like a checklist compliance framework. In the case of ISO 27001, organizations working toward compliance often fixate on the list of security controls in ISO 27001 Annex A or ISO 27002 and attempt to implement all of them while ignoring the core scope and risk-based clauses of ISO 27001. This approach is wasteful when the scope determination and risk assessment process may determine that many of the controls are unnecessary. SOC 2 does not have a similar list of specific controls, so organizations that attempt to treat it like a checklist find themselves lost without a list to check. Both frameworks should be implemented by first defining an appropriate scope, then designing appropriate security controls to support that scope, and only then implementing specific security controls. Implementing security controls without conducting the scope and control design processes is a surefire way to fail an ISO 27001 or SOC 2 assessment.

Simplifying Compliance Frameworks with Expertise

TrustedSec's compliance team has years of experience helping organizations understand and implement compliance frameworks. We have a deep understanding of the ISO 27000 series, NIST SP 800 series, PCI DSS, CMMC, and SOC 2.

TrustedSec focuses on reducing the scope of compliance as much as possible prior to beginning any assessment or implementation tasks. This approach provides an enormous return on investment, reducing the time, effort, and financial cost associated with achieving, assessing, and maintaining compliance, especially for frameworks like PCI DSS and CMMC that have very broad and detailed scope requirements.

In addition to core compliance services, TrustedSec offers a variety of services that can be used to meet specific compliance requirements, including risk assessments, training, policy and procedure development and revision, Incident Response, penetration testing, vulnerability scanning, and remediation.