Cybersecurity Materiality & Risk Tolerance

Specific to cybersecurity and data protection, the SCF defines material weakness as:

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

In the context of that definition of cybersecurity materiality, it is important to baseline the understanding risk management terminology. According to the PMBOK® Guide:

• Risk Tolerance is the “specified range of acceptable results.”
• Risk Threshold is the “level of risk exposure above which risks are addressed and below which risks may be accepted.”
• Risk Appetite is the “degree of uncertainty an organization or individual is willing to accept in anticipation of a reward.” It is important to note that the risk tolerance and risk appetite are not the same thing. In terms of cybersecurity materiality, risk tolerance matters.

​The concept of materiality is important to understand the health of a cybersecurity and data protection program, where a material weakness crosses an organization’s risk threshold by making an actual difference that exposes systems, applications, services, personnel, the organization or third-parties to unacceptable risk. Materiality designations can help determine what constitutes reasonable assurance that an organization adheres to its stated risk tolerance.

Assurance is defined as the grounds for confidence that the set of intended security and data privacy controls in a system, application or service are effective in their application. Since assurance is relative to a specific set of controls, defects in those controls affect the underlying confidence in the ability of those controls to operate as intended to produce the stated results. Fundamentally, assurance identifies the level of confidence that a stakeholder has that an objective is achieved, that takes into consideration the risks associated with non-conformity (e.g., non-compliance) and the anticipated costs necessary to demonstrate conformity with the specified controls.

When organizations go through some form of certification process, it undergoes a conformity assessment (e.g., ISO 27001, CMMC, SOC 2, PCI DSS, RMF, etc.). Conformity assessments are designed to assure that a particular product, service, or system meets a given level of quality or safety. Instead of a 100% pass criteria, conformity assessments rely on the concept of assurance to establish a risk-based threshold to determine if the intent of the objective(s) has been achieved.​

Context For Cybersecurity Materiality Usage

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

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

For those in the Governance, Risk Management & Compliance (GRC) space, materiality is often relegated to Sarbanes-Oxley Act (SOX) compliance. However, the concept of materiality is much broader than SOX and can be applied as part of risk reporting in any type of conformity assessment. Financial-related materiality definitions focus on investor awareness of third-party practices, not inwardly-looking for adherence to an organization's risk tolerance:

• Per the Security and Exchange Commission (SEC), information is material “to which there is a substantial likelihood that a reasonable investor would attach importance in determining whether to purchase the security registered.”
• Per the Financial Accounting Standards Board (FASB), “if omitting, misstating or obscuring it could reasonably be expected to influence the decisions that the primary users of general purpose financial statements make on the basis of those financial statements, which provide financial information about a specific reporting entity.”

A financial benchmark is commonly used to determine materiality. As an example, from a financial impact perspective, for an item to be considered material, the control deficiency, risk, threat or incident (singular or a combination) should meet one, or more, of the following criteria where the potential financial impact is measured as:

• ≥ 5% of pre-tax income
• ≥ 0.5% of total assets
• ≥ 1% of total equity (shareholder value); and/or
• ≥ 0.5% of total revenue.

Facets of Materiality Considerations 

There is more to the materiality than simply defining it:

• Material Control. When a deficiency, or absence, of a specific control poses a material impact, that control is designated as a material control. A material control is such a fundamental cybersecurity and/or data protection control that:
• It is not capable of having compensating controls; and
• Its absence, or failure, exposes an organization to such a degree that it could have a material impact.
• Material Risk. When an identified risk that poses a material impact, that is a material risk.
• A material risk is a quantitative or qualitative scenario where the exposure to danger, harm or loss has a material impact (e.g., significant financial impact, potential class action lawsuit, death related to product usage, etc.); and
• A material risk should be identified and documented in an organization's "risk catalog" that chronicles the organization's relevant and plausible risks.
• Material Threat. When an identified threat poses a material impact, that is a material threat.
• A material threat is a vector that causes damage or danger that has a material impact (e.g., poorly governed Artificial Intelligence (AI) initiatives, nation state hacking operations, dysfunctional internal management practices, etc.); and
• A material threat should be identified and documented in an organization's "threat catalog" that chronicles the organization's relevant and plausible threats.
• Material Incident. When an incident poses a material impact, that is a material incident.
• A material incident is an occurrence that does or has the potential to:
• Jeopardize the Confidentiality, Integrity, Availability and/or Safety (CIAS) of a system, application, service or the data that it processes, stores and/or transmits with a material impact on the organization; and/or
• Constitute a violation, or imminent threat of violation, of an organization's policies, standards, procedures or acceptable use practices that has a material impact (e.g., malware on sensitive and/or regulated systems, emergent AI actions, illegal conduct, business interruption, etc.).
• Reasonably foreseeable material incidents should be documented in an organization's Incident Response Plan (IRP) that chronicles the organization's relevant and plausible incidents, so there are appropriate practices to identify, respond to and recover from such incidents.
• Material Weakness. A material weakness is a deficiency, or a combination of deficiencies, in an organization's cybersecurity and/or data protection controls (across its supply chain) where it is probable that reasonable threats will not be prevented or detected in a timely manner that directly, or indirectly, affects assurance that the organization can adhere to its stated risk tolerance.
• When there is an existing deficiency (e.g., control deficiency) that poses a material impact, that is a material weakness (e.g., inability to maintain access control, lack of situational awareness to enable the timely identification and response to incidents, etc.).
• A material weakness will be identified as part of a gap assessment, audit or other form of assessment as a finding due to one (1), or more, control deficiencies. A material weakness should be documented in an organization's Plan of Action & Milestones (POA&M), risk register, or similar tracking mechanism for remediation purposes.

