Anda di halaman 1dari 24

IT Governance, Risk and

Compliance

PDF generated using the open source mwlib toolkit. See http://code.pediapress.com/ for more information.
PDF generated at: Sun, 16 Mar 2014 17:26:27 PST

IT Governance, Risk and Compliance

IT Governance, Risk and Compliance


Overview
IT governance, risk, and compliance (IT GRC) supports:

Documenting policies and procedures, including those from authoritative sources.


Defining and assessing risks.
Defining controls based on policies and their associated risks.
Generating audits and tests to ensure that controls are being followed.
Generating remediation tasks to track corrective actions that are required.

Concepts
Authoritative Sources
An authoritative source is a document that defines the external standards, frameworks, or regulations that a process
must use. These are stored as references, from which policies can be defined. The authoritative source can be broken
up into authoritative source content records that can be interrelated with authoritative source content relationships. In
this way, not only can the authoritative source be viewed as a whole, but the relationships between different sections
can be mapped to better record how the authoritative source is meant to be implemented.
The same relationship mechanism can be used to document relationships across authoritative sources. This is
important because different sources address the same or similar controls and objectives.

Policies
A policy document defines an internal practice that processes must follow. The Policy [grc_policy] table extends
Knowledge [kb_knowledge]. Each policy is stored in the knowledge base and can be accessed in the same way as
any other published article.
To manage elements of the policy, the policy can be associated with:

Entities managed.
Authoritative sources with which it is designed to comply.
Risks associated with failing to comply.
Controls in place to enforce the policies and mitigate identified risks.

Audits
An audit definition establishes a set process for validating controls and control tests. From the definition, audit
instances can be generated as a task to power the audit.
Once generated, audit instances can reference any existing evidence of compliance by associating previously
executed control tests with the control test definitions that have been established in the audit.
During the audit process, audit observations can be recorded by the auditor to track the gathered information. The
auditors can use these observations to create remediation tasks.
During the audit process, an administrator can create and assign remediation tasks that need to be performed before
and during an audit. In addition, audit requirements associate authoritative source content to the audit, allowing
auditors to track compliance or non-compliance with the original regulations.

IT Governance, Risk and Compliance


If the latest evidence is not recent enough, click Execute Now in the Control Test Definition form to execute a
control test instance. This action creates the control test instance and automatically associates it to the audit. The
control test instance record also has the Generate from audit field populated with the audit number, so that it is
clear that the test was created from an audit and not manually.

Risks
A risk is a definition of the possible consequence of failing to comply with a policy. Risks are rated based on risk
criteria that can be used to calculate a risk approach. The risk approach calculation is based on risk approach rules
that typically use the values contained in the Significance and Likelihood fields in the Risk Criteria
[grc_risk_criteria] table. This table contains a Display value field to allow for text values and a weighting, which
can be used to define the risk approach rules.
After the risks are defined, they can be associated with controls to identify how they are being mitigated.

Controls
A control is a process to mitigate risk, enforce a mandated policy statement, and address the directive of an
authoritative source. The control may have one or many control tests associated with it. This ensures that the control
is effective and provides continued compliance. Controls can also be directly associated with authoritative source
content to map an organization's internal controls to those mandated by the authoritative source.

Control Tests
A control test definition determines how and when a control test is performed, including execution steps and
expected results. Each time the control test is performed, a control test instance is generated as a task to be executed,
according to the control test definition. If the control test benefits from included sample data, such as a verification
that servers listed in the CMDB have the correct configurations, the control test definition can be configured to
automatically gather control test sample data from the appropriate table anywhere within the ServiceNow database.
Certification filters and templates simplify the selection of records to test, starting with the Dublin release.
Certification filters provide the scope for test definitions by filtering a table for specific records. You then attach the
filter to a template that tests specific attributes of the filtered records.
The control test definition includes the ability to define the remediation group that is automatically assigned to a
remediation task if the control test instance state is set to Failure.
For more information, see Managing Controls and Tests.

Condition Collections and Conditions


Condition collections can be created with associated conditions to define advanced control test logic.

Entities
Entities are user definable records in the system that can be associated with policies and audits. This could refer to
entities such as a locations, business units, or anything that is important to the organization.

User Roles
These roles provide access to IT governance, risk, and compliance starting with the Dublin release. Each role can
perform all the activities of the roles it contains. If you are using an earlier release, see the previous version
information.

