KnowBe4 KCM GRC: Glossary of Compliance Terms
This glossary contains terms and key concepts that will help you better utilize your KCM Governance, Risk and Compliance (GRC) Platform, easing the burden of staying compliant year-round!
In addition to the terms highlighted in the jump links below, you can find related concepts within each of these sections.
Controls can be thought of as the method, evidence or proof that demonstrates how you are meeting your various Requirements. Controls are a document, process, technical implementation, or other action that relates to one or more Requirements.
We recommend making your Control description very detailed. The description should include what the Control is, how to review and assess the Control, what type of Evidence is expected as a result of a review, and where that Evidence should be placed. The Control description is used in the Task reminder emails and in the Detailed Compliance Reports. If you should need to change ownership of the Control, providing these details will make it much easier for the new user to understand what is expected.
Examples of Controls are:
- Disaster Recovery Policy and periodic review and testing of the policy
- Active Directory password configuration settings review
- Apply the latest patches to SERVER1
- Collect Security and Privacy documentation from VENDOR
- Review and Document Incident
Recurring Tasks can be scheduled on an Annual, Semi-annual, Quarterly, Monthly, or Weekly basis, and are assigned to the Responsible User to complete. Tasks may also be created on an ad-hoc basis, whenever they are needed outside of the recurring schedule.
Control Documents are an optional way to submit an example of evidence documents needed by the Responsible User, in order to satisfy a Task. While this is not a replacement for the Evidence of Task completion, it is a way to support the act of gathering evidence for a particular Control.
Examples of Control Documents:
- Blank management sign-off form
- Screenshot of a particular area in Active Directory
Evidence is provided to satisfy Tasks, in order to support a Requirement's Control. The Evidence Repository section of KCM GRC is a file/URL repository where you can store evidence that Controls are in place and operating as they should be. Evidence can be provided in the form of file uploads or URLs (DocuLinks) that point to the Evidence.
Documents (File Upload)
File upload is one way you can use KCM GRC to store audit evidence. Each file that is uploaded is uniquely encrypted and stored securely in the cloud. Uploaded files are associated with a specific Task.
You should use the file upload feature if you are not currently using a central storage facility for audit evidence.
DocuLinks, or links to Evidence, is an option for storing audit evidence in KCM GRC. If you are currently using a centralized storage area on your internal network for maintaining audit evidence, you do not need to upload files to KCM GRC as well. By providing a URL to the Evidence, you get the benefits of linking that information to a specific Control or Task without storing files in multiple places.
A Requirement is a concrete statement that describes a compliance objective, audit finding, best practice, or other obligation that the organization is striving to achieve or correct.
Some examples of Requirements are:
- PCI DSS 1.1.2 – Current Network Diagram – There must exist a current network diagram with all connections to cardholder data, including any wireless networks.
- HIPAA 164.308(a)(2)(ii) – Facility Security Plan – Implement policies and procedures to safeguard the facility and the equipment therein from unauthorized physical access, tampering, and theft.
- Internal IT Audit FY2015 – Finding #4 Missing Security Patches – The following servers did not have the most recent security patches applied: SERVER1.
A Scope is an umbrella structure to manage a series of related Requirements, Controls, and Evidence. A Scope is a way to describe the boundaries of a project or audit. In KCM GRC, permissions, Reports, and Dashboards are divided up by Scope.
For example, Scopes can represent separate physical locations, different ongoing compliance initiatives, remediation and audit findings, incident and vendor management, tracking projects, etc.
Scopes are typically created from Templates, see the Custom Templates section below for more information.
Each Scope can be exported so that the data can be saved for offline archiving. The format of this export is a zip file (which can be password-protected), containing a series of HTML files that mimic the Detailed Compliance Report found in the console.
Scope Requirements Self-Assessment (Optional)
Each Scope has a set of Requirements. Each Requirement has a Self-Assessment question, or status, associated with it. You can set the status for each Requirement in a Scope by going through the Scope's Self-Assessment.
You can set the status as:
-‘Met’ if this is a Requirement that you are meeting
-‘Not Met’ if you have not yet met the Requirement
-‘Not Applicable’ if the Requirement is not applicable to your organization for that Scope
(You can later remove the non-applicable Requirements from the Scope by unmapping them.)
Tasks allow for the continuous monitoring of Controls. They give you an opportunity to collect Evidence relating to a Control on a periodic basis so you will be prepared when it is time for an audit.
Automated email reminders are sent to the Responsible User upon the Task's creation, and when the Task's due date is approaching. These reminders go out 30 days prior, seven days prior, one day prior, on the due date, and every day for one week following the due date (when the Task is considered past due).
Effective Date Range
You can choose whether or not you want to use Effective Date Range when setting up a Task Schedule for a Control.
If you utilize Effective Date Range, you are choosing to specify the length of time that the Evidence submitted for a particular Task is valid–in reference to the associated compliance Requirement.
Say you must submit network access files in order to meet a compliance requirement, and the date range for these files to remain valid is January 1, 2018 - December 31, 2018.
When setting a Task Schedule for these files, you would select "Yes" for "Use Effective Date Range", choose "Annually" for the Frequency, and input January 1, 2018, as the Start Date. The Effective Date Range feature will assume 12/31/18 is the date this Evidence is no longer valid. Therefore, the due date to submit new Evidence for this Task would be three months after 12/31/18, by default. You have the ability to change the Effective Date Range default due dates in your Account Settings.
Compliance Templates are the highest-level object within KCM GRC. A Template is a repository or collection of Requirements that are related to one another. A Template can either be a "Managed Template" which is created and kept current by KnowBe4, or a "Custom Template" which is created by the KCM GRC customer to suit their needs.
Templates contain a group of Requirements that a KCM GRC customer will create and manage. This can be anything from audit requirements and findings, state and local regulations, security best practices, vendor management, incident management, IT and non-IT based projects, and more.
As a best practice when creating Scopes, we recommend you start with a Template and convert it into a Scope. We recommend this method because you can continue to utilize the Template's References for additional compliance (or general) objectives, by adding them to additional Scopes.
These are common groups of Requirements that are created and managed by KnowBe4.
You can find a current list of the Managed Templates we offer on our website.
The Risk Templates are a portion of the KCM GRC Risk Management Module. The Risk Templates area of your console holds the pre-populated Risks offered from our Master Risk Repository, as well as any Risks you've imported or manually created in your KCM GRC platform. See the KCM GRC: Risk Templates article for more information.
The KCM GRC platform consists of three different modules: the Compliance module, Policy Management, and Risk Management modules. Below you can see the different user types under their associated KCM GRC module.
KCM GRC Compliance Module
- Account Administrator
- Contributor/Scope Administrator
KCM GRC Policy Management Module
- Policy Administrator
- Campaign Manager
- End User
KCM GRC Risk Management Module
- Risk Administrator
See our KCM GRC: User Types guide for more information on each user type and what permissions they're allotted.