Skip to main content
HIPAA Path
Category: HITRUST CSF and Scoring

Threat Catalogue

Also known as: Threat Catalog, Threat List
Simply put

A threat catalogue is a structured list of common information security threats, including the events, sources, and actions that could potentially harm an organization's systems or data. Organizations typically use it as a reference when identifying and assessing the risks they face. In a healthcare compliance context, it can support the risk analysis process by helping teams consider a broad range of potential threats to protected health information.

Formal definition

A threat catalogue is a curated, generally topically organized repository of information security threats that describes and structures potential threat events, threat sources, and harmful actions or inactions relevant to information systems. Examples include NIST's Mobile Threat Catalogue (MTC), which catalogues threats to mobile information systems, and schema-based catalogues such as the OpenSSF Gemara ThreatCatalog, which defines a set of topically associated threats as a metadata object containing a list of threat entries. Threat catalogues are commonly used as inputs to risk assessment and threat modeling workflows and may be paired with vulnerability-oriented resources such as CISA's Known Exploited Vulnerabilities (KEV) Catalog for prioritization. Note that a threat catalogue is not itself a regulatory requirement or a HIPAA-defined term; while the HIPAA Security Rule requires a risk analysis addressing threats and vulnerabilities to ePHI, it does not mandate use of any specific catalogue, and organizations should verify current regulatory expectations and select catalogues appropriate to their environment.

Why it matters

The HIPAA Security Rule requires covered entities and business associates to conduct a risk analysis that accounts for reasonably anticipated threats and vulnerabilities to electronic protected health information (ePHI). A threat catalogue supports that process by giving teams a structured, pre-organized reference of common threat events, sources, and actions, so that a risk analysis is less likely to overlook categories of harm that might otherwise go unconsidered. Using a recognized catalogue as an input can bring consistency and thoroughness to what is often an ad hoc exercise.

It is important to understand the limits of this tool in a compliance context. A threat catalogue is not a HIPAA-defined term, and the Security Rule does not mandate the use of any particular catalogue. Adopting one, whether NIST's Mobile Threat Catalogue, a schema-based resource such as the OpenSSF Gemara ThreatCatalog, or an internally maintained list, does not by itself satisfy the risk analysis obligation or establish HIPAA compliance. The catalogue is a reference input; the organization still must perform and document an analysis appropriate to its own environment, systems, and data flows.

Because no single catalogue covers every environment, teams generally need to select or tailor catalogues to their actual systems. A mobile-focused catalogue, for example, addresses threats to mobile information systems but would not on its own cover threats to on-premises servers or paper-based workflows. Organizations should treat a threat catalogue as one component of a broader risk management program and verify their approach against current regulatory expectations, noting that state law, the HITECH Act, or other frameworks may impose additional requirements.

Who it's relevant to

Security Officers and Risk Analysts
Those responsible for conducting the HIPAA Security Rule risk analysis can use a threat catalogue as a structured starting point for enumerating reasonably anticipated threats to ePHI, helping ensure a broad range of threat sources and events is considered. They should tailor the catalogue to their environment and document their analysis, rather than treating adoption of a catalogue as sufficient on its own.
Compliance and Privacy Officers
Compliance staff overseeing risk management programs should understand that a threat catalogue is a supporting reference, not a HIPAA-defined term or regulatory requirement. It can strengthen the defensibility and consistency of a risk analysis, but it does not by itself establish compliance, and current regulatory expectations should be verified.
IT and Security Teams Performing Threat Modeling
Technical teams building threat models for systems that handle ePHI can use catalogues as inputs to enumerate threats and, when paired with vulnerability resources such as CISA's KEV Catalog, prioritize remediation. Domain-specific catalogues, such as those focused on mobile systems, should be selected to match the systems actually in scope.

Inside Threat Catalogue

Enumerated Threats
A structured list of potential threats that could compromise the confidentiality, integrity, or availability of information, including electronic protected health information (ePHI). In the HITRUST context, a threat catalogue is typically maintained by HITRUST as part of its CSF resources; readers should verify current contents against the applicable HITRUST CSF version.
Threat Sources or Actors
Categorization of where threats originate, such as adversarial human actors, non-adversarial human error, structural failures (equipment or software), and environmental or natural hazards. This helps organizations reason about likelihood and applicable safeguards.
Mapping to Controls
Associations between identified threats and the controls or safeguards intended to mitigate them. Under the HIPAA Security Rule, such mappings generally support administrative, physical, and technical safeguards, though a HITRUST threat catalogue is a private framework tool and is not itself a HIPAA requirement.
Risk Assessment Input
A reference resource used to inform an organization's risk analysis by helping identify reasonably anticipated threats. The Security Rule generally requires a covered entity or business associate to assess risks and vulnerabilities to ePHI, and a threat catalogue can support but does not replace that analysis.
Vulnerability Pairing
The concept that a threat is meaningful primarily when paired with a vulnerability it could exploit; catalogues are typically used alongside vulnerability information to estimate risk.