IT Governance, Risk and Compliance

Role
grc_user

Contains Roles
task_editor

Description
Can create and edit policies, risks, controls, and
authoritative sources. Can edit control tests, remediation,
and audit records.

grc_audit_definition_admin task_editor

Can create and edit audit definitions. Can read audit


records and records associated with an audit.

grc_test_definition_admin

task_editor, certification_filter_admin

Can create control test definitions. Can read condition


collections, conditions, and control tests.

grc_admin

grc_user, grc_audit_definition_admin,
grc_test_definition_admin, task_editor,
certification_filter_admin

Can manage entities, risk criteria, condition collections,


and conditions.

Click the plus to expand previous version information

Role
grc_user

Contains Roles
task_editor

Description
Can create and edit policies, risks, controls, and authoritative
sources. Can edit control tests, remediation, and audit records.

grc_audit_definition_admin task_editor

Can create and edit audit definitions. Can read audit records
and records associated with an audit.

grc_test_definition_admin

task_editor

Can create control test definitions. Can read condition


collections, conditions, and control tests.

grc_admin

grc_user, grc_audit_definition_admin,
grc_test_definition_admin, and task_editor

Can manage entities, risk criteria, condition collections, and


conditions.

IT Governance, Risk and Compliance

Menus and Modules

Policies: The list view of the Policy [grc_policy] table.


Risks: The list view of the Risk Definition [grc_risk] table.
Controls

My Controls: A list of controls for which the user is either the Owner or Delegate.
My Groups Controls: A list of controls for which the user's group is the Owning Group.
All: The list view of the Control [grc_control] table.
Control Tests

Assigned to Me: A list of control tests that are assigned to the current user.
My Groups Tests: A list of control tests that are assigned to the current user's group.
All: The list view of the Control Test [grc_control_test] table.
Remediation

Assigned to Me: A list of remediation tasks that are assigned to the current user.
My Groups Remediation: A list of remediation tasks that are assigned to the current user's groups.
All: The list view of the Remediation [grc_remediation] table.
Audit

Assigned to Me: A list of audits that are assigned to the current user.
My Groups Audit: A list of audits that are assigned to the current user's group.
All: The list view of the Audit [grc_audit] table.
Observations

Assigned to Me: A list of audit observations that are assigned to the current user.
My Groups Observations: A list of audit observations that are assigned to the current user's group.
All: The list view of the Audit Observation [grc_audit_observation] table.
Authoritative Sources

Authoritative Sources: The list view of the Authoritative Source [grc_authoritative_source] table.
Content: The list view of the Authoritative Source [grc_authoritative_src_content] table.
Relationship Types: The list view of the Authoritative Content Relationship Type [auth_content_rel_type] table.
Administration

Entities: The list view of the Entity [grc_entity] table.


Risk Criteria: The list view of the Risk Criteria [grc_risk_criteria] table.
Risk Approach Rules: The list view of the Risk Approach Rules [grc_risk_approach_rules] table.
Control Test Definitions: The list view of the Control Test Definition [grc_control_test_definition] table.
Condition Collections: The list view of the Condition Collection [grc_condition_collection] table.
Conditions: The list view of the Condition [grc_condition] table.
Audit Definitions: The list view of the Audit Definition [grc_audit_definition] table.
Filters: The list view of active versions of all certification filters. This functionality is available starting with the Dublin
release.
Templates: The list view of certification templates of audit type Compliance. This functionality is available starting with
the Dublin release.
Properties: The properties for configuring Governance.

Activating IT Governance Risk and Compliance


Administrators can activate the IT Governance, Risk and Compliance plugin. This plugin activates the Version
Management plugin, which manages certification filter and template versions. This plugin provides demonstration
data.
Instructions for activating a plugin.

IT Governance, Risk and Compliance

1. Navigate to System Definition > Plugins.


2. Right-click the plugin name on the list and select Activate/Upgrade.
If the plugin depends on other plugins, these plugins and their activation status are listed.

3. [Optional] Select the Load demo data check box.


Some plugins include demo datasample records that are designed to illustrate plugin features for common use cases. Loading demo data is
a good policy when first activating the plugin on a development or test instance. You can load demo data after the plugin is activated by
repeating this process and selecting the check box.
4. Click Activate.