Internal vs External Consumption for Materiality Considerations

As shown above in the financial context of materiality, that usage of "materiality" is intended for external, third-party consumption (e.g., investors) to ensure informed decisions are made. The SCF's definition of "cybersecurity materiality" is intended for internal governance practices.  

This intended usage for internal governance practices is meant to mature risk management practices by providing context, as compared to generally-hollow risk management statements that act more as guidelines than requirements, as it pertains to risk thresholds. Cybersecurity materiality is meant to act as a "guard rail" for risk management decisions. 

Use Cases For Cybersecurity Materiality

Use cases for how "cybersecurity materiality" can benefit cybersecurity and data privacy practitioners include, but are not limited to:

• Control assessments - using risk tolerance and risk thresholds provides context about how to report the significance of the findings, where material weaknesses in the controls assigned to systems, applications, services, projects, etc. can take on an enhanced sense of urgency.
• Project/initiative planning - identifying "must have" cybersecurity and data privacy controls early in the development lifecycle can prevent roadblocks that should halt a project/initiative from going live in a production environment, due to material weaknesses. This enables a risk-based justification for funding requirements for necessary people, processes and technologies to ensure the organization's risk tolerance is met.
• Third-party risk assessments - depending on the nature of a third-party's products/services, that entity's deficiencies can directly or indirectly affect the overall security of your organization. To prevent "hand waiving" practices that allow third-party services through without scrutiny, utilizing cybersecurity materiality considerations is a viable way to evaluate if that third-party enables your organization to adhere to its stated risk tolerance.
• Catalyst for change & budget justification - as a responsible party (e.g., CISO, CPO, etc.) for your organization's cybersecurity and data privacy program, being able to identify and designate material weakness can be an immensely beneficial tool for change. If material weaknesses are identified by a CISO (or equivalent role), that requires executive-level support. This may equate to forcing technology changes (e.g., good IT hygiene practices, legacy technology refreshes, terminating unsuitable vendor contracts, etc.), processes changes (e.g., good hiring practices, terminating unsuitable employees, procurement practice changes, embedding cybersecurity and data privacy in project management, etc.) or adequate budget to remediate deficiencies in the cybersecurity and data privacy program.

Defining Risk Appetite

Risk appetites exist as a guiderail from an organization's executive leadership to inform employees about what is and is not acceptable, in terms of risk management.

Risk appetite is primarily a “management statement” that is subjective in nature. Similar in concept to how a policy is a "high-level statement of management intent," an organization's stated risk appetite is a high-level statement of how all, or certain types of, risk are willing to be accepted. Using a review of current risk status vs target risk appetites can be useful to see how well cybersecurity practices operate to clearly see what practice areas deviate from expectations.

Examples of an organization stating its risk appetite from basic to more complex statements:

• "[organization name] is a low-risk organization and will avoid any activities that could harm its customers."
• "[organization name] will aggressively pursue innovative solutions through Research & Development (R&D) to provide industry-leading products and services to our clients, while maintaining a moderate risk profile. Developing breakthrough products and services does invite potential risk through changes to traditional supply chains, disruptions to business operations and changing client demand. Proposed business practices that pose greater than a moderate risk will be considered on a case-by-case basis for financial and legal implications.”

