Audit Management in ServiceNow

[Saiganeshraja]

Audit Management is an application in GRC. It leverages data from the GRC Suite to complete audit life cycle.

The Objectives of audit management are to ensure that:

1. Risks are properly identified and quantified

2. Controls are designed in a way that effectively reduce the identified risks

3.Controls are properly monitored for the operating effectiveness.

4.Control deficiencies are identified and remediated.

Audit Management states:

Scope:

Scoping an engagement is when the audit team will define each component of the business that they are responsible for reviewing. In other words, scoping will drive what testing the audit team will perform as part of the fieldwork.

Validate:

During this phase, the system automatically populates risk register items and controls that have been pre-mapped to those entities. Members of the audit team are expected to demonstrate a holistic understanding of the organization and the risk it faces. The different risks and controls that get populated give the audit team one-click access to view management’s evaluations of risk and controls. Once the scope has been reviewed, along with all of the different things associated with it, the audit team can begin performing and completing the engagement by moving it to the Fieldwork stage.

Field Work:

Auditors complete their assigned audit tasks during the Fieldwork state. These tasks include control testing, interviews, walkthroughs, and other activities. Issues that are found during control testing are associated with the engagement. Auditors can also create general issues associated with the engagement. Audit managers can create additional audit tasks as needed. When the audit is done, audit managers specify the result of the engagement, whether it's satisfactory, adequate or inadequate, and provide details on their opinion.

Awaiting Approval:

During the Awaiting Approval stage, the approvers specified in the engagement's Approvers field review the results of the audit tasks conducted and the issues that were created. After reviewing the results of the engagements, they can either approve or reject the engagement.

Follow Up:

Once an engagement has been approved, if there are any remaining open tasks or issues associated with the engagement, the engagement automatically goes into the Follow Up  stage. During this stage, auditors must close out all remaining issues and tasks before the engagement can be considered to be completed. Audit managers can generate audit report that summarizes the findings of an engagement so report findings can be communicated to executives.

Closed:

Engagements move into the Closed state under one of three conditions:

1. The engagement is closed as incomplete during the Scope, Validate, or Fieldwork stages.
2. There are no open audit tasks or issues after the engagement is approved. In this case, the engagement automatically moves from the Awaiting Approval stage to the Closed stage.
3. All of the follow up issues and tasks are closed out. In this case, the engagement automatically moves from the Follow Up state to the Closed stage.

State Value	Available Actions from State	State Activity
Scope	[Validate] [Close Incomplete] [Delete]	Set parameters of the engagement Add entities Set the report template and KB article template
Validate	[Advance to Fieldwork] [Close Incomplete] [Delete]	Review engagement details Generate Control Tests and assign Create other applicable audit tasks and assign
Fieldwork	[Close Incomplete] [Request Approval] [Delete]	Completion of audit tasks by auditors Engagement results determination by the audit manager (engagement assigned to user)
Awaiting Approval	[Delete]	Review of audit results and approval/rejection determination by audit approver(s)
Follow Up	[Generate Report] [Delete]	Generate preliminary audit report Resolve audit issues (findings/observations)
Closed	[Generate Report] [Delete]	Generate final audit report

Audit Tables:

Table	Description
Activity [sn_audit_activity]	Extends Audit Task [sn_audit_task] and stores audit activities
Audit Task [sn_audit_task]	Extends Planned Task [planned_task] and is a generic table for all tasks associated with an audit
Base Audit Test [sn_audit_base_test]	Base table for Test Templates and Test Plans
Control Test [sn_audit_control_test]	Extends Audit Task [sn_audit_task] and stores control tests
Control to Engagement [sn_audit_m2m_control_engagement]	Stores many-to-many relationships between controls and engagements
Engagement [sn_audit_engagement]	Extends Planned Task [planned_task] and stores engagements
Interview [sn_audit_interview]	Extends Audit Task [sn_audit_task] and stores interviews
Entity to Engagement [sn_audit_m2m_profile_engagement]	Stores many-to-many relationships between entities and engagements
Risk to Engagement [sn_audit_m2m_risk_engagement]	Stores many-to-many relationships between risks and engagements
Test Plan [sn_audit_test_plan]	Extends Base Audit Test [sn_audit_base_test] and stores test plans
Test plan to Engagement [sn_audit_m2m_test_plan_engagement]	Stores many-to-many relationships between test plans and engagements
Test Template [sn_audit_test_template]	Extends Base Audit Test [sn_audit_base_test] and stores test templates
Walkthrough [sn_audit_walkthrough]	Extends Audit Task [sn_audit_task] and stores walkthroughs
Audit Report Template [sn_audit_report_template]	Stores the defined xml, html or script-based audit report templates

[Kimberly Wetten]

Do you know if you can add CONTROLS from the library to an ENGAGEMENT in Fieldwork or Validate State ?  Our usecase is that its possible that additional controls need to be evaluated that weren't previously mapped to the entity....

[Lottet13]

@Saiganeshraja   I am an analyst who supports our IT Audit team. The GRC module in SN is new to us so we're still learning. The organization is immature in this space so the auditors are needing to redo their Design/Operation tests in the audit control test records as they work through their engagements.  

One of the questions I had from an auditor is why the fields are locked down in an audit control test when in the Open phase. What is the thinking behind the audit process by the time the engagement is at this point? And is there a way they can make changes to the Design/Operation test fields (Design expectations & Design assessment procedures and Operational expectations & Operational assessment procedures respectively) so they stay unlocked until the Review state?

[Sebastien Fix]

@Lottet13  The Control Test tasks you see during an Engagement have been previously defined in the Test Template records linked to the Control Objectives. OOTB the idea is that the Auditors just HAVE to follow the testing protocol defined by the SME alongside the COs.

so the Control Test Task is Open during Fieldwork, but it means Open for the Auditor to performed the testing as pre-defined. Not Open as in "Open to change the content".

Hope this helped a bit

[jjcontessa]

@Saiganeshraja, I hope you can help me understand how we can control the indicator results brought into the audit engagement during the scoping phase. Before either the San Diego or Tokyo releases, explicit fields enabled the engagement manager to define the audit period (for example, if we were performing the audit for Q1 of 2022, the audit period would be 1/1/2022 to 3/31/2022). On the new engagement form, we do not see these fields. Can you please clarify where we set the parameter for the indicator results to be pulled in based on the scope in the engagement form? Thank you! 

[Lottet13]

@Sebastien Fix 
In an engagement, when a Control Test fails, an Control Test Issue is generated. The issue name is the same name as the entity instead of the Control Test name. Why is that? (We can override the issue name but curious as to why the issue name is set up to reflect the entity vs. the control test.)