Dependencies
The following plugins are activated with IT Governance, Risk, and Compliance:

List v2 Plugin
Certification Core
Project Management
Many to Many Task Relations

Enhancements
Dublin
Control test definitions support the use of certification filters and templates to define the scope and conditions for
control tests. Templates enable an administrator to define attribute conditions for any table in ServiceNow.
Demonstration data provided with the Dublin release enables customers to audit vendors for non-disclosure
agreements (NDA). You can substitute filters and templates for the existing condition collection functionality, but
you must create your own records. ServiceNow does not provide NDA demonstration data for the new elements.

Defining Authoritative Sources

Defining Authoritative Sources


Overview
An Authoritative Source is a document which defines external standards, frameworks, or regulations that processes
must adhere to. The Authoritative Source is defined by a master record on the Authoritative Source
[grc_authoritative_source] table, with a related list of Authoritative Content [grc_authoritative_src_content]
records. The content records contain the actual provisions of the authoritative source, which can be interrelated.
From these Authoritative Sources, Policies can be defined, with Risks, Controls, Audits, and other processes to
ensure that the Authoritative Source is being held to.

Defining an Authoritative Source


Field

Input Value

Name

The name of the Authoritative Source.

Type

A choice list of types of documents. Out-of-box, choices are:

None
Regulation
Framework
Standard
Related List: Authoritative Source Contents

Reference

A reference number to the section of the Authoritative Source that contains the contents.

Name

The name of the Authoritative Source Content section.

Type

The type of content contained in this Authoritative Source Content.

Authoritative Source A reference to the parent Authoritative Source.


Key Areas

The important content from the Authoritative Source.

Comments

Relevant information or discussion.

Defining Authoritative Source Content Relationships


Adding Relationships Between Contents
To add a relationship between two Authoritative Source Contents, navigate to one of the contents' forms, and select
either the Add related to or Add related from related links.
Populate the following fields:

Defining Authoritative Sources

Field

Input Value

To

The content that is the object of the relationship.

Relationship The Relationship Type. To add a new relationship, see Defining Relationship Types
From

The content that is the subject of the relationship.

The display-only fields at the bottom will display the information from the other Authoritative Source Content
record:

Once selected, the content will appear in the Related to or Related fromrelated list, as appropriate:

Defining Relationship Types


To define an Authoritative Source Relationship Type, navigate to IT GRC > Relationship Types and click New.
Populate the following fields:

Defining Authoritative Sources

Field

Input Value

From descriptor A description of how the relationship's subject relates to its object.
To descriptor

A description of how the relationship's object relates to its subject.

Name

A name for the relationship. Out-of-box relationship types use the format <from_descriptor>::<to_descriptor>

Active

If true, the relationship type will be available for selection.

Relating Authoritative Source Contents to Policies


Authoritative Source Contents can also be associated with policies. For more information, see Managing Policies.

Viewing Relationships with Authoritative Source Hierarchy


The relationships between Authoritative Source Content and Controls can be viewed by navigating to IT GRC >
Content and selecting the View Hierarchy related link. This view is useful to visualize where organizational
controls are or are not in place to address Authoritative Source Content:

By right-clicking on any of the items, the hierarchy can be refocused on the item, or the item can be edited:

The +/- controls in the top right-hand corner of the item can collapse or expand child items:

When the items display, they will display in the format:


Authoritative Source: Authoritative Source Content

Defining Authoritative Sources


Authoritative Source Content Type: Short Description of Authoritative Source Content

Managing Policies
Overview
A policy is a document which defines an internal practice that processes must adhere to. The Policy [grc_policy]
table extends Knowledge [kb_knowledge], so each policy is stored in the Knowledge Base and can be accessed in
the same way as any other published article.
To manage elements of the policy, the policy can be associated with:

The Entities managed


The Authoritative Sources and Authoritative Source Contents it is designed to comply with
The Risks associated with failing to comply
The Controls in place to enforce the policies and/or mitigate identified risks

Defining Policies
To define a policy, navigate to IT GRC > Policies and click New.
Field

Input Value

Number

A unique number assigned to the KB article using Number Maintenance.

Article Type

The type of markup used to write the article. Choices are HTML and Wiki.

Classification

A choice list of how the article is classified, specific to Policies.

Topic