It is important to know that in many immature risk programs, risk appetite statements are divorced from reality. Executive leaders mean well when they put out risk appetite statements, but the Business As Usual (BAU) practices routinely violate the risk appetite. This is often due to numerous reasons that include, but are not limited to:

• Technical debt;
• Dysfunctional management decisions;
• Insecure practices;
• Inadequate funding/resourcing;
• Improperly scoped support contracts (e.g., Managed Service Providers (MSPs), consultants, vendors, etc.); and
• Lack of pre-production security testing.

Defining Risk Tolerance

An organization's risk tolerance is influenced by several factors that includes, but is not limited to:

• Statutory, regulatory and contractual compliance obligations (including adherence to data privacy principles for ethical data protection practices)
• Organization-specific threats (natural and manmade)
• Reasonably-expected industry practices
• Pressure from competition
• Executive management decisions

Risk tolerance is simplified as being one of the following five (5) levels:

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

Low Risk Tolerance

Organizations that would be reasonably-expected to adopt a low risk tolerance generally:

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

Organizations that are reasonably-expected to operate with a low risk tolerance include, but are not limited to:

• Critical infrastructure
• Utilities (e.g., electricity, drinking water, natural gas, sanitation, etc.)
• Telecommunications (e.g., Internet Service Providers (ISPs), mobile phone carriers, Cloud Service Providers (CSPs), etc.) (high value)
• Transportation (e.g., airports, railways, ports, tunnels, fuel delivery, etc.)
• Technology Research & Development (R&D) (high value)
• Healthcare (high value)
• Government institutions:
  • Military
  • Law enforcement
  • Judicial system
  • Financial services (high value)
  • Defense Industrial Base (DIB) contractors (high value)

Moderate Risk Tolerance

Organizations that would be reasonably-expected to adopt a moderate risk tolerance generally:

• Have executive management support for securing sensitive / regulated data enclaves.
• Are in regulated industries that have specific cybersecurity and/or data privacy requirements (e.g., CMMC, PCI DSS, SOX, GLBA, RMF, etc.).
• Have “flow down” requirements from customers that require adherence to certain cybersecurity and/or data privacy requirements.
• Store, process and/or transmit sensitive/regulated data.
• Are legitimate targets for attackers who wish to financially benefit from stolen information or ransom.
• Have cyber-related liability insurance.

Organizations that are reasonably expected to operate with a moderate risk tolerance include, but are not limited to:

• Education (e.g., K-12, colleges, universities, etc.)
• Utilities (e.g., electricity, drinking water, natural gas, sanitation, etc.)
• Telecommunications (e.g., Internet Service Providers (ISPs), mobile phone carriers, etc.)
• Transportation (e.g., airports, railways, ports, tunnels, fuel delivery, etc.)
• Technology services (e.g., Managed Service Providers (MSPs), Managed Security Service Providers (MSSPs), etc.)
• Manufacturing (high value)
• Healthcare
• Defense Industrial Base (DIB) contractors and subcontractors
• Legal services (e.g., law firms)
• Construction (high value)

High Risk Tolerance

Organizations that would be reasonably-expected to adopt a high risk tolerance generally:

• Are in an unregulated industry, pertaining to cybersecurity and/or data privacy requirements.
• Do not store, process and/or transmit sensitive/regulated data.
• Lack management support for cybersecurity and data privacy governance practices.
• Do not have cyber-related liability insurance.

Organizations that may choose to operate with a high risk tolerance include, but are not limited to:

• Startups
• Hospitality industry (e.g., restaurants, hotels, etc.)
• Construction
• Manufacturing
• Personal services

Severe Risk Tolerance

Organizations that would be reasonably-expected to adopt a severe risk tolerance generally:

• Are in an unregulated industry, pertaining to cybersecurity and/or data privacy requirements.
• Do not store, process and/or transmit sensitive/regulated data.
• Lack management support for cybersecurity and data privacy governance practices.
• Do not have cyber-related liability insurance.

Organizations that may choose to operate with a high risk tolerance include, but are not limited to:

• Startups
• Artificial Intelligence (AI) developers

Extreme Risk Tolerance

Organizations that would be reasonably-expected to adopt an extreme risk tolerance generally:

• Are in an unregulated industry, pertaining to cybersecurity and/or data privacy requirements.
• Do not store, process and/or transmit sensitive/regulated data.
• Lack management support for cybersecurity and data privacy governance practices.
• Do not have cyber-related liability insurance.

