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

[Kim walgren]

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!

[Kim walgren]

Hi Shiva,

Thanks for the response!  What I am curious about is the number of profiles being created for your Profile Types?    Will you be managing profiles per asset in your environment?   We are struggling to understand how this is manageable?

Are you managing at a higher level for reporting purposes and sacrificing individual asset granularity? 

Any input is appreciated!

[Shiva Thomas]

Hi Kim,

As for now, we are focussing on risk reporting.
We have about 150 profiles for in scope Legal Entities, and will have at least the same amount of profiles for Departments.

We defined several profile types, focussed on business sectors, for both LE and Departments, as business sectors have different Risks and Controls.
Each Risks and Controls are assessed annually. There may be up to 50 Risks and up to 200 Controls per profile, depending of business sectors.

In our case, each Control is one simple question that will be answered by the local Owner. I implemented a one-click assessment interface for Controls, that is much faster to use than Assessment questionnaires, and dashboards that highlight to owners what is needed to be acted on. Each risk is linked to several controls (=questions) and depending of the one-click assessment results (=answers) the risk score is automatically updated.

Also Controls can never be assessed by the Risk's Owner, to enforce separation of duty.

∴
Best regards from Switzerland
Shiva :¬,

If this reply assisted you, please consider marking it 👍Helpful.
This enables other customers to learn from this thread.

[Jan Spurlin · Accepted solution]

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. 

[Eric Feron]

Thank you for this Jan!

[Kim walgren]

HI Jan,

Thank you for your response and entering into this discussion! 

I just responded to Eric with this information - I work in GRC for the IT arm of a large health care organization.  We did play around in a test environment with creating a Profile Type (server), and creating profiles (Company, Business Unit, Functional Area, and Department), and associated one control. What we are struggling with is the granularity of profiles needed.  In our organization we will have hundreds of thousands of assets (applications and infrastructure). 

Two things we noticed in some testing we did:

1) When we filtered to a specific subset of servers it seems there is a profile being created for each one (in excess of 10,000).  Is this correct?  Each device profile must have an owner assigned?  It seems we can report at a higher level but would loose the device granularity.  We are wondering if this is what large organizations do in order to make this environment manageable?

2) Take this example of using the exception module to track when a device is noncompliant:

We have 20 DB servers and all were compliant but one device for the same control.  Is this control now marked as non-compliant because of one device being non-compliant?  We would like to do an exception for this one device - how does this affect the compliant/non-compliant status of the control?

Your thoughts would be appreciated!