Determines where in the Knowledge Base the Policy will appear. By default, the Topic will be Policies

Distribution

A choice of how the policy is to be distributed.

Workflow

A stage field for how far along the policy is in the drafting process.

Published

Date of publication.

Roles

Determines who can see the article. If empty, everyone can see the policy. Once a role is input, only the selected roles can see
the policy.

Valid to

A date for the Policy to no longer appear in the knowledge base.

Attachment link

If true, selecting the policy from the Knowledge Base will open the attachment rather than opening the policy in the Knowledge
Base.

Image

An icon to appear next to the policy in the Knowledge Base.

Short
Description

A short description or title for the policy.

Text

The text of the policy.

The related lists can be used to associate the Policies to other tables.
When Authoritative Source Content items are added to the related list, the parent Authoritative Sources will be
added to the appropriate related list.

Managing Policies

10

Defining Entities
An Entity can be any object to which a Policy refers. Entities are associated to Policies using the Scope related list
on the Policy form.
To define an entity, navigate to IT GRG > Entities and click New. Populate the following fields:
Field Input Value
Name The name of the entity.
Type

What the entity is from the perspective of policies.

Enforcing Policies
Once policies are defined, there are two processes available for ensuring that their provisions are followed:
Risk Managing - Once risks are defined, they can be managed using Controls and Control Tests to protect
against the consequences of breaching policies.
Audits - Once all of the processes for policies have been defined, audits can be performed to confirm that they are
being performed properly.

Defining Risks
Overview
A Risk is a defined consequence that will occur if a Policy is not complied with. Once risks are defined, they can be
managed by:

Defining Risk Criteria


Defining a Risk Approach Rule
Defining Controls
Defining and performing Control Tests

Defining a Risk
To define a Risk, navigate to IT GRC > Risks and click New. Populate the following fields:
Field

Input Value

Risk ID

A unique number assigned to the Risk using Number Maintenance.

Risk Name

The name of the risk.

State

A choice field for the state of the risk. Choose from:

Known The existence of the risk is known. This is the default value.
Open The risk has been analysed.
Issue The risk has occurred.
Closed The risk is no longer valid. E.g the risk was related to mainframes, but the organisation no longer uses
mainframes.

Category

What category of risk applies to the record.

Applies To

A Document ID field to identify the scope.

Description

A verbose description of the risk.

Defining Risks

11

Significance

The impact of the the risk if it is realized. Defined by Risk Criteria.

Likelihood

The probability that the risk will be realized. Defined by Risk Criteria.

Recommended
approach.

A reference to the Risk Approach Rule that determines how to treat this risk. Can be calculated dynamically using the
Calculate Risk Approach UI action on the form.

Defining Risk Criteria


In the base ServiceNow system, the risk criteria available on the form are:
Significance
Likelihood
These are defined on the Risk Criteria [grc_risk_critera] table, which holds a record for each possible choice,
grouped by Type.
1. Navigate to IT GRC > Administration > Risk Criteria.
2. Click New.
Populate the fields as follows:

Display value - One of the choices for the new Risk Criteria (e.g. 5 - Extremely Expensive).
Order - The order in which this choice appears in the choice list.
Type - The name of the new risk criteria (e.g. Cost)
Weighting - A numeric value for the risk, used to calculate Risk Approach Rules. Low Weighting indicates a
lower overall Risk, and high Weighting indicates a higher overall risk.

3. Repeat the previous step for each of the choices for the new risk criteria. Keep the Type field the same, while
changing the other fields appropriately.
4. Navigate to the Risk Definition form, by clicking on the Risks module.
5. Personalize the Form to add a new Reference field to the Risk Criteria [grc_risk_criteria] table. Typically, this
new field should share the same name as the Type field of the Risk Criteria.
6. Right-click the new field's label to Personalize the Dictionary.
1. For the Reference qual field, add type=<type-value, where <type-value> is the value from the
Type field of the risk criteria.
2. To format the field as a choice list, select Drop-down with --None-- from the Reference choice field.
3. Submit.
The new field should appear on the form as a drop-down:

Defining Risks

12

Defining Risk Approach Rules


To define a risk approach rule, navigate to IT Governance, Risk, & Compliance > Risk Approach Rules and click
New. Populate the following fields:
Field

Input Value

Recommended
approach