Organizations that may choose to operate with a high risk tolerance include, but are not limited to:

• Startups
• Artificial Intelligence (AI) developers

 

Defining Risk Threshold

Risk thresholds are directly tied to risk tolerance. As the graphic at the top of the page depicts, there is a threshold between the different levels of risk tolerance. By establishing thresholds, it brings the "graduated scale perspective" to life.

Risk thresholds are entirely unique to each organization, based on several factors that include:

• Financial stability;
• Management preferences;
• Compliance obligations (e.g., statutory, regulatory and/or contractual); and
• Insurance coverage limits.

Examples of how risk thresholds are unique to each organization include:

• Defining specific activities / scenarios that could damage the organization’s reputation;
• Defining specific activities / scenarios that could negatively affect short-term and long-term profitability; and
• Defining specific activities / scenarios that could impede business operations.

 

Examples of Cyber Materiality

The following examples are organized according to the thirty-three (33) domains that make up the Secure Controls Framework (SCF). These are examples of deficiencies where it is probable that threats associated with those specific controls would not be prevented or detected in a timely manner, which would directly or indirectly affect that organization’s ability to adhere to its risk tolerance (from a reasonable person’s perspective).

Cybersecurity & Data Privacy Governance (GOV)

Domain Principle: Execute a documented, risk-based program that supports business objectives while encompassing appropriate security and data privacy principles that addresses applicable statutory, regulatory and contractual obligations.

Reasonable Material GOV Deficiencies:

• GOV-01 – lack of a formal cybersecurity program
• GOV-02 – lack of documented policies and standards
• GOV-04 – lack of assigned responsibilities for running the security program

Artificial Intelligence and Autonomous Technology (AAT)

Domain Principle: Ensure trustworthy and resilient Artificial Intelligence (AI) and autonomous technologies to achieve a beneficial impact by informing, advising or simplifying tasks, while minimizing emergent properties or unintended consequences.

Reasonable Material AAT Deficiencies:

• AAT-01 – lack of governance for Artificial Intelligence (AI) and Autonomous Technologies (AAT)
• AAT-07 – lack of technology risk management for AAT
• AAT-10 – lack of testing, evaluation, validation and verification for AAT

Asset Management (AST)

Domain Principle: Manage all technology assets from purchase through disposition, both physical and virtual, to ensure secured use, regardless of the asset’s location.

Reasonable Material AST Deficiencies:

• AST-02 – lack of asset inventories
• AST-04 – lack of network / data flow diagrams
• AST-12 – lack of controls over personal technology usage

Business Continuity & Disaster Recovery (BCD)

Domain Principle: Maintain a resilient capability to sustain business-critical functions while successfully responding to and recovering from incidents through well-documented and exercised processes.

Reasonable Material BCD Deficiencies:

• BCD-01 – lack of a business continuity capability
• BCD-11 – lack of backups

Capacity & Performance Planning (CAP)

Domain Principle: Govern the current and future capacities and performance of technology assets.

Reasonable Material CAP Deficiencies:

•  CAP-01 – lack of capability / performance management

Change Management (CHG)

Domain Principle: Manage change in a sustainable and ongoing manner that involves active participation from both technology and business stakeholders to ensure that only authorized changes occur.

Reasonable Material CHG Deficiencies:

• CHG-01 – lack of formal change management practices
• CHG-02 – lack of configuration change control

Cloud Security (CLD)

Domain Principle: Govern cloud instances as an extension of on-premise technologies with equal or greater security protections than the organization’s own internal cybersecurity and data privacy controls.

Reasonable Material CLD Deficiencies:

• CLD-06 – lack of control over multi-tenant environments
• CLD-09 – lack of control over geographic processing and storage locations

Compliance (CPL)

Domain Principle: Oversee the execution of cybersecurity and data privacy controls to ensure appropriate evidence required due care and due diligence exists to meet compliance with applicable statutory, regulatory and contractual obligations.

Reasonable Material CPL Deficiencies:

• CPL-01 – lack of situational awareness of compliance obligations
• CPL-02 – lack of oversight on security and data privacy controls

Configuration Management (CFG)

Domain Principle: Enforce secure configurations for systems, applications and services according to vendor-recommended and industry-recognized secure practices.

Reasonable Material CFG Deficiencies:

• CFG-02 – lack of system hardening practices
• CFG-03 – lack of “least functionality” enforcement

Continuous Monitoring (MON)

