Risk Management Workflow for IT Compliance

End-to-End Example: Over-Privileged Access Risk

Follow how Sarah, a Compliance Administrator, and Maria, a Risk Owner, identify and manage a compliance risk that threatens policy for Least Privilege requirements.

Phase 1: Identify and Register the Risk

Sarah opens the Risk Scenario Library to find a template for access control risks. She selects the Over-Privileged Access to Sensitive Data scenario, which provides a standardized description and suggested likelihood/impact ratings based on similar risks in other organizations.

She creates a Compliance Risk called Over-Privileged Access to Customer Data based on the scenario template. The risk describes the threat that IT personnel could gain unauthorized access to customer data due to excessive permissions in production systems.

Sarah assigns Maria, the IT Director, as the risk owner. Maria is responsible for ensuring mitigating controls are in place and responding when the risk materializes.

Sarah sets the risk category to Access Control and the status to Identified. The risk has not yet been evaluated or scored.

Phase 2: Define Risk Scope

Sarah creates a Risk Scope record to define what this risk threatens and which safeguards protect it. She uses junction records to create traceable links:

• Business process mapping: Link the risk to the Customer Data Processing business operations process. This mapping shows which operational workflow the risk threatens.
• Risk Scope Type: Apply a Risk Scope to the risk by using a Risk Scope Type that categorizes what's at risk — for example, the Configuration Item Risk Scope Type pointing to the production AWS accounts tracked in the CMDB. If a suitable Risk Scope Type doesn't exist yet, Sarah creates one first. See Define and Apply Risk Scope for IT Compliance.
• Policy mapping: Link the risk to the Data Access Policy: RBAC with Least Privilege policy clause. The risk represents a potential violation of the internal policy.
• Asset mapping: Link the risk to production AWS accounts tracked as assets in the CMDB. This mapping shows which specific systems are vulnerable.
• Control mapping: Link the risk to the RBAC Enforcement Check control version. This control is designed to mitigate the risk by verifying that access rights match job functions. She assigns a control effectiveness rating of 80%, indicating that when the control is operating correctly, it reduces the risk's impact by 80%.

Phase 3: Evaluate the Risk

Sarah creates a Compliance Risk Evaluation to formally assess the risk. She sets the evaluation date to the current date and the methodology to Stakeholder Survey.

Sarah creates a Compliance Risk Assessment using Salesforce Surveys. The survey includes two key questions:

• Likelihood: "How likely is it that IT personnel will gain unauthorized access to customer data due to over-privileged access?" (Scale: 1 = Very Low, 5 = Very High)
• Impact: "If unauthorized access occurs, how severe would the impact be on customer trust, regulatory compliance, and business operations?" (Scale: 1 = Very Low, 5 = Very High)

Sarah sends the survey to Maria (IT Director) and three other stakeholders: the CISO, the Head of Cloud Infrastructure, and the Compliance Manager. Each stakeholder receives an email notification with a link to the survey.

All stakeholders complete their assessments. The average likelihood rating is 3 (Medium) and the average impact rating is 4 (High).

Phase 4: Calculate Risk Scores

After all stakeholders submit their survey responses, Sarah reviews the aggregated feedback and calculates the risk scores using the Business Rules Engine.

Inherent risk is the natural severity of the risk without any controls applied. The formula is: Inherent Risk = Likelihood × Impact

Based on the survey results, the inherent risk score is calculated as 12 which falls in the High range (10-15). This means that without any controls, the Over-Privileged Access risk poses a significant threat to the organization.

Residual risk is the remaining severity after controls are applied. The formula is Residual Risk = Inherent Risk × (1 - Control Effectiveness).

The RBAC Enforcement Check control is linked to the risk with an 80% effectiveness rating. The calculated residual risk score of 2.4 falls in the Low range (0-5). This means the RBAC control is effectively reducing the risk from High to Low.

Sarah records both scores in the Compliance Risk Evaluation recordand updates the record status to Completed.

Phase 5: Review AI-Generated Risk Summary

Sarah generates a Risk Summary to create an AI-powered narrative explaining the risk drivers and scoring rationale. The summary identifies three risk drivers: periodic audits detected excessive permissions, production systems contain sensitive data subject to compliance regulations, and cloud infrastructure growth makes manual audits harder.

The summary confirms the RBAC control's 80% effectiveness reflects its testing history (8 out of 10 tests passed) and recommends continuing quarterly testing plus continuous monitoring. Because residual risk is Low, no immediate treatment is required.

Phase 6: Continuous Monitoring and Heat Map

Sarah configures a background monitoring agent to watch for new users, IAM role changes, and control test failures. When detected, the agent triggers a new risk evaluation and notifies Maria.

Sarah reviews the risk on the Risk Heat Map dashboard. The heat map plots risks by likelihood and impact, color-coding the Over-Privileged Access risk as Low (green) based on its residual risk score of 2.4, showing controls are effectively mitigating the threat.

Phase 7: Control Failure Triggers Dynamic Risk Update

In Q2, the RBAC control fails its quarterly test. Three users have over-privileged access.

The system automatically updates the risk:

• Control effectiveness drops to 0%
• Residual risk recalculates: 12 × (1 - 0.00) = 12 (High)
• Maria receives an alert that residual risk increased from 2.4 to 12
• Heat map changes from green to red
• Background agent creates a Compliance Finding

Phase 8: Risk Treatment Plan

Sarah creates a Risk Treatment Plan using the Access Rights Remediation template. The template includes tasks to review access rights, revoke excessive permissions, document changes, rerun the test, and upload evidence.

Maria's team completes the remediation. When the retest passes:

• Control effectiveness restores to 80%
• Residual risk recalculates: 12 × (1 - 0.80) = 2.4 (Low)
• Maria receives confirmation that risk decreased from 12 to 2.4
• Heat map returns to green

Sarah closes the treatment plan and marks the risk status as Mitigated.

Risk Hierarchy and Parent-Child Relationships

Establish parent-child relationships where one high-level parent risk rolls up multiple child risks. For example, a parent risk called Global Data Center Security Vulnerabilities can link to child risks for specific servers (Outdated OS on Server A) and firewalls (Expired TLS Certificates on Perimeter Firewalls).

The system automatically rolls up child risk scores to the parent. Executives see the aggregated score while IT teams drill down to specific systems. When a child risk's score increases due to a control failure, the parent risk score updates automatically.