A short description of the approach philosophy that will be used to mitigate the risk.

Active

If checked, the approach will be available for selection.

Condition

A Condition Builder which determines what risks this approach will be applied to if the Calculate Risk Approach button is
clicked. Note: the first condition that is matched wins, so when creating new risk approach rules ensure that the conditions do
not overlap with other risk approaches.

Description

A full description of the risk approach.

Managing Controls and Tests

Managing Controls and Tests


Overview
After you identify the risks, define controls with accompanying control tests to prevent issues from occurring. This
diagram illustrates the entire IT GRC control process.

13

Managing Controls and Tests

14

Defining a Control
1.
2.
3.
4.

Navigate to IT GRC > Controls > All.


Click New.
Fill in the form, as appropriate (see table).
Click Submit.

Field

Description

Control ID

A unique identifier generated dynamically by the system.

Name

A name for the control.

Applies to

Number of a record from any table in the system. This value defines the scope of the control.

Classification

The type of control.

Purpose

The approach that the control will take.

Control frequency The basis for determining when the control is implemented.
State

A workflow field that determines where in the authoring process the control is currently.

Key control

Indicator that the control is considered key to preventing material risk, if selected.

Owning group

A reference to the group with ownership over the control.

Owner

A reference to the user with ownership over the control.

Owner delegate

A reference to the user who has ownership over the control when the specified owner is unavailable.

Description

A long-form description of the control.

Managing Controls and Tests

15

Defining a Control Test


After you define a control, create control tests that run periodically and provide documented evidence of whether the
associated control is operating correctly.
1.
2.
3.
4.

Navigate to IT GRC > Administration > Control Test Definitions.


Click New.
Fill in the form, as appropriate (see table).
Click Submit.

Field

Description

Definition ID

A unique identifier generated dynamically by the system.

Name

The name of the control test.

Control

A reference to the control being enforced.

Method

One of the following choices for determining the test assignee:

Assign to Group: Assignment group for the control test.


Assign to Individual: User assigned to the control test.

Assign to group

Group assigned to this control test. This field is available only when the selected method is Assign to Group.

Assign to

User assigned to this control test. This field is available only when the selected method is Assign to Individual.

Remediation
group

Group assigned to the remediation tasks if a control test fails.

State

A workflow field to indicate where in the drafting process this control test currently is. If the state is Active, control test
instances are dynamically generated based on this record's definition.

Managing Controls and Tests

Run

Frequency for generating control test instances. Choices are:

Daily
Weekly
Monthly
Periodically
Once
On Demand

Time

The time that a control test instance is automatically generated if Run is set to Daily, Weekly, Monthly, or Periodically.

Day

Day of the week that a control test instance is generated each week if Run is set to Weekly. Day of the month if Run is set to
Monthly.

Repeat interval

A duration, in days and hours, between the automatic generation of control test instances if Run is set to Periodically.

Starting

The date and time control test instances are first generated if Run is set to Periodically. The only date and time a control test
instance is generated if Run is set to Once.

Execution step

The steps involved in the control test.

Expected result

The result that should occur after these tests.

Include
supporting data

Indicator whether sample data should be taken from a particular table within the instance when the control test instance is
generated.

Data purpose

The purpose of the data being sampled If Include supporting data is selected. This selection influences how the control test is
performed. Choices are:

Table

None
Support test execution: Returns a random sampling of records.
Identifies non compliance: Returns all of the records that do not match the condition or conditions specified.
Identifies compliance: Returns all of the records that do match the condition or conditions specified.

The table from which to sample when Include supporting data is selected.
This field is read-only when Template is the Condition type. When you select a template to define test conditions, the table is
set by the certification filter used in the template and cannot be changed. Filters and templates are available starting with the
Dublin release.

Fields

The list of fields to pull values from when determining whether records match the conditions if Include supporting data is
selected.

Condition type

The type of conditions applied to the table and fields above. Choices are:

Basic: Applies conditions to the table in question.


Advanced: Uses condition collections to apply conditions to the table and to related tables. For more information, see
Defining Advanced Conditions.
Template: Uses certification templates to apply conditions to the specified table. Select the template to use from the
Template field. Templates are available starting with the Dublin release.

Sample size

An integer number of rows for a random sample if Include supporting data is selected. A sample size of zero returns all
matching records. This field is available only if Condition type is set to Basic and Data purpose is set to Support test
execution.