Common questions

Answers to the questions practitioners most commonly ask about Threat Catalogue.

Does HIPAA require organizations to maintain a formal threat catalogue?
Not by that specific name. The HIPAA Security Rule requires covered entities and business associates to conduct an accurate and thorough risk analysis that identifies reasonably anticipated threats to the confidentiality, integrity, and availability of ePHI. A threat catalogue is a practical tool many organizations use to support that requirement, but the regulatory text does not mandate a document called a threat catalogue or prescribe its exact format. Readers should confirm the specific risk analysis expectations against the current Security Rule text and applicable OCR guidance.
Does using the HITRUST CSF threat catalogue mean an organization is HIPAA compliant?
No. HITRUST is a private organization and the HITRUST CSF is a certifiable control framework, not a legal requirement. Leveraging a threat catalogue drawn from or aligned with the HITRUST CSF may help structure a risk analysis, but it does not by itself establish HIPAA compliance. HIPAA is enforced by HHS OCR, and compliance is assessed against the regulatory requirements themselves. Any threat catalogue content associated with the HITRUST CSF should be verified against the current CSF version.
What types of threats should a threat catalogue generally include?
A threat catalogue typically groups threats into categories such as environmental and natural events, human threats (both accidental and intentional), technical or system failures, and threats introduced through third parties. Because the HIPAA Security Rule applies only to ePHI, a catalogue supporting a Security Rule risk analysis generally focuses on threats to electronic information systems. Organizations addressing PHI in all forms under the Privacy Rule may extend related threat identification to oral and paper information as well, though that falls outside the Security Rule's technical scope.
How does a threat catalogue relate to the risk analysis process?
A threat catalogue generally serves as an input to the risk analysis. Once threats are identified, they are typically paired with vulnerabilities and assessed for likelihood and potential impact to determine risk. The catalogue helps ensure the analysis is thorough by prompting consideration of a broad range of reasonably anticipated threats. It does not replace the analysis itself, and it does not determine which safeguards are required versus addressable under the Security Rule.
How often should a threat catalogue be reviewed or updated?
There is no single fixed interval mandated in the regulatory text for updating a threat catalogue specifically. In most cases, organizations review threat information as part of periodic risk analysis and whenever significant changes occur, such as new technologies, new business relationships, or changes in the threat environment. Because risk analysis is generally treated as an ongoing process rather than a one-time event, keeping the catalogue current supports that expectation. Confirm timing expectations against current OCR guidance.
Who should be involved in building and maintaining a threat catalogue?
In practice, developing a threat catalogue often involves collaboration among security and privacy officers, IT staff, and personnel familiar with operational and physical environments. Because threats can arise through business associates and subcontractors, input regarding third-party relationships may also be relevant, with related obligations flowing through business associate agreements rather than attaching to every vendor automatically. The appropriate participants generally depend on the organization's size, complexity, and information systems.

Common misconceptions

Using a threat catalogue satisfies the HIPAA Security Rule risk analysis requirement.
A threat catalogue is a supporting reference, not a completed risk analysis. The Security Rule generally requires an organization-specific assessment of risks and vulnerabilities to ePHI. A catalogue can inform that process but does not by itself demonstrate compliance, and outputs should be tailored to the organization's actual environment.
A HITRUST threat catalogue is a HIPAA regulatory document issued by HHS OCR.
HITRUST is a private organization and its CSF and related resources are not legal requirements enforced by HHS OCR. Relying on a HITRUST threat catalogue does not by itself establish HIPAA compliance. Practitioners should distinguish the private framework tool from the federal regulatory text.
A threat catalogue lists every threat an organization needs to consider.
Catalogues are generally intended to be representative starting points, not exhaustive. Emerging threats, organization-specific factors, and requirements from state law or the HITECH Act may introduce additional considerations. Contents and versions change over time and should be verified against current guidance.

Best practices

Use a threat catalogue as an input to, not a substitute for, an organization-specific risk analysis that considers your actual ePHI, systems, and workflows.
Pair each catalogued threat with relevant vulnerabilities and map them to administrative, physical, and technical safeguards, remembering that addressable implementation specifications are not optional and must be evaluated.
Confirm the catalogue you rely on against the current HITRUST CSF version or applicable source, since contents and version numbers change over time.
Keep clear documentation distinguishing HITRUST framework tools from HIPAA regulatory obligations, and avoid treating catalogue use as evidence of legal compliance.
Review and update your threat considerations periodically to account for emerging threats and any additional requirements imposed by state law or the HITECH Act.
Extend threat consideration across defined relationships, including business associates and subcontractors, recognizing that obligations attach through business associate agreements rather than to every vendor automatically.