Landing page and dashboard views

The landing page in the Operational Resilience Workspace provides a single-pane overview of the services, business services, and pillars in your organization. The dashboard displays resilience metrics, including operational status, completed activities, red flags, and suggestions for improvement.

The flexible data model introduced with Operational Resilience, Release 21.0.x provides a foundation for the dashboards and tracks the flow of dependent services. The data, including red flags by type, such as failed controls, incidents, and outages, and business service metrics such as number of flags, importance, and impact tolerance, is updated in the dashboard through changes to the flexible data model.

The data shown in the example is for business services such as business service by number of red flags, business service by importance, business service by impact tolerance. You can change it service offerings, business processes, or application services by configuring the sn_oper_res.top_class_name property. You can then change the top class to another object and the system shows data with respect to that specific top class.

Calculation and roll up of red flags

The dashboard shown in the earlier example displays a range of 1-30 red flags. Upon selecting, it shows a detailed breakdown, showing a total of 20 red flags, with 3 specifically attributed to the "cards and payments" level. This illustrates the roll-up functionality, which aggregates red flags beneath the selected "Cards and Payments" business service, providing a hierarchical view of the data.

The value "24" shown in the Total red flags count column is the roll-up value of the red flags for all entities under the "Cards and Payments" business service.

The Calculate red flags for CSDM and dependencies scheduled job does not create new records in the [sn_oper_res_profile] table. Instead, it recomputes the impacted objects for the existing sn_oper_res_profile records using data from the [sn_grc_m2m_profile_profile] table.

The Calculate red flags for CSDM and dependencies scheduled job fetches the red flags for the profiles in the [sn_oper_res_profile] table only when the following conditions are met:

• The sn_oper_res_profile.pillar is not empty.
• The sn_oper_res_profile.applies_to field is not empty.

The red flags fetching mechanism can use either the sn_oper_res_profile.profile condition, the sn_oper_res_profile.applies_to condition, or a combination of both.

The red flags also inherit the impacted objects and impacted object classes from the [sn_oper_res_profile] record. For example if an application service's Operational Resilience profile lists Business service, Offering, and Business process as impacted objects (shown in the Impacted objects column), these objects are copied to all associated red flags for the application service and its related entities.

Note:

The [sn_oper_res_profile] record is created for an entity that is created without the applies_to record. When an entity is linked properly to its respective records, integrations with risks, failed controls, incidents, and issues function properly.

Conditions for calculating the red flags

This section uses the sn_oper_res_profile.profile and sn_oper_res_profile.applies_to conditions for reference. The criteria for calculating red flags and the relevant tables are detailed in the Red flags calculation table.

Table 1. Red flags calculation

