Data Hierarchy in GRC

[dmac]

Hello,

              We are in the process of using the GRC Tool for the IT Audit within our Company. Unlike the structure of the service now table with Authority Documents > Citations > Policy > Policy Statement etc. Our audit team does not manage the data in such hierarchy. They currently have the Business Process, Risks and Controls.   I would like to know where the Business Process can be fitted within the hierarchy. I am assuming that Policy and Policy Statements would be the right place. Can any one help me on this ?

Hello vineethnair,

First let me clear up the hierarchy, Authoritative document to citation to policy statement.   Think of a policy statement as a control template.   When you import controls from UCF they are imported as policy statements.   You relate a policy statement to a policy and then a policy to its scope of entities that have to adhere.   The scopes, are profile types (or scope definitions).   The profile types generate in scope entities (or profiles).   Then each profile is then assigned a series of its own specific controls based upon the policy statements associated.   Later when you initiate an audit, you select the profiles that are in scope.   You automatically inherent a risk library and control library based on what's related to each profile.   From there initiate control tests based on the test plans for each control.   I've attached a diagram I created to help describe the #Helsinki #GRC #architecture.

In your question above, I assume the business processes would relate to a series of profiles.   The profiles are the parent to risks and controls.   Hope that helps.

You can start building hierarchy with profile types and profiles for resp. Business processes. Then go further with related policies and statements.

Manoj Patel, Risk & Security Practice EMEA ServiceNow

Sent from my iPhone

To complete previous responses, I can tell you that I built a similar example for a client, building a Profile Type based on the table "cmdb_ci_business_process". I populated this table with some examples of simple business processes (Order to Cash, Design to deliver, ....). Those processes being the Profiles on which I could generate my Controls and Risks, based on associated Policy & Risk Statements.

It works well and delivered a nice use case.

Eric

Thanks to three of you   in helping me clear my understanding. Our audit team is adamant that they do not want to import\manage the authorative document\citations for SOX Audit within Service Now.

They want the tool to just manage the Policy, Policy Statement, Control and Risks. At the same time, use the tool to manage the entire audit process. Have you ever seen any company not use Authorative Document and Citations within ServiceNow ?

Hi Vineet,

Actually, many customers do not use the UCF Authority Documents data.

-                   Either because they started the implementation before it was available (Before Fuji)

-                   Either because they have their own system of controls that they want to keep. They may loosely connect it to Authority Documents (or not), but their main stream is Policy to Policy statements to Controls and Indicators

You certainly can feed your Audit process in ServiceNow GRC only from Controls, Test Plans, risks , Indicator results, only based on internal Policies and not on Authority documents.

Best Regards

Eric

This document was generated from the following discussion: Data Hierarchy in GRC