Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Overview


ZenGRC provides a robust forum to effectively manage audits for your organization. This best practice guide will help ZenGRC administrators successfully set them up so assignees understand the role they play and 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.

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: 

  • Auto Population - A fast way to assign assessors in audit creation is to pull information from other fields during Step 3 of an internal audit. Depending on the selection, users will be assigned as assessors or verifiers for all assessments generated in the audit.
    • The Default assessors dropdown in the audit wizard is shown below (the Default verifiers dropdown is directly to the right of it):



    • If Control owner, Primary Contact or Secondary Contact is selected, the audit wizard pulls information from each control in the audit and assigns as the assessor or verifier. A control object's Owner field is shown below:



    • If Audit managers is selected, the audit wizard pulls information from the Audit managers field in Step 1 of audit creation, which is shown below:



  • Identify the control owner for each control
  • Create the import template - Although the requests template isn't imported until Step 4 of Audits, it should be an immediate action item. One suggestion specific to audit spreadsheets is 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 export of evidence and downloadable reporting.

    • Note that Jira audits use a different import template that is found in Step 4 of 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.

    • Start dates for requests are when the emails begin sending to the assignees.

      Info
      titleNOTE

      For additional information on requests, templates and Jira, please see Step 43: Setting up Audit 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 2 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.”
    • For ZenGRC access, set up the external auditor in a Contributor role. In Step 1 of audit creation, you can assign the auditor access in the External 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.

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.