Domain Principle: Maintain situational awareness of security-related events through the centralized collection and analysis of event logs from systems, applications and services.

Reasonable Material MON Deficiencies:

• MON-01 – lack of monitoring capabilities
• MON-01.8 – lack of a review process for event logs
• MON-07 – lack of time synchronization for logs

Cryptographic Protections (CRY)

Domain Principle: Utilize appropriate cryptographic solutions and industry-recognized key management practices to protect the confidentiality and integrity of sensitive data both at rest and in transit.

Reasonable Material CRY Deficiencies:

• CRY-03 – lack of cryptographic protection for sensitive/regulated data in transit
• CRY-05 – lack of cryptographic protection for sensitive/regulated data at rest

Data Classification & Handling (DCH)

Domain Principle: Enforce a standardized data classification methodology to objectively determine the sensitivity and criticality of all data and technology assets so that proper handling and disposal requirements can

be followed.

Reasonable Material DCH Deficiencies:

• DCH-02 – lack of data and asset classification
• DCH-14 – lack of protections on data sharing

Embedded Technology (EMB)

Domain Principle: Provide additional scrutiny to reduce the risks associated with embedded technology, based on the potential damages posed from malicious use of the technology.

Reasonable Material EMB Deficiencies:

• EMB-01 – lack of control over embedded technologies in use

Endpoint Security (END)

Domain Principle: Harden endpoint devices to protect against reasonable threats to those devices and the data those devices store, transmit and process.

Reasonable Material END Deficiencies:

• END-04 – lack of antimalware protection on endpoint devices

Human Resources Security (HRS)

Domain Principle: Execute sound hiring practices and ongoing personnel management to cultivate a security and data privacy-minded workforce.

Reasonable Material HRS Deficiencies:

• HRS-03 – lack of assigned roles and responsibilities for cybersecurity and data protection
• HRS-05 – lack of terms of employment (e.g., acceptable behaviors)
• HRS-06.1 – lack of confidentiality agreements

Identification & Authentication (IAC)

Domain Principle: Enforce the concept of “least privilege” consistently across all systems, applications and services for individual, group and service accounts through a documented and standardized Identity and Access Management (IAM) capability.

Reasonable Material IAC Deficiencies:

• IAC-01 – lack of capability to facilitate the implementation of identification and access management controls.
• IAC-07 – lack of secure user provisioning / deprovisioning
• IAC-10 – lack of secure authenticator management practices
• IAC-10.8 – lack of a process to remove vendor default passwords
• IAC-17 – lack of a process to periodically review assigned user privileges

Incident Response (IRO)

Domain Principle: Maintain a viable incident response capability that trains personnel on how to recognize and report suspicious activities so that trained incident responders can take the appropriate steps to handle incidents, in accordance with a documented Incident Response Plan (IRP).

Reasonable Material IRO Deficiencies:

• IRO-02 – lack of a process to report, analyze, contain, eradicate and recover from incidents
• IRO-08 – lack of a capability to maintain the chain of custody for evidence
• IRO-10.2 – lack of a capability to report cybersecurity incidents (e.g., regulated reporting requirements)

Information Assurance (IAO)

Domain Principle: Execute an impartial assessment process to validate the existence and functionality of appropriate cybersecurity and data privacy controls, prior to a system, application or service being used in a production environment.

Reasonable Material IAO Deficiencies:

• IRO-02 – lack of a capability of assess cybersecurity and data privacy controls to ensure systems, applications and services going into production are secure.
• IAO-03 – lack of a System Security Plan (SSP), or similar documentation, the describes the controls in place for projects
• IAO-05 – lack of a risk register (e.g., Plan of Action and Milestones) that tracks the remediation process for identified deficiencies

Maintenance (MNT)

Domain Principle: Proactively maintain technology assets, according to current vendor recommendations for configurations and updates, including those supported or hosted by third-parties.

Reasonable Material MNT Deficiencies:

• MNT-02 – lack of performing necessary maintenance throughout the lifecycle of systems, applications and services

Mobile Device Management (MDM)

Domain Principle: Implement measures to restrict mobile device connectivity with critical infrastructure and sensitive data that limit the attack surface and potential data exposure from mobile device usage.

Reasonable Material MDM Deficiencies:

• MDM-01 – lack of control over mobile devices

Network Security (NET)

Domain Principle: Architect and implement a secure and resilient defense-in-depth methodology that enforces the concept of “least functionality” through restricting network access to systems, applications and services.

Reasonable Material NET Deficiencies:

