Import/Create records in [sn_risk_risk] or [sn_grc_issue] table?

[Valqe]

Hi all,

I'm relatively new to the GRC space and would greatly appreciate your advice on the following matter:

Is there a scenario where records are created directly (or imported) into the [sn_risk_risk] table without following the 'per book' process, wherein you create an 'Entity Type' and associate it with an 'Entity' and 'Risk Statement'?

I'm asking because (new implementation) customer has provided us with an Excel list they refer to as the 'Existing risk ticket queue,' and they want to import it into ServiceNow. Personally, I feel it might be more appropriate to import these records into [sn_grc_isse] instead of considering them as risks and importing them into [sn_risk_risk]. I welcome your comments and further elaboration on this matter.

Sharing best pactices to importing existing records in [Risk] module when fresh IRM implementation is greatly appreciated 🙂

Many thanks,

Valqe.

[Rakesh Chigari]

@Valqe  Servicenow gives you both options, either create manual standalone risk (without risk statement) or using  automation by mapping entity type to risk statement. 

In some scenarios,  we do import risk records into sn_risk_risk if there is specific business use case

• If risk are managed in different tool and now you migrating to servicenow
• If risk are managed in excel currently and you want migrate this to servicenow

Servicenow recommends for auto generation of risk because of following advantages

• Easy generation of risk by mapping risk statement to entity tap, this configuration will help you to map control objective and generate controls to mitigate risk during risk remediation.
• Few data attributes from risk statement are auto copied from risk statement to risk
• Any change (few fields) in risk statement will but risk back to draft state for re assessment automatically
• If entity owner is mapped as risk owner, if entity owner is changed, risk owner will be auto updated (give sync with entity owner field is checked on risk form)

Now to you scenario, every org will have their own process to handle risks, some don't want to pollute risk register because of its high visibility at CXO level, so they evaluate observations/findings as an issue first and than convert only eligible candidate into risk and proceed with Risk process and keep monitoring them.

The 'Existing risk ticket queue,' you mentioned should be reviewed by risk management team and if they feel it is valid list and they need to be registered as risk, import them in sn_risk_risk table. try to explain them advantages of auto generation. bit of additional effort could save lot of time for future.

• Create entity type with entity filter to generate entities
• Create  and import risk statement (sn_risk_definition)  (they are just risk template, list can be built using risk itself)

If I could help you with your Query then, please hit the Thumb Icon and mark as Correct

[Community Alums · Accepted solution]

Hi @Valqe ,

Intresting Question!!

It's not advised to import directly to "sn_risk_risk" table as it's meant to be created automatically when you add the entity type to Risk Statements.

Now, as per your customer's requirement, i belive it's the risk's excel sheet which they want to track and remidiate. so import 'Existing risk ticket queue', to the "sn_grc_isse" table and follow the issue management lifecycle.

Issue lifecycle involves the below stages and it should be the right approach to track your requirement provided by your customer:

New: Default state of issue. So as soon as issue is created, it will be in New state and assigned to the control owner.

Analyze: In this state, the owner needs to analyze the issue and identify the root cause.

Respond: In this state, owner decides if he/she can remediate the issue or needs to accept the issue and create an exception. If owner select response as Remediate, the owner/his team responds/fixes the issue in this state and move it to review. If they select response as Accept, we provide user to create an exception. And until the exception is closed, we keep the issue in respond state. Once closed, owner should remediate the issue.

Review: In this state, as per my understanding, the compliance/Risk/Audit Manager reviews the response from the owner and decides if issue is fixed.

Closed: Compliance/Audit/Risk manager closes the issue, if he/she thinks issue has been resolved.

[Community Alums]

Hi @Valqe ,

[Valqe]

Thank you @Community Alums - I appreciate your comment.
From ongoing/future records on [sn_grc_issue] I know they get created when we have inditacor or attestation failure, but what if the team identifies new entry similar to their current 'Excel' record? Shall I create a record producer to generate records in [sn_grc_issue] table for future records?

I understand that ongoing risk monitoring will go through 'Entity Type' / 'Risk Statement' / Risk record process, just wondering how do I keep up with future identified risks and shall I try to store them in [sn_grc_issue] table, or for future records shall I try to go in 'Entity Type' -> 'Risk Statement' -> Risk direction?

Thank you for your comment