Is there any chance that GRC was installed prior to the Istanbul Version? There were major architectural changes that were made in that require a migration. There is even docs on how to migrate - here is a link to those:
I think I agree with you on the filter that was built - that looks like an infinite loop. I do not understand why it would have been built that way.
What I would do is to first inactivate those four Profile Types. Do that by deleting the Profile Filter on each of those Profile Types. If you don't do that, then when you do what I am going to tell you next - I think it will just start regenerating the profiles.
Next you want to go to the All Profiles modules and delete (yes, hard delete all the profiles). I would do this in small batches - because there is a lot of processing that is going to happen when you do this. I just deleted 3 profiles from my test system from the list view - and I got this pop-up message:
So, what it is going to do is go and retire these 7 risks and 12 controls. That is what will happen on your system.
Best Practice for Profile Types is a long conversation. It varies by customer and what you are trying to do. Maybe of the holidays I will write an article on how to select what you will use for Profile Types and why. In general, the Profile Type should represent the groups/people that will be managing/owning the controls and risks. That could be based on departments, or locations or servers or applications, etc. Lots of choices.
Is there any chance that GRC was installed prior to the Istanbul Version? There were major architectural changes that were made in that require a migration. There is even docs on how to migrate - here is a link to those:
I think I agree with you on the filter that was built - that looks like an infinite loop. I do not understand why it would have been built that way.
What I would do is to first inactivate those four Profile Types. Do that by deleting the Profile Filter on each of those Profile Types. If you don't do that, then when you do what I am going to tell you next - I think it will just start regenerating the profiles.
Next you want to go to the All Profiles modules and delete (yes, hard delete all the profiles). I would do this in small batches - because there is a lot of processing that is going to happen when you do this. I just deleted 3 profiles from my test system from the list view - and I got this pop-up message:
So, what it is going to do is go and retire these 7 risks and 12 controls. That is what will happen on your system.
Best Practice for Profile Types is a long conversation. It varies by customer and what you are trying to do. Maybe of the holidays I will write an article on how to select what you will use for Profile Types and why. In general, the Profile Type should represent the groups/people that will be managing/owning the controls and risks. That could be based on departments, or locations or servers or applications, etc. Lots of choices.
Jan,
Thank you so much for the additional information. I verified and our Production instance does not use the legacy GRC plugin. I believe the legacy GRC plugin ID is (com.snc.governance). Here is what we have for active Plugins.
The Steps for inactivating the Profile Types and cleaning up the data were exactly what I need. I can now see where you were going with the question on retiring Controls and Risks. The short answer is, Yes we plan on retiring all of the Controls and Risks currently in our Production instance.
As you can probably figure out from our infinite loop scenario, we have several thousand Controls that will be retired.
I have a much better understanding of what tables can be used to build the profiles. Also took a look at some of the Profile Types created within ServiceNow demo data. So if we develop Policy Statements around information security, then I believe including profile types that are related to CMDB Data Centers, Servers, etc would be a good Profile Type.
So if I understand this correctly, the goal should be to line up Profile Types with Groups, System Owners, Systems, etc that could be included in an audit plan. By using GRC, we can confirm these Profile Types meet requirements defined in our Policy Statements and the Controls defined for our organization are effective. Let me know if I missed something here.
Thanks again,
JB
