Page Comparison

Overview

To get the most out of ZenGRC, it is imperative to have a solid understanding of ZenGRC's objects and how they are used in the application.

The objects are defined in the order in which they display in the ZenGRC left-hand navigation.

Compliance

Program - Programs are typically standardized, industry-wide compliance guidelines issued by large authoritative sources. In ZenGRC, a program contains all objects related to one authoritative source. It can be a regulatory framework (NIST 800-53, PCI, etc.) or a custom program to manage a compliance initiative (Enterprise Risk Management, Vendor Management, etc.). It serves as a “container” for other compliance objects, and can also be mapped to other objects (including non-compliance objects) to indicate a requirement for regulatory compliance.

Standard - A directive set by a third-party agency, industry group or other non-governmental entity. Typically, standards are based on an authoritative source document (i.e., PCI-DSS for PCI), but can be based on internal standards (i.e., Organizational Cybersecurity Standard). Programs can have one or more standards, or none.*

Section - A portion of a Regulation, Policy, or Standard object.* Indicates an actual section of the authoritative source document (i.e., Requirement 1 of the PCI-DSS, Section XX of a policy document).

* Programs that do not contain standard and section objectives will not display with full functionality in the Compliance Dashboard.

Objective - An individual compliance objective, or requirement that must be met by the organization. This is the actual verbiage of the requirement from the authoritative source document and what must be satisfied by organizational controls to achieve compliance (i.e., Requirement 1.1.1 of the PCI-DSS). Because they are quite vague, interpretation of objectives can vary by company and more actionable, specific controls are often put in place to ensure that objectives are met. We define an objective as an actionable goal that serves to uphold a compliance requirement (the opposite of a risk).

Control - Prescriptive guidelines or rules set in place to ensure a company meets its compliance goals. Often they are step-by-step instructions or commands that when met, assure compliance. We define controls as a company solution that mitigates risks and supports the compliance of its mapped objective. Controls are the only objects that are tested in the audit module in ZenGRC. They can be mapped to various objects to allow audit flexibility (i.e., controls mapped to system A to allow an audit of system A).

Business Objects

Clauses - Typically used to indicate a portion or section of a contract. This can indicate the contractual requirements with which an organization must comply. By mapping relevant controls to clauses, an organization can test its contractual compliance to a specific contract clause.

Contracts - Agreements between the organization and another entity (vendor, customer, etc.). These are typically legally-binding agreements that specify the responsibilities of both entities in the business relationship. Can also be used to reflect internal Service Level Agreements (SLAs) between departments within an organization.

Exceptions - Exceptions to controls, including policies and processes.  Used to track cases in which exceptions to these controls are granted, generally on a temporary basis.  Can be used in conjunction with tasks to track updates in remediating control gaps that necessitate the exception.

Policies - A business principle that guides operations or written directives of an organization that specify minimum requirements on a given topic (i.e., Access Control Policy). Typically, a link is used to the actual policy document to ensure that ZenGRC is not out of sync with actual written policies.

Processes - Written instructions on how to perform a certain activity (i.e., SOX Payroll Process). Typically, a link is used to the actual process document to ensure that ZenGRC is not out of sync with actual written processes.

Vendors - An entity that provides products or services to the organization. To use the Vendor Risk Management module, vendor objects must be created. Can be used to manage vendor compliance to specific controls and/or objectives (requirements). Can also be set as an audit target by mapping relevant controls.

Audit Management

Audits - A container object for audits run against controls. This object will contain metadata around the audit itself (i.e., audit title, audit period, audit 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 - A gap or finding that requires remediation or acceptance. It is 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.

Groups

Org Groups - Objects used to track groups in ZenGRC. Typically, this object is used to track

departments in an organization.

Business Assets

Data Assets - Information that requires protection, such as a user list. They can be used to track things like databases, data files, or removable media objects. A use case for this object is to create tasks and/or workflows to track the disposal of sensitive data media.

Facilities - Objects for tracking organizational facilities, such as offices, datacenters, or warehouses. Can be used to track facility-specific requirements such as datacenter environmental controls. Can also be set as an audit target by mapping relevant controls.

Markets - An area where products or services are sold. Can be used to track market-specific compliance requirements by mapping relevant frameworks and/or requirements.

Products - Objects for tracking products being developed or already developed by an organization. Mapping controls to products in development can help to ensure that proper security protocols are put in place prior to the product’s release. Can also be set as an audit target by mapping relevant controls.

Projects - A service or product delivered to customers, closely related to Systems. It is a planned set of tasks to be executed over a fixed period. This object can be mapped to controls during the project lifecycle to ensure that required security controls are in place prior to go-live.

Systems - Objects used to track IT systems of an organization. Typically, this object is used to track infrastructure components (i.e., servers, network devices) or applications. Mapping relevant controls to a system can help to identify relevant compliance obligations. Can also be set as an audit target by mapping relevant controls.

Risks

---

Risks - Objects used to track risks to the organization. Risks are identified dangers that could potentially harm the organization if not addressed. By mapping relevant controls to identified risks, an organization can identify controls that have been put in place to minimize risk. This is commonly known as a Risk and Control Matrix (RCM).

Threats - These objects identify potential exploitations of a vulnerability. A threat can be environmental (earthquake, snowstorm, flood), physical (hardware failure, building issues, people), or technical (virus, malware, software bug), or other categories as appropriate.  It is critical to recognize that a threat is able to exploit a vulnerability. You can typically reduce the impact of the threat on the vulnerability, but it is very difficult to avoid the threat altogether. By creating and mapping relevant Issues to Threats, a remediation plan can be identified and implemented to minimize or eliminate the threat.

Incidents - Incidents track risks and or vulnerabilities. They can be used to track failures in patching processes, which could lead to a risk manifesting, or the fact that the actual risk has manifested. It must be clear, that an incident is not a risk, nor is it a vulnerability. Often, these are confused, which reduces the effectiveness of the risk management program

Vulnerabilities - A vulnerability as a weakness that can cause or contribute to a risk manifesting as, or being exploited by a threat.  It is a gap that increases the likelihood that something will happen. While a risk is theoretical, a vulnerability is real. Perhaps you’re easily distracted by your phone --a vulnerability--so you put it away while you drive: a control. Maybe you’re not a confident driver, so you take that driving class: a remediation.

Workflows