Risk Management
Risk Management in Tripl-i helps teams capture, organize, and review risks that affect the organization’s systems, services, compliance obligations, and business operations.
The risk module is designed to work alongside Compliance and the CMDB. Compliance shows whether controls are operating effectively. The risk register helps teams understand what could go wrong, where it applies, who owns it, and how it should be reviewed.
Key Concepts
Risk Library
The Risk Library is a reusable catalog of risk templates. A template describes a general risk that may apply in different parts of the organization.
Examples:
- Unauthorized privileged access
- Datacenter power outage
- Expired certificate on a critical service
- Unpatched externally exposed server
- Loss of critical third-party service
- Incomplete asset ownership data
Each risk template can include:
- Name and description
- Category
- Potential impact
- Common triggers
- Tags
- Status
- Related controls
Use the Risk Library when you want a consistent vocabulary for risk across teams.
Risk Register
The Risk Register contains specific risk statements. A risk statement applies a risk template to a specific business, infrastructure, or operational context.
Example:
| Risk template | Risk statement |
|---|---|
| Datacenter power outage | Power outage risk for primary production datacenter |
| Expired certificate | Certificate expiry risk for customer portal |
| Unauthorized privileged access | Privileged access risk for production database servers |
Each risk statement can include:
- Title
- Linked risk template
- Affected CIs
- Owner
- Priority
- Status
- Risk appetite
- Review frequency
- Notes
- Inherent and residual risk scores, when available
Risk Categories
Tripl-i supports multiple risk categories so teams can organize risk in a way that matches their business.
| Category | Example |
|---|---|
| Operational | A critical service becomes unavailable |
| Compliance | A required control is not operating effectively |
| Financial | A system issue affects billing or revenue reporting |
| Strategic | A major dependency creates business continuity exposure |
| Reputational | A customer-facing outage or data issue damages trust |
| Security | A vulnerability, access issue, or misconfiguration increases exposure |
Risk Statuses
Risk statements move through a practical lifecycle.
| Status | Meaning |
|---|---|
| Identified | The risk has been captured and needs review |
| Assessed | The risk has been analyzed and scored |
| In treatment | A response or mitigation activity is underway |
| Monitored | The risk is being watched through normal review cycles |
| Closed | The risk no longer applies or has been resolved |
Risk Scoring
Risk scoring helps teams compare risk consistently.
Tripl-i supports inherent and residual risk concepts:
- Inherent risk describes the risk before controls or mitigations are considered.
- Residual risk describes the risk after existing controls and mitigations are considered.
Risk scores help teams decide whether a risk is acceptable, needs mitigation, or requires escalation.
Affected Systems
Risk statements can be linked to affected configuration items in the CMDB.
This matters because risk is more actionable when teams know exactly which systems are involved. A risk attached to “production database servers” is easier to assign, review, and remediate than a generic risk statement with no infrastructure context.
Use affected CIs to connect risks to:
- Servers
- Databases
- Network devices
- Workstations
- Business services
- Applications
- Other configuration items
Related Controls
Risks can be linked to controls that reduce likelihood or impact.
For example:
| Risk | Related controls |
|---|---|
| Unauthorized access | Access reviews, MFA, privileged access monitoring |
| Expired certificates | Certificate inventory, expiry monitoring, renewal process |
| Unpatched systems | Vulnerability scanning, patch management, exception review |
| Loss of audit logs | Log retention, backup monitoring, SIEM forwarding checks |
This creates a clearer connection between risk management and compliance operations.
Working With The Risk Library
Create a Risk Template
- Navigate to GRC → Risk Library.
- Select Add Risk Template.
- Enter the risk name and description.
- Select the risk category.
- Set the potential impact.
- Add common triggers and tags.
- Set the status.
- Save the risk template.
Maintain Risk Templates
Review the Risk Library periodically to:
- Retire risks that no longer apply
- Update descriptions and triggers
- Add new risks discovered during incidents, audits, or assessments
- Standardize naming across teams
- Link risks to relevant controls
Working With The Risk Register
Create a Risk Statement
- Navigate to GRC → Risk Register.
- Select Add Risk Statement.
- Choose a risk template from the library.
- Enter a specific title for the risk statement.
- Select affected CIs.
- Assign an owner.
- Set priority and status.
- Define review frequency and risk appetite.
- Save the risk statement.
Review Risk Statements
Use the Risk Register to review:
- High-priority risks
- Risks with upcoming review dates
- Risks without owners
- Risks linked to critical systems
- Risks where residual score exceeds appetite
- Risks related to recent compliance failures or incidents
How Risk Connects To Compliance
Risk and compliance should reinforce each other.
Compliance tells you whether controls are being performed. Risk tells you why those controls matter and what could happen if they fail.
Examples:
- A failed access review assessment can increase concern around unauthorized access risk.
- A non-compliant certificate control can highlight service availability or trust risk.
- A repeated vulnerability finding can support a higher priority for patch management risk.
- A missing asset owner can create accountability risk for remediation and change approval.
How Risk Connects To Discovery And Service Mapping
Discovery and service mapping make risk more specific.
Discovery keeps the list of affected systems current. Service mapping helps explain business impact.
For example:
- A risk on a standalone test server may be low priority.
- The same risk on a server supporting payment processing may require urgent review.
Use CMDB and service context to prioritize risks based on:
- Business criticality
- Service dependencies
- Asset ownership
- Exposure
- Vulnerabilities
- Compliance scope
- Operational history
Advantages
Consistent Risk Language
The Risk Library gives teams a common vocabulary. This helps reduce duplicate risk names and inconsistent descriptions across departments.
Clear Ownership
Risk statements assign accountability. Teams can see who owns each risk and when it needs review.
Better Prioritization
Risk priority, scores, affected CIs, and service context help teams focus on the risks that matter most.
Stronger Audit Conversations
Risk statements linked to controls and systems help auditors understand how the organization identifies, evaluates, and monitors risk.
Infrastructure-Aware Decisions
Because risks can be linked to CIs, teams can connect GRC decisions to real systems instead of relying only on abstract risk registers.
Best Practices
- Use the Risk Library for reusable risk types.
- Use the Risk Register for specific real-world risk statements.
- Assign an owner to every active risk statement.
- Link risks to affected CIs whenever possible.
- Review high-priority risks more frequently.
- Use consistent naming for risk statements.
- Link risks to controls that reduce likelihood or impact.
- Revisit risks after incidents, failed assessments, major changes, or new discoveries.