GRC-Architecture

[MUSIC PLAYING]
SPEAKER: Organizations must successfully manage the complex regulatory requirements across their
industries. This video describes the robust GRC architecture and the ServiceNow components that
enable a successful integrated risk management program. These icons represent the major tables used
in the GRC suite and the relationships between them. Organizations are required to or choose to comply
with various external legislation and regulations.
These vary by geographic location and industry. One regulation that is important to many organizations is
the payment card industry, PCI, data security standard. This pertains to organizations that handle credit
card processing. The standard was created to increase controls around cardholder data to reduce credit
card fraud.
At ServiceNow, regulatory content is imported and maintained in the authority document table. Authority
documents are similar to a title page, which includes name, version, and publish date. The authority
document table could also contain other types of content, such as contractual obligations or an
international standard. The documents stored in the authority document table usually consist of
paragraphs describing activities an organization should do to remain compliant. These paragraphs are
called citations.
For example, a citation for PCI requires procedures for authorizing visitors before they enter areas where
cardholder data is maintained. The next set of tables are policies and control objectives, which are
structured similarly to authority documents. Just like the citation is a breakdown of the authority
document, control objectives are a breakdown of the policy. Policies help define company culture, such
as facility access, diversity, security, or sustainability. Some policies are driven by citations and ultimately
help the organization comply with regulations.
An organization's security policy might be driven by multiple regulations. But it represents what the
organization believes they need to do for security. Authority documents and citations catalog external
requirements on the organization. Policies and control objectives document how the organization is
addressing those requirements. There may also be some policies that are driven by the organization's
culture and not a specific regulation.
When a control objective is created, it should be related to the citations that it addresses. Many times, we
find that a control objective is related to multiple citations across multiple authority documents. The
organization will measure compliance to their control objectives. Because the control objective is related
to the citation, the compliance score will roll up to the related citations and authority documents. This
allows the company to measure once and satisfy many.
The next set of tables are risk frameworks and risk statements. Consider a risk framework as a group of
risk statements. A risk statement may be a parent or child to other risk statements. A risk statement helps
define the impact to the organization if the risk occurs. We have covered the primary tables used to set up
GRC. They determine which risks and controls organizations want to manage and what regulations
should be measured.
Next, are the entity type and entity tables. They represent the people, assets, business processes,
locations, or things that are used to manage controls and risks. Locations is an example of an entity type.
Each location is a unique entity. Vendors is another example of an entity type. Each vendor is a unique
entity. Every organization will define the entity types that are relevant to them. Some other common entity
types include business processes, departments, or applications.
Entity types are applied to risk statements and control objectives. When they are applied, additional
records are generated. A control or risk is generated for every entity, based on the control objective or
risk statement. This is called scoping. Control objectives and risk statements are scoped with entity types.
Consider the control objective to escort visitors within the facility. The control objective is scoped with the
entity type of locations.
Several controls are generated, one for each entity under the entity type of locations. The controls may
look like duplicates, however, each control is associated to a different entity. Risks are created in the
same way as controls. Risk and control owners are primarily responsible for monitoring and reviewing
risks and controls. They do this with the help of things like test plans, indicators, and issues.
Test plans are specific to controls and can be leveraged during audits. They determine if a control is
designed effectively and operating as expected. Test templates can be applied to a control objective if it is
relevant to multiple controls, creating more automation. Indicators are created to monitor the controls and
risks and collect evidence of performance. Indicators can either be manual, basic, or scripted. Indicator
templates can be used to create additional automation.
Issues can be associated with a control or a risk. Issues can be created manually or automatically for
various reasons. For example, if an indicator fails due to ineffective control performance or behavior, an
issue is automatically created. An organization can proactively follow up on the issue prior to it being
found during an audit. Additionally, there are assessments. Control attestations are administered on
controls to validate control implementation.
Risk assessments are administered on risks for evaluation and treatment. Specific to compliance, a
business user may request a policy exception to a control. Policy exceptions can also be related to other
elements, such as an issue or a control objective. Policy exceptions associated to a control objective or
control allow the control behavior to be exempt for a pre-defined period of time. Risk response tasks are
leveraged to either mitigate, avoid, transfer, or accept a risk.
Risk response tasks can be assigned, allowing the organization to track and manage the effort and to
determine how they are going to respond. We have reviewed the GRC architecture and tables related to
risk and compliance. The primary reason for compliance management is to reduce risk. Therefore,
organizations relate controls to risks to ensure visibility into the risk environment.
If there are 10 controls related to a risk and some are non-compliant, this could be considered when
assessing a risk. Control effectiveness enables risk managers to quickly identify areas of concern by
pinpointing entities with high known risk. Finally, we are ready to cover audit management. Audit allows
organizations to leverage the work done in the policy and compliance and risk management applications.
In an audit engagement, auditors select which entities they want to include. Notice they select entities and
not entity types. An IT audit may want to leverage entities for locations in California only. However, the
locations entity type has entities across the United States and would not be applicable for the audit. When
the audit is scoped with specific entities, the engagement pulls in all relationships established from policy
and compliance and risk.
Audit management has specific tables to capture audit tasks. Additionally, audit engagements leverage
test plans to pull in control test results. Control tests can be administered ad hoc for specific audit
engagements as well. The issues from risk and compliance are leveraged in audit. However, the audit
team can create more issues specific to findings observed in response to audit activities. Finally, the
organization has the ability to create an audit report to share their findings.
When organizations leverage the advanced audit application, additional features are available for
planning and conducting audits. Advanced audit features include audit plans, auditable units, milestones,
observations, along with project and portfolio management integration for resource planning. We have
reviewed how GRC architecture helps organizations remain compliant with regulations like PCI, all while
minimizing risks. Now, you are ready to learn more about creating a successful integrated risk
management program with ServiceNow.
[MUSIC PLAYING]