Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Combined original text with A. Gouvea and G. Sheitlin

Table of Contents
outlinetrue

Object Definitions

...

To get the most out of ZenGRC, it is imperative that you to have a solid understanding of the basic object definitions of ZenGRC. Going forward we will provide you with a Style Guide where you establish how you want your content to appear within ZenGRC. For this to be most effective however, you must first understand our criteria.

Program

ZenGRC's objects and how they are used in the application.

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.

Compliance

...

ProgramPrograms are typically standardized, industry-wide compliance guidelines issued by large authoritative sources. In ZenGRC, a program contains all objects related to one authoritative source. They are often made up of directives (regulations, contracts, clauses, standards, policies, or sections), objectives and controls, assets and risks, and so on. These different object types can be mapped to their respective programs within ZenGRC. Examples of typical programs are PCI, FedRAMP, HIPAA, and SOC 2, but thanks to the dynamic flexibility of ZenGRC, any program can be up and running in minutes. The Audit functionality of ZenGRC is often utilized on Programs, to assess the effectiveness of controls and objectives set in place to maintain compliance with a specific Program.

Directives

Regulations - An authoritative source (e.g. ISO 27001, SOX, Fisma)

Standards - A 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

Policies - A business principle that guides operations

Contracts - A legal agreement between business parties

Clause - A portion of a Contract object

Section - . 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 objects

Objectives/Controls

Because both objectives and controls provide information on how to meet compliance requirements, the two objects can often be confused in ZenGRC. It is up to you to decide where you would like to draw the line between controls and objectives. Below, we offer our definitions of the two objects.

Objectives are general guidelines and recommendations for compliance strategies. 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).

Controls are prescriptive Control - Prescriptive guidelines or rules set in place to ensure a company meets its compliance goals. Often times 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. Risks - Considerations, events, activities, etc. that may reduce the chances an organization will achieve its strategy and goals

Threat Actors - Individuals or organizations who impose risk from an outsider, insider or partner position

Audits - Official inspections of an individual's or organization's controls and/or accounts, typically by independent bodies

Control Assessments - A conclusion of a control's effectiveness at a certain period of time, with regards to a specific selection of mapped objects

Issues - A gap or finding that requires remediation or acceptance

Requests - An audit task that requires a response, usually with evidence attached

Other ZenGRC Objects 

...

People

...

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

...

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.

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.

Groups

...

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

Access Groups - Another object used to track groups in ZenGRC. Typically, this object is used to track groups of people who have access to a specific application(s) or network segment(s).

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

...

Feature Definitions

System of Record

ZenGRC's system of record keeps track of your compliance posture and universe. Our easy-to-use interface allows you to customize attributes without development efforts and map many-to-many relationships between all of the objects that matter to your company.

Workflow

The workflow feature enables you to complete typical compliance related tasks such as document requests. Furthermore, because of their incredible flexibility, workflows can really be used to task manage any project or process within the scope of your business operations. Workflows can be set up with varying frequencies such as daily, weekly, monthly, quarterly, annually, and so. Workflows can be broken up into smaller sub categories based on task groups, and within task groups specific tasks/requests can be created and assigned to specific ZenGRC users. Objects can be mapped to task groups and each task can be assigned to a specific person. Please view our other video on workflows for an advanced tutorial.

Audit

Our Audit module allows for 3 use cases:

1) Evidence collection - Managing a DRL (Document request list) is an extensive project management endeavor. ZenGRC allows you to import a DRL or PBC request list from your auditor, so that you can collect, verify/decline evidence, and escalate the request if no action is taken.
2) Testing and concluding on controls - Our assessment object allows you to easily review submitted evidence, and make a determination for whether or not your controls are operating effectively.
3) Issue management - Internal Audit and External Auditors often find gaps, findings, issues. Our issue object allows you to set up workflows so that you can remediate them and keep track of this lengthy process.

Reporting

1) Downloadable reports - .csv exports that you can use to pull any piece of information from your system-of-record

...

.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/Threats

...

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).

ThreatsThese 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. Oftentimes, these are confused and this confusion reduces the effectiveness of the risk management program

Vulnerabilities - A vulnerability as a weakness that can cause or contribute to a risk’s manifesting, or be 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.