01 ServiceNow GRC

Large organizations rarely manage Governance, Risk, and Compliance using a single spreadsheet.

Enterprise GRC programs may need to manage:

Thousands of Controls

Hundreds of Policies

Multiple Regulations

Business Risks

Technology Risks

Audit Findings

Control Assessments

Evidence

Issues

Remediation Plans

Third Parties

Executive Reporting

Managing this manually becomes increasingly difficult as the organization grows.

Enterprise platforms such as ServiceNow Integrated Risk Management (IRM) help organizations bring these activities into a structured governance environment.

A simplified architecture looks like:

Regulations
      ↓
Policies
      ↓
Controls
      ↓
Entities
      ↓
Risks
      ↓
Assessments
      ↓
Evidence
      ↓
Issues
      ↓
Remediation
      ↓
Dashboards
      ↓
Executive Decisions

This lesson focuses on how a GRC professional should understand and work with ServiceNow’s risk and compliance capabilities rather than simply learning where buttons are located.

Learning Objectives

By the end of this lesson, you will be able to:

• Explain the role of ServiceNow in enterprise GRC.

• understand ServiceNow Integrated Risk Management.

• distinguish GRC processes from GRC technology.

• understand common ServiceNow IRM capabilities.

• understand the ServiceNow GRC data model conceptually.

• understand authority documents and regulatory requirements.

• understand policies and policy statements.

• understand control objectives and controls.

• understand entity and profile concepts.

• understand risk records.

• understand risk assessments.

• understand control assessments.

• understand indicators.

• understand issues and findings.

• understand remediation workflows.

• understand exception management.

• understand evidence management.

• understand audit-management integration.

• understand regulatory change workflows.

• understand continuous monitoring.

• understand dashboards and reporting.

• understand workflow automation.

• understand integrations.

• understand roles and responsibilities.

• design a practical GRC operating model using ServiceNow.

• identify common ServiceNow GRC implementation mistakes.

1. What Is ServiceNow?

ServiceNow is an enterprise workflow platform used by organizations to manage processes across areas such as:

IT Service Management

Security Operations

Risk Management

Compliance

Audit

Asset Management

Operations

Business Workflows

For GRC professionals, the important concept is:

ServiceNow provides workflow and data-management capabilities that can support an organization’s governance, risk, and compliance operating model.

2. ServiceNow GRC and IRM

You may hear organizations use terms such as:

ServiceNow GRC

ServiceNow IRM

Integrated Risk Management

The terminology and product packaging can evolve over time.

From a learning perspective, think of the platform as supporting interconnected processes involving:

Risk

Compliance

Policy

Controls

Audit

Issues

Indicators

Third Parties

Operational Resilience

depending on the organization’s licensed capabilities and implementation.

3. GRC Platform vs GRC Program

This distinction is extremely important.

GRC Program
      ↓
Governance Model
Risk Methodology
Control Framework
Policies
Processes
Ownership
Accountability

The platform supports the program.

It does not create a mature GRC program automatically.

Good GRC Program
+
Good Platform Configuration
=
Effective GRC Operations

4. What ServiceNow Helps Solve

Without a centralized platform:

Policies
→ SharePoint

Risks
→ Excel

Controls
→ Excel

Evidence
→ Email

Audit Findings
→ Documents

Remediation
→ Tickets

Compliance
→ Separate Spreadsheets

This creates:

Duplicate Data

Inconsistent Controls

Missing Ownership

Manual Follow-Up

Poor Traceability

Reporting Problems

Evidence Challenges

5. Centralized GRC Model

A ServiceNow-based environment can create relationships between:

Requirement
      ↓
Control Objective
      ↓
Control
      ↓
Entity
      ↓
Assessment
      ↓
Issue
      ↓
Remediation

This relationship model is one of the major advantages of enterprise GRC platforms.

6. Example

Suppose the organization must comply with:

PCI DSS

A requirement may require:

Multi-Factor
Authentication

The organization defines:

Enterprise MFA
Control Objective

The control applies to:

AWS

Azure

Microsoft 365

Corporate VPN

Testing identifies:

7 Administrator
Accounts Without MFA

The platform can connect:

PCI Requirement
      ↓
MFA Control
      ↓
Cloud Environment
      ↓
Assessment
      ↓
Failed Test
      ↓
Issue
      ↓
Remediation Task
      ↓
Control Retest

7. Core GRC Objects

Conceptually, expect to work with objects representing:

Authority Documents

Citations / Requirements

Policies

Policy Statements

Control Objectives

Controls

Entities

Risks

Assessments

Indicators

Issues

Remediation Tasks

Evidence

Audits

Exact terminology and relationships can vary depending on configuration and product version.

