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

Gen Fields · ‎03-26-2019

Excellent question! Interested to see the responses. Thanks for posting Kim.

Eric Feron · ‎03-28-2019

Hello again Kim,

what industry vertical is your company operating in? This is important to give you the right guidance.

Thanks,

E

Kim walgren · ‎04-03-2019

Hi Eric - thank you for your response. I work within the IT arm of a very large health care organization with 200,000 employees. As a result, we have hundreds of thousands of assets (applications and infrastructure).

We are trying to figure out how to build our Profile structure to accommodate the level of granularity we need for reporting. We experimented with a Profile Type of Server with classes of Company, Business Unit, Functional Area, and Department ( these rollup into each other). We associated one policy with the Profile type.

It appears the system wants to create a profile per device for the control, resulting in excess of 10,000+ for a filtered OS selection.

This seems unmanageable when you do the math and extrapolate out the controls and number of assets. Is there something we are missing? WE are assuming there are other large organizations using SN who have faced this challenge.

Thoughts? Thank you in advance for participating in this discussion.

Shiva Thomas · ‎03-29-2019

Hi Kim,

I'm implementing high level GRC Risk Management for a very large Pharma group. In this case, we focussed only on Legal Entities and Departments.

Best regards,
Shiva

Kim walgren · ‎04-01-2019

Hi Shiva - thx for your input. We are hoping to start with a subset as well. WE are still struggling with the right structure to adopt. There are a lot of moving parts here!