Control test
conditions

A condition builder that limits the sample data if Include supporting data is selected. This field is available only if Condition
type is set to Basic.

In scope
definition

A reference to a condition collection if Include supporting data is selected and Condition type is set to Advanced. For more
information see Defining Advanced Conditions.

Configuration to
retrieve

Method for using the Configuration reference field if Include supporting data is selected and Condition type is set to
Advanced or Template.

None: Returns all records in scope.


Matching: Returns all matching records in scope.
Non-matching: Returns all non-matching records in scope.

For more information, see Defining Advanced Conditions.

16

Managing Controls and Tests

Template

[Required] Certification template that defines conditions for this test definition. Only templates with an audit type of
Compliance are available for selection. This field is available and mandatory when the value in the Condition type field is
Template. For more information about compliance templates, see Certification Templates. Templates are available starting with
the Dublin release.

Configuration

Condition collection to use. This field is available only if Include supporting data is selected, Condition type is set to
Advanced, and Configuration to retrieve is set to anything except None.

Defining Advanced Conditions


Set the Condition type to Advanced on control tests to define more flexible conditions using condition collections.
Condition collections have one primary condition, which is applied to the selected table, and one or more
supplemental conditions.
When a control test is performed, advanced conditions evaluate in this order:
1. The system processes the condition collection in the In scope definition reference in this order:
a. The primary condition is processed on the fields specified in Table and Fields on the control test definition,
returning an array of elements.
b. For each element in the array returned by the primary condition, supplemental conditions are processed,
filtering the array of elements further.
c. The In Scope field is updated with the number of elements in the array.
2. The condition collection in the Configuration reference is processed on the array of elements returned from the
In scope definition. The choices for Configuration to retrieve are:
None: These conditions are skipped. Supporting Data is all of the elements that are in scope.
Matching: The control test checks the array of elements, returning any elements that match the
Configuration.
Non-matching: The control test checks the array of elements, returning any elements where at least one
condition did not match the Configuration.
3. The final array of elements is recorded as Supporting Data records.
Both the In Scope and Configuration fields refer to the Condition Collection [grc_condition_collection] table.
To define condition collections:
1. Navigate to IT GRC > Administration > Condition Collections.
2. Click New.
3. Populate these fields:
Name: Name of the condition collection.
Description: Description of the condition collection.
Type: Which Control Test Definition field references the condition collection. Choices are:
In Scope Definition
Configuration Definition
4. After the condition collection is defined, use the Add Condition related link to add these conditions:
Condition: Predefined condition definition from the Condition [grc_condition] table.
Condition type: Choices are determined by the condition collection Type:
In Scope Definition
Primary
Supplemental
Configuration Definition
Not Applicable

17

Managing Controls and Tests


To define new condition records:
1. Navigate to IT GRC > Administration > Conditions.
2. Click New.
3. Populate these fields:

Name: Name of the condition collection.


Description: Description of the condition collection.
Table: Table on which the condition should be applied.
Reference Field: For supplemental conditions, the reference field for the table on which the primary condition
is running.
Condition: Condition builder for defining the condition.

Performing a Control Test


The following processing dependencies exist:
If a control test definition is active, the system generates the control test instances dynamically, according to
definition. To generate a control test manually:
1. Navigate to IT GRC > Administration > Control Test Definitions.
2. Open a control test definition record.
3. Click Execute Now.
ServiceNow generates a control test instance, marks it Pending, and assigns it to the group or individual
responsible for the test according to the control test definition.
If sample data was requested in the definition, any sample data that matches the conditions is found in the
Supporting Data section. The Test Complete Data Values related list holds references to the records returned
by the sample data query.
If a control test has a condition type of Basic, the value in the Sample size field limits the number of failures that
are stored as support data. If the result is passed or compliant, all the matching data is stored.
If a control test has advanced conditions, the system evaluates them as follows:
1. The condition collection in the In scope definition reference is processed.
a. The primary condition is processed on the fields specified in Table and Fields on the control test
definition and returns an array of elements.
b. For each element in the array returned by the primary condition, supplemental conditions are
processed, filtering the array of elements further.
c. The In Scope field is updated with the number of elements in the array.
2. The condition collection in the Configuration reference is processed on the array of elements returned from
the In scope definition. The choices for Configuration to retrieve are:
None: These conditions are skipped. Supporting Data includes all of the elements that were in scope.
Matching: The control test checks the array of elements, returning any elements that match the
Configuration.
Non-matching: The control test checks the array of elements, returning any elements where at least one
condition did not match the Configuration.
3. The final array of elements is recorded as Supporting Data records.