8. Authority Documents

An authority document represents an external or internal source of requirements.

Examples:

PCI DSS

ISO/IEC 27001

NIST CSF

SOC 2 Criteria

Internal Security Standard

Privacy Regulation

9. Requirement Structure

Conceptually:

Authority Document
      ↓
Requirement
      ↓
Control Objective
      ↓
Control

Example:

PCI DSS
      ↓
Access Control
Requirement
      ↓
Privileged Access
Control Objective
      ↓
Enterprise MFA
Control

10. Why Requirement Mapping Matters

Without mapping:

PCI Control

ISO Control

SOC 2 Control

Internal Control

may all represent essentially the same activity.

This creates:

Duplicate Testing

Duplicate Evidence

Duplicate Ownership

Duplicate Remediation

11. Common Control Framework

A mature organization may establish:

Enterprise
Common Control
Framework

Then map:

PCI DSS ───┐
           │
ISO 27001 ─┼──→ Enterprise Control
           │
SOC 2 ─────┤
           │
NIST ──────┘

12. Example Common Control

Enterprise control:

IAM-001

Multi-Factor Authentication
for Privileged Access

Mapped requirements:

PCI DSS

ISO 27001

SOC 2

Internal IAM Standard

Now the organization can potentially:

Test Once
      ↓
Reuse Assurance
      ↓
Report Across
Frameworks

where the assessment criteria and scope support that reuse.

13. Policy Management

Policies establish organizational expectations.

Examples:

Information Security Policy

Access Control Policy

Data Protection Policy

Third-Party Risk Policy

Acceptable Use Policy

14. Policy Lifecycle

A platform can support:

Draft
      ↓
Review
      ↓
Approval
      ↓
Publish
      ↓
Attestation
      ↓
Periodic Review
      ↓
Update
      ↓
Retire

15. Policy Ownership

Each policy should have:

Policy Owner

Approver

Review Frequency

Effective Date

Next Review Date

Version

16. Policy Statements

Large policies may contain specific statements that can be mapped to:

Requirements

Controls

Risks

Example:

Policy Statement:

All privileged accounts
must use multi-factor
authentication.

17. Control Objectives

A control objective describes:

What must be achieved?

Example:

Prevent Unauthorized
Privileged Access

18. Controls

A control describes:

What activity is performed to achieve the objective?

Example:

The identity platform
enforces MFA for all
privileged administrator
accounts.

19. Control Record

A useful control record may contain:

Control ID

Control Name

Description

Objective

Owner

Frequency

Type

Implementation

Applicability

Evidence

Assessment Status

20. Control Types

Controls may be classified as:

Preventive

Detective

Corrective

and:

Manual

Automated

IT-Dependent Manual

21. Control Ownership

Avoid:

Owner:
IT

Prefer:

Control Owner:
Director of IAM

Ownership should be assigned to someone capable of operating and maintaining the control.

22. Entities

Risk and controls must apply somewhere.

That “somewhere” may represent:

Business Unit

Application

Cloud Account

Legal Entity

Department

Location

Service

Technology Platform

23. Entity Example

Customer Payment Platform

may have:

Risks

Controls

Requirements

Assessments

Issues

associated with it.

24. Entity Hierarchy

Example:

Enterprise
      ↓
Technology Division
      ↓
Cloud Services
      ↓
AWS
      ↓
Production Account

Hierarchies help support:

Ownership

Scope

Risk Aggregation

Reporting

25. Profiles

Depending on the ServiceNow implementation and terminology used, profiles can represent objects or organizational components being assessed.

Conceptually:

Object Being
Governed
      ↓
Controls
Risks
Assessments

26. Risk Management

ServiceNow can support centralized:

Risk Identification

Risk Assessment

Risk Ownership

Risk Treatment

Risk Acceptance

Risk Monitoring

Risk Reporting

27. Risk Record

A useful risk record may contain:

Risk ID

Risk Statement

Category

Entity

Owner

Likelihood

Impact

Inherent Risk

Controls

Residual Risk

Treatment

Status

28. Example Risk

RISK-001

A threat actor may
compromise a privileged
cloud account and obtain
unauthorized access to
production systems,
resulting in data exposure
or service disruption.

29. Risk Assessment Workflow

Risk Identified
      ↓
Assign Owner
      ↓
Assess Likelihood
      ↓
Assess Impact
      ↓
Determine Inherent Risk
      ↓
Identify Controls
      ↓
Assess Controls
      ↓
Determine Residual Risk
      ↓
Compare With Appetite
      ↓
Treatment

30. Risk Scoring

An organization might use:

Likelihood
1–5

Impact
1–5

and calculate:

Risk Score
=
Likelihood × Impact

The methodology should be configured according to the organization’s approved risk framework.

31. Inherent Risk

Represents:

Risk Before
Considering Controls

32. Residual Risk

Represents:

Risk Remaining
After Considering
Controls

33. Risk Treatment

Common treatments include:

Avoid

Mitigate

Transfer / Share

Accept

34. Risk Acceptance

A structured workflow can capture:

Risk

Residual Rating

Acceptance Reason

Risk Owner

Approver

Acceptance Date

Review Date

Compensating Controls

35. Risk Register

The platform can become the organization’s centralized:

Enterprise
Risk Register

instead of maintaining separate spreadsheets across departments.

36. Compliance Management

Compliance management connects:

Authority Documents
      ↓
Requirements
      ↓
Control Objectives
      ↓
Controls
      ↓
Entities
      ↓
Assessments

37. Compliance Assessment

A compliance assessment asks:

Does the organization
meet the applicable
requirement?

38. Control Assessment

A control assessment asks:

Is the control
designed appropriately?

Is it implemented?

Does it operate
effectively?

39. Assessment Lifecycle

Assessment Created
      ↓
Assigned
      ↓
Questionnaire / Testing
      ↓
Evidence
      ↓
Review
      ↓
Exception
      ↓
Issue
      ↓
Remediation

40. Assessment Questions

Examples:

Is MFA enabled for
all privileged accounts?

Are access reviews
performed quarterly?

Are critical
vulnerabilities remediated
within required timelines?

41. Evidence

Evidence may include:

System Reports

Screenshots

Configuration Exports

Tickets

Approvals

Logs

Policies

Procedures

Assessment Documents

42. Evidence Traceability

A mature implementation should support:

Requirement
      ↓
Control
      ↓
Assessment
      ↓
Evidence
      ↓
Result

43. Example

PCI Requirement
      ↓
IAM-001
      ↓
Q2 Control Assessment
      ↓
MFA Configuration Export
      ↓
Effective

44. Evidence Reuse

A common control may support multiple requirements.

Therefore:

Evidence
      ↓
Control
      ↓
Multiple Frameworks

may reduce duplicate evidence requests.

45. Evidence Quality Still Matters

Uploading:

Screenshot.png

does not automatically prove compliance.

Evidence still needs to be:

Relevant

Reliable

Complete

Accurate

Current

46. Indicators

Indicators can help continuously evaluate:

Risk

Control Performance

Compliance Conditions

47. Example Indicator

Control:

MFA Required for
Administrators

Indicator:

Percentage of
Administrator Accounts
With MFA Enabled

48. Indicator Calculation

Admins With MFA
──────────────── × 100
Total Admins

Example:

243
─── × 100
250

Result:

97.2%

49. Indicator Threshold

Example:

100%
=
Compliant

98–99.9%
=
Warning

Below 98%
=
Failure

Thresholds should follow organizational requirements rather than arbitrary defaults.

50. Continuous Monitoring

Traditional assessment:

Annual Test
      ↓
Point-in-Time
Result

Continuous monitoring:

System
      ↓
Data
      ↓
Indicator
      ↓
Threshold
      ↓
Exception
      ↓
Issue

51. Continuous Compliance Example

Cloud configuration data may continuously evaluate:

Encryption Enabled?

Logging Enabled?

MFA Enabled?

Public Exposure?

Backup Enabled?

52. Automated Control Monitoring

Example:

Cloud Platform
      ↓
Integration
      ↓
Configuration Data
      ↓
ServiceNow Indicator
      ↓
Control Status

53. Issues

When assessments identify deficiencies, create:

Issue

rather than leaving the problem buried inside:

Assessment Notes

54. Issue Record

A useful issue record may include:

Issue ID

Control

Risk

Entity

Condition

Impact

Severity

Root Cause

Owner

Due Date

Status

Remediation Plan

55. Example Issue

ISSUE-001

Seven privileged
administrator accounts
do not have MFA enabled.

Related:

Risk:
Privileged Account
Compromise

Control:
IAM-001

Entity:
Production Cloud

56. Issue Workflow

Issue Identified
      ↓
Validate
      ↓
Risk Rate
      ↓
Assign Owner
      ↓
Remediation Plan
      ↓
Implementation
      ↓
Retest
      ↓
Closure

57. Remediation Task

The issue may generate specific tasks.

Example:

Issue
      ↓
Enable MFA
for 7 Accounts

Owner:

IAM Operations

Due:

15 Days

58. Root Cause

The platform should capture more than:

MFA Missing

Possible root cause:

Privileged accounts
created through legacy
provisioning workflow
bypassed the standard
MFA enforcement policy.

