Reducing Customizations in GRC Risk Assessments (CIA & CMDB Integration)

[thomasanton]

Hello GRC Experts,

Our team is looking to streamline and reduce customizations within our ServiceNow GRC Risk Assessment process, specifically concerning the use of Confidentiality, Integrity, and Availability (CIA) classifications.

Currently, we utilize CIA directly on the risk assessment form. However, the tables backing these CIA fields are custom and unfortunately, are no longer being actively maintained. This is leading to data integrity issues and making our risk assessments less reliable.

We're exploring two primary approaches to address this and would greatly appreciate your insights on which method would be the least customized and most sustainable for maintenance:

Option 1: Continue using CIA on the Risk Assessment Form with Mapping to CMDB

• This approach would involve keeping the CIA fields on the risk assessment form as they are, but instead of using our unmaintained custom tables, we would map these CIA values to relevant, maintained CMDB tables (e.g., CI attributes, classification fields).
• Questions for the forum:
  • What are the best practices for mapping risk assessment fields (like CIA) to CMDB data? Are there out-of-the-box mechanisms or recommended patterns for this in ServiceNow GRC?
  • Are there any performance implications or architectural considerations we should be aware of when establishing such mappings, especially if they involve lookups to large CMDB datasets?
  • How would this impact reporting and dashboards for risk assessments? Would we be able to easily report on CIA values derived from CMDB?

Option 2: Tie CIA to Entities with Maintained CMDB Tables

• In this scenario, we would move away from having CIA directly on the risk assessment form. Instead, the CIA classification would be associated with the entities being assessed (e.g., applications, services, infrastructure) within ServiceNow, leveraging attributes or relationships within their maintained CMDB records. The risk assessment would then inherit or reference this CIA information from the associated entity.
• Questions for the forum:
  • Is it a common and recommended practice to manage CIA classifications primarily within the CMDB for entities, rather than on the risk assessment itself? What are the pros and cons of this approach from a GRC perspective?
  • How would risk assessments then leverage this CIA information from the entity? Are there standard ways to pull this data into the risk assessment context (e.g., through related lists, dot-walking, or GRC profiles)?
  • What are the implications for user experience when conducting risk assessments if CIA is not directly on the form? How can we ensure assessors still have visibility into the relevant CIA information?
  • Are there any specific GRC modules or features (e.g., GRC Profiles, Advanced Risk, etc.) that lend themselves better to this type of CMDB-centric CIA management?

General Questions for both options:

• From your experience, which of these two approaches (or perhaps a third, better alternative) typically results in the least amount of customization in the long run within ServiceNow GRC?
• Which method generally offers the best maintainability and reduces technical debt?
• Are there any significant pitfalls or challenges we should anticipate with either approach from an upgrade, performance, or data governance standpoint?
• Are there any out-of-the-box ServiceNow GRC features or modules that are particularly well-suited to managing CIA in an integrated and low-customization manner with the CMDB?

We are aiming for a solution that is robust, scalable, and adheres as closely as possible to ServiceNow best practices. Any guidance, examples, or experiences you can share would be incredibly valuable.

Thank you in advance for your time and expertise!

Best regards,

Thomas