18

Managing Controls and Tests

Remediation Tasks
If the control test reveals problems in the process, create a task from the Remediation Task related list. You can
relate remediation tasks to any task in the system with the related items tool from the Many to Many Task Relations
plugin.

Managing Audits
Overview
Once Policies are defined, an Audit Process can be put in place to verify that the Policy, and any Risk Controls
associated with it, are being followed.

Process Diagram
The following diagram illustrates the process of managing an audit with IT Governance, Risk and Compliance:

19

Managing Audits

20

Creating an Audit Definition


The first step in the audit process is for the auditor to define the necessary audit.
To define an audit, navigate to IT GRC > Administration > Audit Definitions. Populate the following fields:
Field

Input Value

ID

A unique ID for the audit definition, populated by Number Maintenance.

Name

A name for the audit definition.

Owning group

A reference to a group to have ownership over the audit process.

Owner

A reference to a user to have ownership over the audit process.

Execution group

A reference to the group that will execute the audit.

Type

The type of audit process.

State

Where in the drafting process the definition is.

Short Description A short description of the audit.


Description

A full description of the audit.

The related list Control Test Definitions can be used to specify control tests to perform during the audit. The related
list Scope can be used to define entities for the audit to refer to.

Audit Requirements
Audit Requirements can be defined to create a relationship between the audit and authoritative source content,
allowing auditors to determine whether the audit is in compliance with particular sections of regulation or policy.
The audit requirement is defined by navigating to IT GRC > Audit Definitions, locating the Requirements related
list, and clicking Edit to add Authoritative Source Content to the Requirements List. Once the audit requirements are
added to the list, a control test can be specified in the Control Test Definition to be associated with the control test.
Once the audit requirements are associated with the audit definition, they will create Requirements records
associated to each Audit Instance generated. The Requirements form has the following fields:
Field

Input Value

Number

A number identifier for the requirement, populated by Number Maintenance.

Requirement

A reference to the Authoritative Source Content which contains the original source of this requirement.

Name

The name field from the Authoritative Source Content record.

Type

The type field from the Authoritative Source Content record.

Authoritative Source

The authoritative source field from the Authoritative Source Content record.

Control test definition

The control test associated with the requirement.

Supporting control test The control test instance whose results are either compliant or not compliant with this requirement.
Compliant

A checkbox to record whether the audited subject is compliant with this requirement.

State

The state field from task.

Assignment group

A group assigned to assess the requirements.

Assigned to

A user assigned to assess the requirements.

Managing Audits

21

Creating an Audit Instance


Once the audit is defined, use the Create Audit Instance related link to generate an Audit Instance record, which
can manage the audit process.
The audit is automatically assigned to the owning group, and the event grc_audit.inserted is recorded in the event
log by the business rule planned task global events.

Recording Audit Observations


The observations related list on the Audit Instance record can be used to record any information uncovered in the
audit process. Remediation tasks can be generated directly from audit observations. For instance, the audit
observation "There is no process around off-boarding can lead to the remediation task Define off-boarding process.
Using the Related Items tool (from the Many to Many Task Relations Plugin), audit observations can be related to
any task on the platform by explicitly defined relationships.

Recording Audit Activities


Audit Activities are used to record and track the tasks required to perform an audit instance. To create an Audit
Activity, navigate to the appropriate audit instance and use the Audit Activities related list.
Populate the following fields:
Field

Input Value

Number

An incremented identifier for the audit activity, generated using Managing Record Numbering.

Requested By

A reference to the user who requested the audit activity.

Requestor Reference A reference to a record in a third party system where the requestor may be tracking the requirement
Opened By

A reference to the user who created the audit activity.

Opened

A date-time stamp for when the audit activity was created.

State

A choice list for status of the task:

Pending
Open
Work in Progress
Closed Complete
Closed Incomplete
Closed Skipped

Assignment Group

A reference to the group assigned to perform the audit activity.

Assigned To

A reference to the user assigned to perform the audit activity.