• NET-03 – lack of appropriate boundary protections
• NET-04 – lack of data flow enforcement (e.g., access control lists)
• NET-19 – lack of control over the remote access technologies

Physical & Environmental Security (PES)

Domain Principle: Protect physical environments through layers of physical security and environmental controls that work together to protect both physical and digital assets from theft and damage.

Reasonable Material PES Deficiencies:

• PES-03 – lack of appropriate physical access control
• PES-06 – lack of appropriate visitor control

Data Privacy (PRI)

Domain Principle: Align data privacy practices with industry-recognized data privacy principles to implement appropriate administrative, technical and physical controls to protect regulated personal data throughout the lifecycle of systems, applications and services.

Reasonable Material PRI Deficiencies:

• PRI-01 – lack of a formal data privacy program
• PRI-05.4 – lack of control on the internal usage of sensitive personal data
• PRI-07 – lack of control over sharing sensitive personal data with third parties

Project & Resource Management (PRM)

Domain Principle: Operationalize a viable strategy to achieve cybersecurity & data privacy objectives that establishes cybersecurity as a key stakeholder within project management practices to ensure the delivery of resilient and secure solutions.

Reasonable Material PRM Deficiencies:

• PRM-04 – lack of security and data privacy in project management
• PRM-07 – lack of lifecycle management (e.g., SDLC)

Risk Management (RSK)

Domain Principle: Proactively identify, assess, prioritize and remediate risk through alignment with industry-recognized risk management principles to ensure risk decisions adhere to the organization's risk threshold.

Reasonable Material RSK Deficiencies:

• RSK-03 – lack of risk identification
• RSK-04 – lack of risk assessments
• RSK-10 – lack of Data Protection Risk Assessments (DPIAs)

Secure Engineering & Architecture (SEA)

Domain Principle: Utilize industry-recognized secure engineering and architecture principles to deliver secure and resilient systems, applications and services.

Reasonable Material SEA Deficiencies:

• SEA-01 – lack of secure engineering principles
• SEA-03 – lack of a defense-in-depth architecture

Security Operations (OPS)

Domain Principle: Execute the delivery of security and data privacy operations to provide quality services and secure systems, applications and services that meet the organization’s business needs.

Reasonable Material OPS Deficiencies:

• OPS-01.1 – lack of Standardized Operating Procedures (SOP)

Security Awareness & Training (SAT)

Domain Principle: Foster a security and data privacy-minded workforce through ongoing user education about evolving threats, compliance obligations and secure workplace practices.

Reasonable Material SAT Deficiencies:

• SAT-03 – lack of role-based training for cybersecurity and data privacy

Technology Development & Acquisition (TDA)

Domain Principle: Develop and test systems, applications or services according to a Secure Software Development Framework (SSDF) to reduce the potential impact of undetected or unaddressed vulnerabilities and design weaknesses.

Reasonable Material TDA Deficiencies:

• TDA-01 – lack of a formal capability to manage technology development and acquisition
• TDA-06 – lack of secure coding practices
• TDA-08 – lack of separation between test/dev/staging/prod environments

Third-Party Management (TPM)

Domain Principle: Execute Supply Chain Risk Management (SCRM) practices so that only trustworthy third-parties are used for products and/or service delivery.

Reasonable Material TPM Deficiencies:

• TPM-01 – lack of a formal capability to manage third-party service providers
• TPM-05 – lack of contractual obligations for third-parties for cybersecurity and data protection

Threat Management (THR)

Domain Principle: Proactively identify and assess technology-related threats, to both assets and business processes, to determine the applicable risk and necessary corrective action.

Reasonable Material THR Deficiencies:

• THR-02 – lack of Indicators of Compromise (IoC)
• THR-03 – lack of threat intelligence feeds to maintain situational awareness of threat activity

Vulnerability & Patch Management (VPM)

Domain Principle: Leverage industry-recognized Attack Surface Management (ASM) practices to strengthen the security and resilience systems, applications and services against evolving and sophisticated attack vectors.

Reasonable Material VPM Deficiencies:

• VPM-02 – lack of a vulnerability remediation capability
• VPM-05 – lack of a capability to manage software/firmware patching

Web Security (WEB)

Domain Principle: Ensure the security and resilience of Internet-facing technologies through secure configuration management practices and monitoring for anomalous activity.

Reasonable Material WEB Deficiencies:

• WEB-01 – lack of secure website management practices
• WEB-04 – lack of security for client-facing web services