59. Corrective Action

Weak:

Enable MFA
for 7 Accounts

Better:

Enable MFA
for 7 Accounts
+
Update Provisioning
Workflow
+
Implement Automated
MFA Coverage Monitoring

60. Retesting

Issue closure should ideally follow:

Remediation
      ↓
Evidence
      ↓
Retest
      ↓
Closure

rather than:

Owner Says
Fixed
      ↓
Close

61. Exception Management

Organizations sometimes cannot meet a requirement immediately.

Example:

Legacy Application
Cannot Support MFA

An exception workflow may capture:

Requirement

Business Reason

Risk

Compensating Controls

Approver

Start Date

Expiry Date

Review

62. Exception Is Not Permanent Compliance

An approved exception means:

Known Risk
+
Authorized Decision

not:

Requirement
No Longer Matters

63. Exception Expiration

Configure:

Expiry Date
      ↓
Notification
      ↓
Reassessment
      ↓
Renew / Remediate

64. Audit Management

Audit activities may include:

Audit Universe

Audit Planning

Engagements

Audit Testing

Findings

Remediation

Reporting

65. Audit and Compliance Integration

Example:

Compliance Control
      ↓
Audit Test
      ↓
Finding
      ↓
Issue
      ↓
Remediation

This helps avoid isolated:

Audit Findings Spreadsheet

66. Audit Evidence

Auditors may leverage existing:

Control Records

Assessment Results

Evidence

Risk Records

Previous Findings

subject to audit requirements and evidence sufficiency.

67. Regulatory Change

Organizations may need to monitor:

New Regulations

Updated Standards

Changed Requirements

New Guidance

68. Regulatory Change Workflow

Conceptually:

Regulatory Change
      ↓
Impact Analysis
      ↓
Applicable Requirements
      ↓
Policies
      ↓
Controls
      ↓
Gap Assessment
      ↓
Remediation

69. Example

New requirement:

Stronger Authentication
Requirement

Impact analysis identifies:

IAM Policy

MFA Control

Cloud Platforms

VPN

Legacy Applications

70. Workflow Automation

One major advantage of ServiceNow is workflow.

Instead of:

Email Control Owner

Wait

Send Reminder

Wait

Escalate Manually

use:

Assessment Assigned
      ↓
Notification
      ↓
Due Date
      ↓
Reminder
      ↓
Escalation
      ↓
Completion

71. Example Assessment Workflow

Assessment Created
      ↓
Control Owner
      ↓
Evidence Submitted
      ↓
GRC Review
      ↓
Pass / Exception
      ↓
Issue
      ↓
Remediation

72. Approval Workflow

Risk acceptance may require:

Risk Owner
      ↓
Security
      ↓
Compliance
      ↓
Executive Approval

depending on severity and organizational policy.

73. SLA Management

Examples:

Critical Issue:
15 Days

High:
30 Days

Medium:
90 Days

The platform can track:

Due

Approaching Due

Overdue

74. Notifications

Notifications can support:

Assessment Due

Policy Review Due

Evidence Required

Risk Review Due

Issue Overdue

Exception Expiring

75. Escalation

Example:

Issue Due
      ↓
Reminder
      ↓
Overdue
      ↓
Manager
      ↓
Risk Committee

76. Dashboards

Dashboards convert GRC records into:

Management
Information

77. Risk Dashboard

May display:

Critical Risks

High Risks

Risks Above Appetite

Risk Trend

Overdue Treatments

Accepted Risks

78. Compliance Dashboard

May display:

Requirements

Compliant Controls

Failed Controls

Open Assessments

Evidence Outstanding

Compliance Score

79. Issue Dashboard

May display:

Open Issues

Critical Issues

Overdue Issues

Issues by Owner

Issues by Business Unit

Remediation Trend

80. Control Dashboard

May display:

Controls

Effective

Partially Effective

Ineffective

Not Assessed

Assessment Due

81. Executive Dashboard

Executives usually need:

Top Risks

Compliance Posture

Critical Control Failures

Overdue Remediation

Risk Trend

Major Regulatory Exposure

not thousands of individual control records.

82. Dashboard Drill-Down

A useful dashboard should allow:

Enterprise
      ↓
Business Unit
      ↓
Entity
      ↓
Risk / Control
      ↓
Assessment
      ↓
Issue

83. Integrations

A GRC platform becomes more valuable when integrated with authoritative systems.

Examples:

Identity Platforms

Vulnerability Scanners

Cloud Platforms

CMDB

Security Tools

HR Systems

Ticketing Systems

Asset Management

84. CMDB Integration

ServiceNow’s broader platform capabilities can make configuration and asset information useful to risk and compliance processes.

