Drata _ IT Risk Register Standard – Risk Naming and Classification
Purpose
This standard establishes a consistent naming convention and documentation format for entries in the Information Security Risk Register. A standardized approach improves reporting, enables easier sorting and filtering, supports audit readiness, and provides consistency across risk assessments aligned to frameworks such as NIST SP 800-53, NIST Cybersecurity Framework (CSF), and the GLBA Safeguards Rule.
Risk Identification
Risk ID Format
Each risk shall be assigned a unique identifier using the following format:
R-<Domain>-###
Example:
- R-EPM-001
- R-IAM-004
- R-VRT-002
Where:
- R = Risk
- Domain = Functional security domain
- ### = Sequential number within that domain
Risk IDs are permanent identifiers and shall not change even if the title or description is updated.
Risk Domains
The following domain abbreviations should be used when assigning new risks.
| Code | Domain |
|---|---|
| AI | Artificial Intelligence |
| GOV | Governance & Compliance |
| RSK | Enterprise Risk Management |
| AST | Asset Management |
| EPM | Endpoint Management |
| IAM | Identity & Access Management |
| NET | Network Security |
| APP | Application Security |
| DAT | Data Protection |
| VRT | Virtualization Infrastructure |
| CLD | Cloud Security |
| LOG | Logging & Monitoring |
| VUL | Vulnerability Management |
| IR | Incident Response |
| BCM | Business Continuity & Disaster Recovery |
| VRM | Vendor Risk Management |
| PHY | Physical Security |
Additional domains may be created as organizational needs evolve.
Risk Title Standard
Risk titles should:
- Be concise (typically 3–8 words)
- Describe the risk condition rather than the corrective action
- Remain technology-neutral whenever practical
- Avoid framework references (e.g., "SI-2 Finding")
- Avoid including remediation activities
Good Examples
- Unpatched Endpoint Systems
- Unsupported VMware NSX Platform
- Excessive Administrative Privileges
- Dormant User Accounts
- Incomplete Asset Inventory
- Weak Multi-Factor Authentication
- Unencrypted Sensitive Data
Avoid
- Patch Management
- VMware Licensing Issue
- SI-2 Deficiency
- Fix Windows Updates
- Security Finding
Risk Description Standard
Each description should explain:
- The current condition.
- Why the condition creates risk.
- The potential business impact.
A recommended structure is:
Condition results in threat, which could lead to business impact.
Example
Endpoint systems within the laboratory environment are not consistently patched according to organizational standards. As a result, known vulnerabilities may remain exploitable, increasing the likelihood of unauthorized access, malware infection, operational disruption, and compromise of institutional systems or data.
Descriptions should describe the risk itself—not the remediation plan.
Recommended Risk Register Fields, Scoring, Strategies & Mapping
Each description should explain:
Each risk should include, at a minimum:
- Risk ID
- Risk Domain
- Risk Title
- Risk Description
- Affected Environment
- Business Owner
- Risk Owner
- Inherent Likelihood
- Inherent Impact
- Overall Inherent Risk
- Existing Controls
- Treatment Strategy
- Treatment Plan
- Target Completion Date
- Residual Likelihood
- Residual Impact
- Overall Residual Risk
- Current Status
- Framework Mapping
- Review Date
Organizations may include additional fields as needed.
Treatment Strategies
Every risk shall be assigned one treatment strategy.
| Strategy | Definition |
| Mitigate | Implement or improve controls to reduce the likelihood and/or impact of the risk. |
| Accept | Formally acknowledge and retain the risk without additional controls. |
| Avoid | Eliminate the activity, technology, or process that creates the risk. |
| Transfer | Shift financial or operational responsibility to a third party (e.g., insurance, managed service provider, contractual agreements). |
| Untreated | No treatment decision has been made or implementation has not yet begun. |
In most information security scenarios, Mitigate will be the appropriate treatment strategy.
Risk Scoring Guidance
Risk should be assessed both before and after planned treatment.
Inherent Risk
- Represents the level of risk before considering planned mitigation activities.
Residual Risk
- Represents the level of risk expected after treatment has been implemented.
Likelihood and Impact should be evaluated using the organization's approved risk matrix.
Framework Mapping
Framework references should be maintained separately from the risk title and description.
Common mappings may include:
- NIST SP 800-53 Rev. 5
- NIST Cybersecurity Framework (CSF) 2.0
- GLBA Safeguards Rule
- CIS Critical Security Controls
Maintaining mappings independently allows the same risk to satisfy multiple compliance and governance requirements without creating duplicate entries.
Example
Risk ID: R-EPM-001
Title: Unpatched Endpoint Systems
Description:
Endpoint systems are not consistently patched within established organizational timeframes. Known vulnerabilities may remain exploitable, increasing the likelihood of malware infection, unauthorized access, operational disruption, and compromise of institutional information assets.
Treatment Strategy: Mitigate
Framework Mapping: NIST SP 800-53 SI-2, RA-5; NIST CSF PR.PS; GLBA Safeguards Rule
Last Updated: 11/25/25