Red flags	Table	Conditions	Notes
High risks - Advanced risk	[sn_risk_advanced_risk_assessment_instance]	Conditions: entity_1=profile status=30 summary_residual_risk_score should be greater than the max criteria defined in risk_assessment_methodology Should not have any open assessments linked to sn_risk_advanced_risk_assessment_instance	For all these risks, staging records are created in the [sn_oper_res_risk] table.
Failed controls: Step 1 (Optional)	[sn_compliance_m2m_control_entity] (sn_compliance_control ← → sn_grc_profile)	Conditions: entity=profile control.status=non_compliant control.exempt=false control.state=monitor control.active=true	A list of controls is extracted and are valid red flags.
Failed controls: Step 2	[sn_compliance_control]	Conditions: entity=profile or sys_id in the list of controls control.status=non_compliant control.exempt=false control.state=monitor control.active=true	For all these controls, staging records are created in the [sn_oper_res_failed_control] table.
Issues: Step 1 (Optional)	[sn_grc_m2m_issue_to_entity] (sn_grc_issue ←→ sn_grc_profile)	Conditions: entity=profile sn_grc_issue.active=true	A list of issues is extracted and are valid red flags.
Issues: Step 2 (Optional) If one of the following pillars is used, then this step is considered: Service Business service Offering	[sn_oper_res_m2m_scenario_event_issue] (scenario_event ←→ sn_grc_issue) [sn_oper_res_m2m_scenario_event_service] (scenario_event ←→ service)	A joint query is performed using the two tables and [sn_grc_issue] is fetched for the service, business service, and offering.	These are appended in the list of issues from step 1.
Issues: Step 3	[sn_grc_issue]	Conditions: entity=profile or sys_id in the list of controls active=true In addition, the issues should not have any exception policy. Exception policy can be checked in the [sn_compliance_policy_exception] table with two conditions: validity>now state=8	For all these issues, staging records are created in the [sn_oper_res_issue] table.
Incident: Step 1	incident	Conditions: cmdb_ci=profile.applies_to state IN [1,2]	For all these incidents, staging records are created in the [sn_oper_res_incident] table.
Incident: Step 2 (Optional)	[task_ci]	Conditions: ci_item=profile.applies_to task.sys_class_name=incident task.state IN [1,2]
Incident: Step 3	[task_cmdb_ci_service]	Conditions: cmdb_ci_service=profile.applies_to task.sys_class_name=incident task.state IN [1,2]
Change request: Step 1	[change_request]	Conditions: cmdb_ci=profile.applies_to active=true	For all these change requests, staging records are created in the [sn_oper_res_change_request] table.
Change request: Step 2 (Optional)	[task_ci]	Conditions: ci_item=profile.applies_to task.sys_class_name=change_request task.active=true
Change request: Step 3	[task_cmdb_ci_service]	Conditions: cmdb_ci_service=profile.applies_to task.sys_class_name=change_request task.state IN [1,2]
Outage	[cmdb_outage_ci_mtom] (cmdb_ci ←→ cmdb_ci_outage) [cmdb_ci_outage] (cmdb_ci) For each record in [cmdb_ci_outage], one record is created in the [cmdb_ci_outage_ci_mtom] table. In [cmdb_ci_outage], for each affected CIs, a record is inserted in the [cmdb_ci_outage_ci_mtom] table.	Conditions: ci_item=profile.applies_to outage.type IN [degradation, outage] outage.end IS empty OR outage.end > now	For all these outages, staging records are created in the [sn_oper_res_outage] table.
Task	[task]	Conditions: cmdb_ci=profile.applies_to active=true sys_class_name IN <list of classes fetched from property sn_oper_res.allowed_task_tables As part of base system, it considers only problem records.	For all these tasks, staging records are created in the [sn_oper_res_task] table.
Operational vulnerabilities: Step 1 (optional)	[sn_grc_case_mgmt_related_area]	Conditions: related_area=profile OR related_area=profile.applies_to core_case.sys_class_name=sn_oper_res_vulnerability core_case.active=true	For all these vulnerabilities, staging records are created in the [sn_oper_res_vulnerability_profile] table.
Operational vulnerabilities: Step 2 (optional)	[sn_grc_case_mgmt_impacted_area]	Conditions: impacted_area=profile OR impacted_area=profile.applies_to core_case.sys_class_name=sn_oper_res_vulnerability core_case.active=true
Third party risk assessments	[sn_vdr_risk_asmt_assessment]	Conditions: applies_to IN [core_company, sn_vdr_risk_asmt_vendor_engagement] state IN [5, 8, 9] risk_rating_valid_to > now risk_rating = highestRiskRating vendor = profile.applies_to (Note: This condition is different than the applies_to field in the [sn_vdr_risk_asmt_assessment] table.) engagement = profile.applies_to (Note: This condition is different than the applies_to field in the [sn_vdr_risk_asmt_assessment] table.)	For all these assessments, staging records are created in the [sn_oper_res_tprm] table.

Note:

You can calculate red flags for entities with a pillar; for vulnerable items, the pillar must be Technology. For other red flags, entities must have a pillar, with no restrictions on the type.