Conceptually:

Business Service
      ↓
Application
      ↓
Infrastructure
      ↓
Risk
      ↓
Control

85. Example CMDB Relationship

Online Banking
      ↓
Payment Application
      ↓
Production Database
      ↓
Cloud Infrastructure

If a critical vulnerability affects the infrastructure, the organization can better understand:

Business Impact

86. Vulnerability Integration

Conceptually:

Scanner
      ↓
Vulnerability Data
      ↓
Affected Assets
      ↓
Risk / Indicator
      ↓
Issue

87. IAM Integration

Identity Platform
      ↓
Account Population
      ↓
MFA Status
      ↓
Control Indicator
      ↓
Exception

88. Cloud Integration

Cloud data may support monitoring of:

Encryption

Logging

Public Access

Identity

Backup

Configuration

89. API-Based Integration

Enterprise GRC programs may use APIs to:

Import Evidence

Update Indicators

Create Issues

Synchronize Assets

Update Risk Data

90. Automation Principle

Do not automate:

Bad Process

A poorly designed workflow becomes:

Automated
Bad Process

First establish:

Governance
      ↓
Process
      ↓
Ownership
      ↓
Data Model
      ↓
Automation

91. Roles

Typical roles may include:

GRC Analyst

Risk Manager

Compliance Manager

Control Owner

Risk Owner

Policy Owner

Internal Auditor

Issue Owner

Platform Administrator

92. GRC Analyst

May perform:

Requirement Mapping

Control Assessments

Evidence Review

Issue Management

Reporting

Compliance Monitoring

93. Risk Manager

May manage:

Risk Methodology

Risk Register

Risk Assessments

Risk Acceptance

Risk Reporting

94. Compliance Manager

May manage:

Regulatory Requirements

Control Framework

Compliance Assessments

Compliance Reporting

95. Control Owner

Responsible for:

Operating Control

Providing Evidence

Responding to Assessment

Remediating Deficiencies

96. Risk Owner

Responsible for:

Understanding Risk

Treatment Decisions

Risk Acceptance

Monitoring

97. Platform Administrator

Responsible for areas such as:

Configuration

Access

Workflows

Forms

Integrations

Platform Maintenance

The GRC team should not automatically become responsible for all platform administration.

98. Segregation of Duties

Avoid giving one person uncontrolled ability to:

Own Control

Test Control

Approve Result

Close Issue

where independent assurance is required.

99. Access Control

ServiceNow itself may contain:

Risk Information

Audit Findings

Security Weaknesses

Personal Information

Evidence

Regulatory Information

Therefore platform access should follow:

Least Privilege

100. GRC Data Quality

Poor data produces poor reporting.

Bad Data
      ↓
Bad Dashboard
      ↓
Bad Decision

101. Common Data Problems

Duplicate Controls

Missing Owners

Old Risks

Expired Assessments

Incorrect Entities

Duplicate Issues

Missing Relationships

102. Data Governance

Define ownership for:

Controls

Risks

Policies

Entities

Requirements

Issues

Evidence

103. Naming Standards

Example:

IAM-001
Privileged MFA

IAM-002
Quarterly Access Review

VM-001
Critical Vulnerability
Remediation

rather than:

MFA Control New

MFA Final

MFA Control 2

104. Control Rationalization

Before loading controls:

Collect
      ↓
Compare
      ↓
Remove Duplicates
      ↓
Standardize
      ↓
Map

105. Example

Existing:

PCI MFA Control

ISO MFA Control

SOC MFA Control

AWS MFA Control

Rationalized:

IAM-001
Enterprise Privileged
MFA Control

mapped appropriately across requirements and applicable entities.

106. Do Not Start With Tool Configuration

A weak implementation starts:

Install Platform
      ↓
Create Forms
      ↓
Import Spreadsheets

A stronger implementation starts:

Understand
GRC Operating Model
      ↓
Define Taxonomy
      ↓
Define Ownership
      ↓
Define Framework
      ↓
Rationalize Controls
      ↓
Define Workflows
      ↓
Configure Platform

107. GRC Operating Model

Before implementation define:

Who Owns Risk?

Who Owns Controls?

Who Tests Controls?

Who Approves Risk?

Who Creates Issues?

Who Closes Issues?

Who Reports to Leadership?

108. Risk Taxonomy

Example:

Enterprise Risk
      ↓
Technology
      ↓
Cybersecurity
      ↓
Identity & Access

109. Control Taxonomy

Example:

Security Controls
      ↓
Identity
      ↓
Privileged Access
      ↓
MFA

110. Entity Taxonomy

Example:

Enterprise
      ↓
Business Unit
      ↓
