All Open Ideas for GRC/IRM (October 2020)
I was just going through Idea portal, and its difficult to see everything in one place. Please find a current list of open ideas. Things which are planned not included. Sorry if I missed any...
Not sure if this article should be maintained or new one posted regularly (Top 5/10?). If you have raised a new idea on the Idea Portal, please comment with the link and brief description.
Review the idea and comment/vote
Capability to perform a target risk assessment
Exception Approval and Verification Rules Dependent on Fields
The current Exception Approval Rules has conditions to permit some approvals based on control objective, risk rating, etc. They are statically defined. However, there are instances where one or more approvals are dependent on the referential data, such as the requester's department, the requester's manager, etc. Those cannot be defined from the approval rules today. Adding the ability to define an approval based on a name in a certain field on the view/form will allow more customization and easier self-administration. This concept should also apply to 'Verification Rules' too.
Extend existing Dependency Views (app.ngbsm) to be able to generate a dependency between:
- risks, issue and remediation tasks.
- authority document, control objectives, policies, controls, etc.
At this moment, Next Generation Business Service Management Map is restricted to cmdb_ci field and therefore we cant customize to provide any relationship within the GRC world.
Active flag on sn_grc_choice table
This table is used across various areas of GRC , and it would be great to be able to deactivate options - rather than having to delete.
This would require a new true/false field: active , as per standard table structure (e.g. task)
And update to all standard reference qualifiers e.g. type, classification, category on sn_grc_content etc
VRM: Support for Multiple Vendor Engagement assessment
Key Capabilities Required: 1. Ability to structure vendors based on services or products they provide, engagements you have with them or different sites 2. Ability to have separate primary and secondary vendor contacts per engagements/services and flexibility to share these vendor contacts across various engagements/services 3. Ability to perform tiering assessments and come up with a risk tier per engagements/services/sites 4. Ability to perform risk assessments and come up with a risk rating per engagements/services/sites based on risk area 5. Ability to manage issues for each engagements/services/sites 6. Ability to review and approve/electronic sign-off engagements/services/sites 7. Ability to rollup risk tiers, risk ratings and issues at vendor level 8. Ability to report on risk tier, risk ratings across various vendors engagements/services and slice and dice based on risk areas Business Rationale: Customers need to review their Vendors in the context of the Services being provided or engagements they have. Different Services will lead to differing levels of questionnaire and/or additional checks or document requests. When a Vendor provides the same (or different) services from multiple sites within their organization there can be a requirement to assess each location as a standalone assessment and decide to Pass some while Failing others. Therefore, customers would want to monitor risk tiers or risk ratings at different services or engagements level rather than at vendor vendor.
Enhanced Security in GRC to ensure only authorized users are able to access the data
Key Capabilities Required: 1. Ensure only authorized users are able to access the data 2. Even users like GRC Admin/System admin should not be able to access the data Business Rationale: For most customers, GRC data is highly confidential. Some of the risks and audit information is sensitive and only restricted users should be able to the access the data. However, currently admins can impersonate to be other users and can access confidential information even though they should not be. This is a huge issue which needs to be fixed. Applications like HR and SIR already supports this capability and we should improve data security in GRC as well
Delegate Attestations and Risk Assessments
There are a lot of customers who want the ability to 'delegate' an attestation or risk assessment, if the assigned to person is not available OR in fact, if the control/risk owner wants to delegate the task but still remain the owner.
It is possible to change the user but this can cause a loss of traceability. Other approaches may result in unintended consequences by customising baseline settings.
Prevent/Fix Empty Numbers in GRC
Since GRC Scoped Apps were released in Helsinki, this bug has been present and still exists today.
I have created an article to explain, but please resolve in the core release:
We would like to have an additional option for the "collection_frequency" field on the snc_grc_indicator table. Currently, users have to set up multiple records to achieve a bi-weekly schedule (that is, every two weeks).
Key Capabilities Required: 1. Ability to inherit the control compliance status of upstream control based on the control compliance status of downstream control Business Rationale In actual business, a parent entity would be dependent on the corresponding child entities. Therefore even from a compliance perspective it may happen that the compliance status of the upstream control maybe dependent on the compliance status of the downstream controls. Therefore instead of defining additional assessments at parent control users should have a capability to inherit the results from the downstream controls which will help improve efficiency of the organization Example: Business Functions -- Tier1 Applications -- Tier2 Data Centres - Tier3 Suppliers - Tier4 NOTE: we require a T4 to be able to be linked directly to a T2 AND/OR T1 (i.e. bypass T3) Or record, for instance, a mitigating control on an IT System, which affects the compliance of an operation control on an OT System
Control always copy the data from Control Objective
Whenever we want to create controls that are linked to the control objective but have different details like separate names, descriptions for control, that is not possible.
The details are always copied over from Control Objective to Control. This should be the case whenever Controls are populated automatically. But if we would like to create controls with different from the details in Control objective it doesn't allow us to do so.
AS A Compliance Manager GIVEN THAT our GRC Profiles have been arranged in a M2M relationship representing Risk and Compliance inheritance AND I am looking at a dashboard, like Compliance Overview - PA Premium I WANT to be able to select a Profile and have reports display results for all profiles Downstream of the selected profile SO THAT I can view the real compliance impact on higher parts of the organization without customizing tables and reports. --- As an organization, we have 3 subsidiary companies each of which implements operational controls, based in part on guidance from the group level. The compliance of the overall group depends on the compliance of each subsidiary company. This same pattern repeats at lower levels of granularity, like Departments and Vendors. Currently, the Compliance Overivew - PA Premium dashboard allows for reports to be filtered by Profile and Control State using Interactive Filters. However, we are only able to select individual profiles, and not a whole hierarchy of profiles based on the Upstream/Downstream relationships we defined. When I look at a profile, I can see in related lists the Upstream and Downstream profiles. I want to be able to use this relationship in an interactive filter, to easily select a profile and filter to all downstream profiles.
Control Multi-Scope Compliance
AS A Compliance Manager, GIVEN THAT a single control is implemented by our organization, AND that control provides compliance for many distinct entities, I WANT to be able to apply the control and its compliance to multiple entities, SO THAT I can demonstrate the compliance of those individual entities, without creating multiple controls. Bad use case: For a financial services entity, i have a European level entity and subsidiary entities for each country. I want one control at the Europe entity that makes all my subsidiary country entities compliant. This is bad because I don't end up testing something like financial services licensing at each country level, and can falsify my compliance. Good use case: Consider a physical security control like Fire extinguisher class in datacenters or badge readers in a building. I may have multiple services hosted in a datacenter, or multiple departments in a building, each of which needs to show compliance to those physical security controls. In this case it really is just one control, but multiple entities are made compliant by that control.
Make the default short description of an issue configurable
The default short description when an issue is created through an attestation is currently '[name profile] has an assessment failure'.
This short description is not liked by stakeholders as it comes across as too negative. Therefore they would like to change it.
Changing the default description is currently only possible by changing the OOTB scripts or by creating additional business rules.
Can you make the default issue short description configurable?
Enable compliance data for customers via a customer reporting portal
As a vendor I would like to enhance compliance transparency and give my customers real time insight in my compliance status via a customer portal. E.g. Compliance test results re Identity Access Management are visible via a customer portal. The customer should see that the controls are compliant or not, what was tested and the results (for external reporting purposes).
Now we have to report the results via email and memo's.
If issues are reported, the customer should havehave real time insight in the follow up status and updates. This will optimize my reporting process to customers re updates on audits and enhance transparency. No memo's and limited emails and track and trace via GRC.
Tag users in comments on the Portal
We've a feature on the native view on journal fields like worknotes/comments to tag users using '@'.This feature isn't working on our portal for the same record.It would be really good for an application which requires constant communication on a record.
It is very unfortunate that we have this feature on the native view and not the portal
https://www.servicenow.com/community/grc-articles/all-open-ideas-for-grc-irm-october-2020/ta-p/2306707