Closed

A date-time stamp for when the audit activity was closed.

Closed by

A reference to the user who closed the record.

Short Description

A short description of the audit activity.

Description

A more detailed description of the audit activity.

Work Notes

A journal field for recording work performed on the audit activity.

Article Sources and Contributors

Article Sources and Contributors


IT Governance, Risk and Compliance Source: http://wiki.servicenow.com/index.php?oldid=70892 Contributors: Bbrooks, Bushra.akhtar, Cheryl.dolan, David.Bailey, Davida.hughes,
Emily.partridge, Guy.yedwab, Heidi.schnakenberg, Joseph.messerschmidt, Myla.jordan, Rachel.sienko, Ross.weir, Steve.wood, Suzannes, Wallymarx
Defining Authoritative Sources Source: http://wiki.servicenow.com/index.php?oldid=167263 Contributors: Emily.partridge, Guy.yedwab, Joseph.messerschmidt, Michael.randall,
Rachel.sienko
Managing Policies Source: http://wiki.servicenow.com/index.php?oldid=185217 Contributors: Emily.partridge, Guy.yedwab, Joseph.messerschmidt, Rachel.sienko, Steve.wood
Defining Risks Source: http://wiki.servicenow.com/index.php?oldid=185220 Contributors: Guy.yedwab, Joseph.messerschmidt, Michael.randall, Rachel.sienko, Ross.weir, Steve.wood
Managing Controls and Tests Source: http://wiki.servicenow.com/index.php?oldid=199285 Contributors: Cheryl.dolan, David.Bailey, Emily.partridge, Guy.yedwab, Heidi.schnakenberg,
Joseph.messerschmidt, Rachel.sienko, Ross.weir, Steve.wood
Managing Audits Source: http://wiki.servicenow.com/index.php?oldid=182685 Contributors: David.Bailey, Emily.partridge, Guy.yedwab, Joseph.messerschmidt, Rachel.sienko, Steve.wood

22

Image Sources, Licenses and Contributors

Image Sources, Licenses and Contributors


Image:GRC-app-w11s2.png Source: http://wiki.servicenow.com/index.php?title=File:GRC-app-w11s2.png License: unknown Contributors: Guy.yedwab, Steve.wood
Image:ITGRC.png Source: http://wiki.servicenow.com/index.php?title=File:ITGRC.png License: unknown Contributors: Guy.yedwab
Image:GRC-authsource.png Source: http://wiki.servicenow.com/index.php?title=File:GRC-authsource.png License: unknown Contributors: Guy.yedwab
Image:GRC-authsource2.png Source: http://wiki.servicenow.com/index.php?title=File:GRC-authsource2.png License: unknown Contributors: Guy.yedwab
Image:GRC-contenthierarchy.png Source: http://wiki.servicenow.com/index.php?title=File:GRC-contenthierarchy.png License: unknown Contributors: Guy.yedwab
Image:GRC-contenthierarchy2.png Source: http://wiki.servicenow.com/index.php?title=File:GRC-contenthierarchy2.png License: unknown Contributors: Guy.yedwab
Image:GRC-content-hierarchy3.png Source: http://wiki.servicenow.com/index.php?title=File:GRC-content-hierarchy3.png License: unknown Contributors: Guy.yedwab
Image:GRC-criteria.png Source: http://wiki.servicenow.com/index.php?title=File:GRC-criteria.png License: unknown Contributors: Guy.yedwab
Image:GRC-criteria.png2 Source: http://wiki.servicenow.com/index.php?title=File:GRC-criteria.png2 License: unknown Contributors: Guy.yedwab
Image:ITGRC-controlprocess.png Source: http://wiki.servicenow.com/index.php?title=File:ITGRC-controlprocess.png License: unknown Contributors: Guy.yedwab
File:IT_GRC_Control.png Source: http://wiki.servicenow.com/index.php?title=File:IT_GRC_Control.png License: unknown Contributors: Steve.wood
File:IT_GRC_Control_Test_Def.png Source: http://wiki.servicenow.com/index.php?title=File:IT_GRC_Control_Test_Def.png License: unknown Contributors: Steve.wood
Image:ITGRC_auditprocess.png Source: http://wiki.servicenow.com/index.php?title=File:ITGRC_auditprocess.png License: unknown Contributors: Guy.yedwab

23