Business Service
      ↓
Application
      ↓
Technology

111. Issue Taxonomy

Example:

Control Deficiency

Audit Finding

Compliance Gap

Risk Treatment Issue

Policy Exception

112. Workflow Governance

For every workflow define:

Trigger

Owner

Reviewer

Approver

SLA

Escalation

Closure Criteria

113. Example — Control Assessment

Trigger:
Quarterly Schedule

Owner:
Control Owner

Reviewer:
GRC Analyst

SLA:
10 Business Days

Escalation:
Owner's Manager

Closure:
Evidence Accepted

114. Example — Risk Acceptance

Residual Risk:
High

Approver:
CISO

Expiry:
6 Months

Review:
Before Expiry

Actual approval thresholds should follow organizational policy.

115. ServiceNow Implementation Phases

A practical implementation can follow:

Phase 1
Governance

Phase 2
Data Model

Phase 3
Controls

Phase 4
Risk

Phase 5
Compliance

Phase 6
Assessments

Phase 7
Issues

Phase 8
Reporting

Phase 9
Integrations

Phase 10
Automation

116. Phase 1 — Governance

Define:

Objectives

Scope

Stakeholders

Roles

Decision Rights

Operating Model

117. Phase 2 — Data Model

Define:

Entities

Taxonomies

Relationships

Naming Standards

Ownership

118. Phase 3 — Controls

Develop:

Common Control Framework

Control Owners

Control Frequencies

Control Mapping

119. Phase 4 — Risk

Configure:

Risk Taxonomy

Likelihood

Impact

Scoring

Risk Appetite

Treatment

120. Phase 5 — Compliance

Load applicable:

Authority Documents

Requirements

Mappings

Policies

121. Phase 6 — Assessments

Define:

Assessment Types

Questions

Testing Procedures

Evidence Requirements

Frequency

122. Phase 7 — Issues

Configure:

Severity

Ownership

SLA

Remediation

Escalation

Closure

123. Phase 8 — Reporting

Develop reporting for:

Operational Teams

GRC Management

Risk Committees

Executives

Board

124. Phase 9 — Integrations

Prioritize systems that provide:

Authoritative

Repeatable

High-Value

data.

125. Phase 10 — Automation

Automate:

Assessments

Notifications

Indicators

Evidence Collection

Issue Creation

Escalation

Reporting

after the processes are stable.

126. Common Implementation Mistake — Lift and Shift

Organization has:

15 GRC Spreadsheets

and simply imports everything.

Result:

15 Bad Processes
Inside ServiceNow

127. Better Approach

Review
      ↓
Rationalize
      ↓
Standardize
      ↓
Simplify
      ↓
Configure

128. Common Mistake — Too Many Controls

Example:

8,000 Controls

because each regulatory requirement becomes a separate control.

This can create:

Assessment Fatigue

Duplicate Evidence

Duplicate Testing

Poor Ownership

129. Better Approach — Common Controls

Requirements
      ↓
Common Controls
      ↓
Applicability
      ↓
Assessment

130. Common Mistake — No Entity Model

Controls exist but nobody knows:

Where Do
They Apply?

131. Better Entity Mapping

Control
      ↓
Business Unit
Application
Cloud Account
Service

132. Common Mistake — No Ownership

Records assigned to:

Cybersecurity Team

instead of specific accountable individuals.

133. Common Mistake — Too Much Customization

Excessive customization can create:

Complexity

Maintenance

Upgrade Challenges

User Confusion

Prefer configuration aligned with genuine business requirements.

134. Common Mistake — Dashboard First

Building attractive dashboards before fixing:

Data Quality

produces:

Beautiful
Incorrect Reporting

135. Common Mistake — Compliance Score Obsession

A dashboard may show:

98% Compliant

but the remaining:

2%

could include critical control failures.

Always consider:

Risk
+
Compliance

136. Common Mistake — Closing Issues Without Retesting

Owner:
Fixed

GRC:
Closed

is weak assurance.

Prefer:

Remediation
      ↓
Evidence
      ↓
Retest
      ↓
Closure

137. Common Mistake — Evidence Dump

Users upload:

500 Files

without mapping them to:

Control

Assessment

Period

Requirement

138. Better Evidence Governance

Evidence ID
      ↓
Control
      ↓
Assessment
      ↓
Period
      ↓
Result

139. Common Mistake — Automating Everything

Not every GRC decision should be automated.

Human judgment remains important for:

Risk Acceptance

Control Conclusions

Material Findings

Regulatory Interpretation

Executive Decisions

140. Example End-to-End Workflow

Requirement:

Privileged Accounts
Require MFA

Map to:

IAM-001
Enterprise Privileged
MFA Control

Apply to:

Production AWS

Assessment:

250 Admin Accounts

Evidence:

MFA Status Export

Result:

243 Enabled

7 Disabled

Then:

Control Assessment
      ↓
Exception
      ↓
Issue
      ↓
Risk Evaluation
      ↓
Remediation
      ↓
MFA Enabled
      ↓
Retest
      ↓
Closure

141. ServiceNow GRC Operational Checklist

Governance

• GRC operating model defined.

• stakeholders identified.

• roles established.

• decision rights established.

• platform ownership established.

Data Model

• entity hierarchy defined.

• risk taxonomy defined.

• control taxonomy defined.

• issue taxonomy defined.

• naming standards established.

• data owners identified.

Requirements

• authority documents identified.

• requirements loaded.

• applicability determined.

• requirement ownership established.

• mappings validated.

Controls

• common controls established.

• duplicate controls rationalized.

• control owners assigned.

• control frequency defined.

• control type defined.

• applicability mapped.

• evidence requirements defined.

Risk

• risk taxonomy configured.

• scoring methodology established.

• inherent risk defined.

• residual risk defined.

• appetite established.

• treatment workflow defined.

• acceptance workflow established.

Assessments

• assessment methodology defined.

• control assessments configured.

• evidence requirements established.

• assessment frequency defined.

• reviewers assigned.

• exception process established.

Issues

• issue severity defined.

• issue ownership defined.

• remediation workflow configured.

• SLA established.

• escalation established.

• retesting required.

• closure criteria established.

Evidence

• evidence naming established.

• evidence mapped to controls.

• assessment period recorded.

• sensitive evidence protected.

• retention requirements defined.

• evidence quality validated.

Automation

• reminders automated.

• escalation automated.

• recurring assessments scheduled.

• indicators configured.

• evidence integrations evaluated.

• issue creation automated where appropriate.

Reporting

• operational dashboards created.

• risk dashboards created.

• compliance dashboards created.

• issue dashboards created.

• executive reporting created.

• data-quality monitoring established.

ServiceNow GRC Deliverables

After completing this lesson, you should be able to design:

01 GRC Operating Model

02 ServiceNow GRC Data Model

03 Entity Hierarchy

04 Risk Taxonomy

05 Control Taxonomy

06 Common Control Framework

07 Requirement Mapping Matrix

08 Control Assessment Workflow

09 Risk Assessment Workflow

10 Issue Management Workflow

11 Evidence Management Model

12 GRC Dashboard Design

13 GRC Integration Map

14 ServiceNow GRC Implementation Roadmap

Practical Activity — Build a ServiceNow GRC Model

Scenario:

Your organization operates:

Customer SaaS Platform

using:

AWS

Microsoft 365

Corporate Identity Platform

The organization must support:

ISO 27001

SOC 2

PCI DSS

Your task is to design:

Authority Documents

Requirements

Common Controls

Entities

Risks

Assessments

Evidence

Indicators

Issues

Dashboards

Practical Activity — Common Control Mapping

Create:

IAM-001
Privileged MFA

Map it conceptually to applicable:

PCI DSS

ISO 27001

SOC 2

Internal IAM Policy

Then identify:

Control Owner

Entities

Assessment Frequency

Evidence

Indicator

Exception Process

Practical Activity — Risk Workflow

Risk:

Privileged Cloud
Account Compromise

Create:

Risk Statement

Risk Owner

Inherent Likelihood

Inherent Impact

Existing Controls

Residual Risk

Treatment

KRI

Practical Activity — Control Assessment

Control:

All privileged
administrator accounts
must use MFA.

Population:

250 Accounts

Evidence:

Identity Platform
MFA Export

Result:

243 Pass

7 Fail

Determine:

Assessment Result

Issue

Severity

Owner

Remediation

Retesting

Closure Evidence

Practical Activity — Issue Workflow

Issue:

7 Production
Administrators
Without MFA

Design:

Issue Creation
      ↓
Assignment
      ↓
Risk Evaluation
      ↓
Remediation
      ↓
Evidence
      ↓
Retest
      ↓
Closure

Practical Activity — GRC Dashboard

Design a dashboard containing:

Top Enterprise Risks

Controls Tested

Failed Controls

Open Compliance Gaps

Critical Issues

Overdue Remediation

Risk Acceptances

Expiring Exceptions

Compliance Trend

ServiceNow GRC Mindset

When working with ServiceNow GRC, ask:

What Business
Problem Are
We Solving?

What Regulations
Apply?

What Requirements
Must Be Met?

Can Requirements
Map to Common
Controls?

What Are
Our Entities?

Where Does
Each Control Apply?