Sample query conditions for Operational Resilience integration

The Operational Resilience application uses entities to integrate with Risk Management, Advanced Risk, and Policy and Compliance Management. Operational Resilience uses the applies_to value of an entity to integrate with other tables. To illustrate how these integrations work, the following table provides examples of query conditions for various integration types, demonstrating the role of Entity and applies_to in facilitating these connections.

Table 2. Sample conditions

Table	Condition	Function	Integrated Application
task_ci	task.sys_class_name=incident task.state IN New, In progress ci_item = Applies_to	_createIncidentAndChangeRequestsWithImpactedAndAffectedCis	Incident
task_ci	task.sys_class_name=change_request task.active=true ci_item = Applies_to	_createIncidentAndChangeRequestsWithImpactedAndAffectedCis	Change request
task_cmdb_ci_service	task.sys_class_name=incident cmdb_ci_service= Applies_to	_createIncidentWithCriticalService	Incident
task_cmdb_ci_service	task.sys_class_name=change_request cmdb_ci_service= Applies_to	_createIncidentWithCriticalService	Change request
cmdb_outage_ci_mtom	ci_item = Applies_to outage.type = degradation or outage outage.end is empty or after	_createOpresOutageWithAffectedCis	Outage
sn_grc_case_mgmt_impacted_area	Impacted_area=Entity or Applies_to Core_case.sys_class_name = sn_oper_res_vulnerability Core_case.active=true	_createOpresVulProfileForImpactedAreas	Operational Vulnerability
sn_grc_case_mgmt_related_area	Related_area=Entity or Applies_to Core_case.sys_class_name = sn_oper_res_vulnerability Core_case.active=true	_createOpresVulProfileForRelatedAreas	Operational Vulnerability
sn_grc_m2m_issue_to_entity	Issue’s active = true Entity = Entity	_createServiceWithOpenIssue	Issue
sn_grc_issue	Issue’s active = true Entity = Entity	_createServiceWithOpenIssue	Issue
	Cmdb_ci = Applies_to Active=true Sys_class_name IN property 'sn_oper_res.allowed_task_tables'
Task			Task
Sn_risk_risk	Profile= Entity State=monitor Residual_score=highest_residual_score Content is NOT Empty Active=true	__serviceWithHighRisk	Risk
sn_risk_advanced_risk_assessment_instance	entity_1= Entity status=completed summary_residual_risk_score=highest rating	_advancedServiceWithHighRisk	Advanced risk
sn_compliance_m2m_control_entity	Control.Status=non_compliant Control.Exempt=false Control.State=monitor Control.active=true Profile= Entity	_createServiceWithFailedControl	Policy and compliance
sn_compliance_control	Status=non_compliant Exempt=false State=monitor Profile= Entity	createServiceWithFailedControl	Policy and compliance
sn_bcp_plan_asset	#1 Item=Applies_to Types ‘contains’ 'primary_scope' Plan.expires after Plan.state=approved	_createServiceWithBCMPlan Otherwise, mark the Applies_to as “No plan”	Business continuity management
sn_recovery_activated_plan	#2 Active=false Plan=one from #1	Otherwise, mark the Applies_to as “No exercise”
sn_recovery_event_asset	#3 asset_name= Applies_to event=one from #2	If event asset’s state is ‘not recovered’, mark the Applies_to as “No recovered”. Otherwise, mark the Applies_to as “Recovered”
sn_vul_vulnerable_item	risk_rating=Critical or high state NOT IN ‘closed, resolved, deferred’ Joined Query with Profile Profile.pillar contains technology Profile.active=true	_computeVulnerabilityEntities	Vulnerability response
sn_oper_res_tprm	applies_toIN’vendor, engagement’ stateIN’submitted,response received,follow-up’ risk_rating_valid_to after risk_rating = highest rating vendor= Applies_to or engagement= Applies_to	_createServiceWithThirdPartyRiskAsmt	Third-party risk assessment