Creating Your Company's GRC Taxonomy (or Everyone's GRC Configuration Challenge)

Kim walgren · ‎03-25-2019

I have questions related to defining the best configuration for Profiles types, etc. I believe I understand the basic concepts (create Profile types, define Profile filters, associate Policy statements, controls generate, etc. )

What is challenging is the up front work on defining the configuration to implement for this framework. It seems like there are common threads everywhere on this topic but I have not seen where anyone has actually shared their defined approach. As I am sure everyone else hopes, whatever we lay out for our company we want it to be a solid approach.

Does it make sense to set up Profile types around Locations and Departments when these can (and do) change (often - usually as a result of a reorg of some kind)? Does it make more sense to map Profile types around requirement groupings (provisioning, scanning, vendor mgt, etc)? While controls in these areas may come and go, they stay rather static? It is entirely possible I am not understanding the concepts very well.

I was a little surprised there is not more in this community about this important configuration work up front, before even starting setting up profiles. Everyone is creating a very similar wheel! I have seen comments that this why there are consultants and I would sure welcome a good one! However, since I lack one, my ask is simply: How did you approach defining your framework? I would love to hear from those of you who have used the GRC application for awhile now and could benefit from knowing what you did right and what you might do differently. Thanks in advance for your valuable input!

Jan Spurlin · ‎04-02-2019

Hi Kim,

I teach the Risk and Compliance Implementation course and Profiles are an entire chapter/module in that course. We talk about different ways that you might approach setting up Profile Types. How should you define them. Here are some of the questions/thoughts we discuss:

Profile Types are comprised of Profiles. Each Profile has a Profile Owner. That Profile Owners will become the Control Owner or the Risk Owner when a Profile Type is applies to a Policy Statement (for Control generation) or a Risk Statement (for Registered Risks).
Understanding how Profiles are used in the GRC application leads you to how to set them up.
I suggest asking the customer - who should be the risk owners or control owners? The answers may be specific people or you may get an answer like "all the application owners". Whatever the answer is, use that information to figure out how to build the Profile Type.
Another method is to ask - how do you manage controls and risks in your current environment? Again, looking for who is doing what and then translating that information into a ServiceNow table.
I have also heard someone suggest that you ask "how do you scope an audit?" "Who do you determine what to include in an audit?" Ex: All the critical SAP Applications or all the critical financial applications, etc. Remembering that in ServiceNow, the way we build an Audit engagement is to identify individual profiles (not Profile Types).

Depending on the maturity of a customer's CMDB you may have to create a new table to use to build profiles. But it is better if you can pull from an existing table - one that is already being maintained because of another non-GRC process.

And don't forget that when building the filter for a Profile Type you can pull from multiple tables. The filters (I think this started in Kingston) are now held in a m2m table. So, I could pull data from the Location table AND the Department table if I needed both to complete a Profile Type.

And don't forget - you can Profile Types like these - where a profile is in more than one Profile Type.

All locations
All warehouse locations
All distribution locations
All applications
All critical applications
All financial applications
All servers
All PCI servers

One other thing to consider is primarily doing this for Policy Compliance - look at the Authority Doc (COBIT, SOX, etc) and try and figure out who within an organization they want to be addressing compliance with their requirements.

Hope this helps.

View solution in original post

randytangco · ‎03-26-2019

Have you seen any process guide for GRC?

Kim walgren · ‎03-26-2019

Hey randytangco,

If you mean have I seen the documentation provided by SN, such as the London Governance, Risk, and Compliance guide last update: February 13, 2019, then the answer is yes.

If you are talking about generic process guides, the answer is yes. What I was hope to get from other users is what approach(es) were used to build the control framework - what worked well. I am not worried about the mapping part, I am wanting to establish the right strategy to build out in the GRC module.

kerrygregory · ‎08-06-2019

Kim, Great questions! where did you find a generic process guide on GRC?

G Balaji · ‎03-26-2019

Important points to be highlighted,

The whole GRC module revolves around Profiles.

SNOW recommends that profile gets created from Profile Type.

Profile is an entity for which Governance, Risk and Compliance is implemented.

Define profile class to categorize profiles.

A profile could also be tagged to multiple profile types.

In terms of practice you could consider following approach,

1. Identify policies that your organization is expected to meet in terms of business contracts with your clients, regulatory commitments etc.

2. Generate policy statements from policies or download from UCF.

3. Identify the profile types to create profiles(SNOW recommended approach) based on the scope of GRC. Or you could profiles and then associate with profile types

4. Assocated policy statements and profile types through m2m relation.

5. If a profile is expected to implement multiple policies, associate it with relevant profile types.

6. Controls gets created automatically once profile is tagged to profile type. These controls attributes are defined to gauge the compliance in an organized manner.

7. Identify risks from the compliance.

8. Manage risks through risk module and ITSM.

9. Perform audit in regular intervals to assess compliance and risks.

Let us know if you look out for detailed information on any of the above.