Who Owns
the Control?

Who Owns
the Risk?

How Will
Controls Be
Assessed?

What Evidence
Is Required?

Can Evidence
Be Automated?

How Do We
Validate Evidence?

What Happens
When a Control
Fails?

When Does
an Exception
Become an Issue?

Who Owns
Remediation?

What Is
the SLA?

Who Escalates
Overdue Issues?

How Is
Remediation Retested?

When Can
an Issue Close?

What Indicators
Should Be
Continuous?

Which Systems
Should Integrate?

What Does
Management Need
to See?

What Does
the Board Need
to See?

Is Our
Data Reliable?

Are We
Automating a
Good Process?

Does the Platform
Reflect Our
Governance Model?

That is the mindset of a GRC professional using an enterprise GRC platform.

Key Takeaways

• ServiceNow can provide a centralized platform for enterprise governance, risk, compliance, audit, issue, and remediation workflows.

• ServiceNow GRC is commonly discussed in the context of Integrated Risk Management.

• A GRC platform supports a GRC program; it does not replace governance, methodology, ownership, or professional judgment.

• Authority documents and requirements can be mapped to organizational controls.

• Common controls can reduce duplicate testing and evidence collection across multiple frameworks.

• Policies, policy statements, control objectives, controls, entities, risks, assessments, evidence, and issues should be connected through a structured data model.

• Entity hierarchies help determine where risks and controls apply.

• Risk workflows should support inherent risk, control consideration, residual risk, treatment, acceptance, and monitoring.

• Control assessments should evaluate design, implementation, and operating effectiveness.

• Evidence must still be validated even when managed through a GRC platform.

• Indicators can support continuous risk and control monitoring.

• Control failures should flow into structured issue and remediation workflows.

• Issue closure should require appropriate evidence and retesting.

• Exceptions should have owners, approvals, compensating controls, and expiry dates.

• Workflow automation can improve reminders, escalation, assessments, and remediation tracking.

• Integrations can reduce manual evidence collection and improve continuous monitoring.

• CMDB and asset relationships can provide important business context for risk.

• Dashboards should support decisions rather than simply display large amounts of GRC data.

• Data quality is fundamental to trustworthy GRC reporting.

• Organizations should rationalize controls before migrating them into a GRC platform.

• Excessive customization can increase platform complexity and maintenance.

• GRC automation should follow mature processes rather than automate poorly designed workflows.

• Strong ServiceNow implementations begin with governance, taxonomy, ownership, control frameworks, and workflows before technical configuration.

Knowledge Check

Before continuing, make sure you can answer:

1. What role does ServiceNow play in enterprise GRC?

2. What is Integrated Risk Management?

3. Why does a GRC platform not replace a GRC program?

4. What is an authority document?

5. How are requirements related to controls?

6. What is a common control framework?

7. Why can common controls reduce compliance effort?

8. What is the difference between a control objective and control?

9. What role do entities play in GRC?

10. What information should a risk record contain?

11. What is inherent risk?

12. What is residual risk?

13. What are common risk-treatment options?

14. What is a control assessment?

15. How should evidence be connected to controls?

16. What is an indicator?

17. How can indicators support continuous compliance?

18. What should happen when a control assessment identifies a deficiency?

19. What should an issue record contain?

20. Why should remediation be retested?

21. What is a policy exception?

22. Why should exceptions expire?

23. How can audit and compliance processes be integrated?

24. What is regulatory change management?

25. How can workflow automation improve GRC operations?

26. What GRC activities can be supported by integrations?

27. Why can CMDB information be valuable for GRC?

28. Why is GRC data quality important?

29. Why should controls be rationalized before migration?

30. What is wrong with simply importing existing GRC spreadsheets?

31. Why can excessive customization become problematic?

32. Why can compliance percentages be misleading?

33. Why should evidence automation still be validated?

34. What should be defined before configuring a GRC platform?

35. What should an executive GRC dashboard communicate?

What’s Next?

➡️ Next: 02 — Microsoft Purview

In the next lesson, you will move from an enterprise-wide GRC workflow platform into Microsoft’s data governance, information protection, privacy, compliance, and risk capabilities.

You will explore how Microsoft Purview can help organizations work with:

Enterprise Data
      ↓
Discover
      ↓
Classify
      ↓
Protect
      ↓
Apply Policies
      ↓
Monitor
      ↓
Investigate
      ↓
Demonstrate Compliance

You will learn about data classification, sensitivity labels, Data Loss Prevention, retention, records management, eDiscovery, audit, insider risk capabilities, information protection, data governance, compliance workflows, and reporting, and how these capabilities fit into an enterprise GRC and data-protection operating model.