Pros and Cons of mapping all of my compliance policy controls to every entity through GRC

Shirl22
Tera Contributor

Hi, 

 

My organization has about 17 agency customers, and each agency customer has a varying number of business applications (1300 total applications across the enterprise), all of which are expected to comply with my organizations 18 information security policies; the 18 information security policies contain controls/safeguards that total about 600 control objectives. 

 

We have loaded the authority documents and done all the citations and control objective mapping.

 

We have about 400 open audit or risk assessment findings against some of the 1300 business applications.

 

We need to complete entity scoping and map controls to the entities (1300 business applications). We plan to complete the entity scoping/entity types by agency (e.g., Business Applications: agency, Business Applications: agency, etc., one entity type per agency).

 

I'd like to know pros and cons and recommendations around whether we should go ahead and map all 600 control objectives to each of the 1300 entities/business applications since each business application is required to comply with them versus pros/cons/recommendations about whether it's better to map fewer controls to each business application/entity and then map additional controls as needed. 

 

Seems like we could save some work by mapping all the control objectives to all business applications/entities upfront. 

 

Looking forward to hearing from the experts. 

 

Thank you.

Shirl

5 REPLIES 5

Community Alums
Not applicable

Hi @Shirl22 ,

In a very laymen language if you want the entities being complaint , you need to have the controls in place for that you need to relate the entities to the controls. This would result of the entity is compliant or not.

 

Now, it’s on you which all entities you want to check the compliance.

 

Jan Spurlin
ServiceNow Employee
ServiceNow Employee

In typical fashion, the answer is that it depends...  Here are a few things to think about:

 

If you look at your 600 Control Objectives, does compliance really vary across all 1300 applications? Do you have automated indicators in place if you were to scope the Control Objectives with 1300 apps? Could the control owners only be dealing with the exceptions versus having to do the admin work of saying that they are compliant with the control?

 

I'm not sure where the 17 agencies come into this scenario. Do they use different apps - or is the same app used by multiple agencies? If it is the same app, are the security requirements really managed by each agency?

 

If you wanted to start out slow, could you group the 1300 applications into groups - like Financial customer-facing apps, Financial internal apps, End-user apps, etc - and then generate controls on those?

 

Have you looked at the new feature of common controls that was released at the beginning of February? Would that help you? Do you have a control objective - for instance single sign-on - that really is managed by a single app, like OKTA but many other apps are dependent on that function?

 

Hope this helps.

Hi Jan, 

 

Your response helps some, yes. The agencies each own some of the 1300 total applications. For example, one agency may one 97 of the applications while another may own 120 of the 1300. We want to track compliance by agency. 

 

Haven't looked at the common controls feature. I'll look into that. 

 

I don't think we want to group based on things like financial apps, end user apps, etc., but we may use Entity classes for that eventually. 

 

We don't have indicators in place yet either. I'm thinking all the apps must comply with all 600 control objectives (the control objectives do apply to every app), so even though we may not assess compliance of all controls for all apps initially, doesn't it make sense and save extra steps in the long run, if we were to scope all controls to all apps so that the controls are in place and we can assess compliance against any of them as/when needed? 

 

Another question would be what are reasons why it might be better to create entity types only for applications and associated controls for which we currently have open audit or risk assessment findings? (i.e., not create entity types for all 1300 entities and not map all controls to each entity)

 

Thank you and anyone else who responds for your expertise.

I posted a reply but it appears the reply did not go through. Thank you for your response, Jan. It is helpful. 

 

I do have a couple more questions. 

 

First, to answer your question about the agencies: each agencies owns some of the 1300 total # of applications and is responsible for the compliance to the controls. 

 

We need to track application compliance by agency. 

 

1. What would be reasons not to complete entity scoping for all 1300 applications based on entity types of Business applications: agency1, Business applications: agency 2, etc. and map all 600 controls to each application? 

2. If we plan to map all controls to every business application, would we even need separate entity types by agency? I'm thinking probably not. 

3. What are reasons why it might be a better idea to create entity types only for the entities against which we currently have open audit and/or risk assessment findings (the number may be closer to 300 applications rather than the 1300 total in the enterprise) -- and then either map only the controls against which there are current non-compliance findings -- or go ahead and map all 600 controls to just those approximately 300 applications? 

 

Thank you for your continuing assistance.