Audits - ZenGRC Best Practice
- Tristan Mohn (Deactivated)
- Victoria Buhler (Deactivated)
Table of Contents
Overview
ZenGRC provides a robust forum to effectively manage audits for your organization. This best practice guide will help ZenGRC administrators successfully up audits up so their assignees understand the role they play within an audit and so external auditors have easy access to the information they need.
For step-by-step instructions, please see links under Audit Documentation in the right panel.
Definitions
In ZenGRC, there are four unique objects for audits:
- Audits
- Requests
- Assessments
- Issues
Audits - A container object for audits run against controls. This object will contain metadata around the audit itself (i.e., title, period, managers, etc.). When creating an audit, any requests and assessments will be automatically mapped to the audit object. Additionally, Issues created from assessments will be mapped to the corresponding audit object.
Requests - Objects used to request evidence as part of an assessment. The request object is sent to the identified assignee, who can respond to the request and upload evidence. Additionally, all communication between the assessor and the assignee will be tracked. Request status is tracked in Audits.
Assessments - Objects used to assess the effectiveness of a control. Assessments are typically made after requested evidence has been submitted and based on that evidence. Assessments are made on the 1) Design and the 2) Operation of a control by selecting either “Effective” or “Ineffective." Typically, controls that receive an “Ineffective” rating in either category will have a corresponding issue created. The status of assessment objects is tracked in Audits.
The control design effectiveness validates whether or not the control that is being assessed can fulfill the organization’s objectives for related framework requirements.
- The control operating effectiveness validates whether or not the control that is being assessed is operating effectively by taking into account the design and the supporting evidence that was provided from the related (evidence) requests.
- More information on control effectiveness in Quick Tips for Assessments: Finishing the Assessment
Issues - Object used to track the remediation of an issue (finding) discovered during the assessment of a control. Information that this object should contain includes an owner, remediation plan, and due date. The status of Issue objects is tracked in Audits.
Preparation
This section offers suggestions to consider prior to creating an audit in ZenGRC.
- Complete control fields for automatic selection in the audit - There are several fields available on controls that can be easily re-used in an audit. For additional information on which fields to populate, please see Understanding Audit Workflow Roles.
- Create the import template - Although the requests template isn't imported until Step 3 of audit setup, it should be an immediate action item. Some suggestions specific to audit spreadsheets are as follows:
- Code column, use the period/name of audit and Data Request List (DRL) line number, which is easily identifiable for external auditors. Other terms used for a DRL are Provided by Client (PBC), and Information Request List (IRL). Example naming convention for requests:
- 2018-Q3 PCI audit - request 1
- 2018-Q3 PCI audit - request 2
- 2018-Q3 PCI audit - request 3
The external auditor recognizes what request matches their DRL line item through the export of evidence and downloadable reporting.
Note that Jira audits use a different import template that is found in Step 3 of Audits. See information for Jira Audits.
Add in additional fields to the template as needed - For example, if you'd like the request to be recurring, you would add in a Repeats column. See information for Setting Recurrence on Action Items.
Start dates for requests are when the emails begin sending to the assignees.
NOTE
For additional information on requests, templates and Jira, please see Step 3: Setting up Audit Requests.
- Code column, use the period/name of audit and Data Request List (DRL) line number, which is easily identifiable for external auditors. Other terms used for a DRL are Provided by Client (PBC), and Information Request List (IRL). Example naming convention for requests:
Creating the Audit
The following are tips for building an audit within your ZenGRC instance:
- Date range place holder - Note that the Audited period fields in the Audit wizard are not tied to any starting or stopping of the audit. Typically these fields are the parameters of the time period that is being targeted by the audit. Notifications are sent on the start date you assign in the requests template.
The following screenshot is from Step 1 of the audit wizard.
- Define time range for evidence collection
- Common time frames are 2-3 weeks determined by the complexity of your organization.
- Impress urgency for recipients.
- Provide guidance - After starting the audit, either link to a common shared drive or pre-populate the requests with evidence from a prior audit/period so assignees have examples to follow. While this may have extra admin/setup time, the benefit includes more accurate and complete evidence submitted.
- When working with external auditors, consider the following:
- Create the ZenGRC audit as an “External audit.”
- Set up the external auditor in a Contributor role. See Adding and Removing Users.
- In Step 1 of audit creation, assign the auditor access in the Auditors field.
- Establish a communication plan for when evidence is rejected by the auditor for reasons such as needing more or something other than what is provided.
- Establish how subsequent requests are handled/created. After the initial DRL is loaded into ZenGRC Requests, determine whether the external auditor (not recommended) or the ZenGRC admin/audit manager (recommended) will create them.
- Refer to Quick Tips for End Users for more end-user insights & guidance
Alternative Use Cases
- Helpful shortcut - Create alternative programs for the same framework. For repeated audits that are always scoped to the same set of controls, you can create multiple, but slightly different versions of a program to accommodate quicker scoping of audits. For example, create the following programs with selected controls:
- PCI Audit A
- Scope a subset of controls to this program.
- PCI Audit B
- Scope a subset of controls to this program.
PCI Audit C
Scope a subset of controls to this program.
- During audit creation, select one of the programs and the subset of controls automatically displays for you to "Select all" and scope all controls at once. This saves having to search and select individual controls each time the audit is conducted.
Audit Documentation
• Understanding Audit Workflow Roles
• Audits in ZenGRC
• Creating an Audit
• Jira Audits
• Managing Audits
DEFINITION: For complete definitions of all objects, please see ZenGRC Definitions.
© 2021 Copyright Reciprocity, Inc.
https://reciprocity.com