04 RSA Archer

Large enterprises rarely manage Governance, Risk and Compliance through a single spreadsheet.

A mature GRC program may need to manage:

Thousands of Risks

Thousands of Controls

Hundreds of Policies

Multiple Regulations

Internal Audits

External Audits

Third Parties

Control Assessments

Risk Assessments

Exceptions

Findings

Remediation Plans

Evidence

Executive Reporting

As the organization grows, managing these activities through spreadsheets, email, documents, and shared folders becomes increasingly difficult.

A GRC platform provides a centralized environment for managing these relationships.

RSA Archer is an enterprise GRC platform designed to support areas such as:

Enterprise Risk Management

Operational Risk

Compliance Management

Policy Management

Control Management

Audit Management

Issue Management

Third-Party Risk

Business Continuity

Security Risk

Reporting

For a GRC professional, the most important concept is not learning where every button exists.

You need to understand the operating model:

Requirement
      ↓
Control
      ↓
Asset / Process
      ↓
Risk
      ↓
Assessment
      ↓
Evidence
      ↓
Finding
      ↓
Remediation
      ↓
Monitoring
      ↓
Reporting

Learning Objectives

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

• Explain the purpose of RSA Archer.

• understand enterprise GRC platforms.

• understand Archer’s information model.

• understand GRC records and relationships.

• understand risk registers.

• understand inherent and residual risk.

• understand control libraries.

• understand control ownership.

• understand compliance management.

• understand regulatory requirement mapping.

• understand policy management.

• understand risk assessments.

• understand control assessments.

• understand evidence management.

• understand issue and finding management.

• understand remediation workflows.

• understand exception management.

• understand audit management.

• understand third-party risk integration.

• understand workflow automation.

• understand notifications and approvals.

• understand role-based access.

• understand dashboards and reports.

• understand KRIs and KPIs.

• understand data quality requirements.

• understand GRC platform governance.

• design an integrated Archer operating model.

1. What Is RSA Archer?

RSA Archer is an enterprise Governance, Risk and Compliance platform.

It can provide a structured system for managing interconnected GRC information.

Instead of maintaining:

Risk.xlsx

Controls.xlsx

Audit-Findings.xlsx

PCI-Evidence.xlsx

Vendor-Risk.xlsx

Exceptions.xlsx

organizations can establish structured relationships such as:

Business Unit
      ↓
Business Process
      ↓
Application
      ↓
Risk
      ↓
Control
      ↓
Requirement
      ↓
Assessment
      ↓
Finding

This creates a more integrated GRC environment.

2. Why Organizations Use GRC Platforms

Consider a multinational organization with:

50 Business Units

2,000 Applications

15,000 Controls

5,000 Vendors

25 Regulatory Frameworks

Hundreds of Audits

Spreadsheet-based GRC quickly becomes difficult to manage.

Common problems include:

Duplicate Controls

Duplicate Risks

Outdated Evidence

Missing Owners

Inconsistent Ratings

Missed Deadlines

Broken Traceability

Manual Reporting

A GRC platform helps provide:

Centralization

Standardization

Workflow

Accountability

Traceability

Automation

Reporting

3. The Archer Information Model

A fundamental concept in Archer is that GRC information exists as interconnected records.

Conceptually:

Organization
      ↓
Business Unit
      ↓
Business Process
      ↓
Asset
      ↓
Risk
      ↓
Control
      ↓
Requirement
      ↓
Assessment
      ↓
Issue

This relationship model is extremely important.

4. Why Relationships Matter

Suppose a vulnerability affects:

Payment Application

That application supports:

Payment Processing

which contains:

Cardholder Data

and is subject to:

PCI DSS

The platform can conceptually connect:

Vulnerability
      ↓
Application
      ↓
Business Process
      ↓
Risk
      ↓
Control
      ↓
PCI Requirement

This enables meaningful risk and compliance analysis.

5. GRC Records

Common record types may represent:

Risks

Controls

Policies

Requirements

Assets

Processes

Applications

Vendors

Assessments

Findings

Issues

Remediation Plans

Each record contains structured information.

6. Example Risk Record

Risk ID:
RISK-001

Title:
Unauthorized Access to Customer Data

Category:
Cybersecurity

Owner:
Customer Platform Director

Likelihood:
Possible

Impact:
Major

Inherent Risk:
High

Control Effectiveness:
Moderate

Residual Risk:
Medium

7. Risk Register

A risk register provides a centralized inventory of organizational risks.

Example:

Risk ID	Risk	Owner	Inherent	Residual
R-001	Data Breach	CISO	Critical	High
R-002	Cloud Outage	CIO	High	Medium
R-003	Vendor Failure	Procurement	High	Medium
R-004	Regulatory Breach	Compliance	Critical	Medium

8. Risk Taxonomy

Organizations should establish consistent risk categories.

Example:

Enterprise Risk
├── Strategic
├── Operational
├── Cybersecurity
├── Technology
├── Compliance
├── Privacy
├── Financial
└── Third-Party

Without taxonomy, reporting becomes inconsistent.

9. Risk Identification

Risks may originate from:

Risk Assessments

Audits

Security Findings

Incidents

Regulatory Changes

Vendor Assessments

Management Reviews

Threat Intelligence

10. Inherent Risk

Inherent risk represents risk:

Before considering controls.

Conceptually:

Threat
      +
Vulnerability
      +
Business Impact
      ↓
Inherent Risk

11. Example

Scenario:

Internet-Facing
Payment Application

Processes:

Cardholder Data

Potential breach impact:

Financial Loss

Regulatory Impact

Customer Impact

Reputation Damage

Inherent risk:

Critical

12. Controls

Controls reduce risk.

Examples:

MFA

Encryption

Network Segmentation

Logging

Vulnerability Management

Access Reviews

13. Residual Risk

Residual risk represents risk remaining after considering controls.

Inherent Risk
      ↓
Controls
      ↓
Control Effectiveness
      ↓
Residual Risk

14. Example

Inherent Risk
Critical

Controls
Strong

Residual Risk
Medium

Management then determines whether:

Medium Risk

is acceptable.

15. Risk Treatment

Common treatment strategies:

Mitigate

Accept

Avoid

Transfer

16. Risk Acceptance

Risk acceptance should normally include:

Risk

Business Impact

Residual Rating

Justification

Risk Owner

Approval

Review Date

17. Risk Ownership

A critical GRC principle:

GRC Team
      ≠
Risk Owner

The GRC team facilitates risk management.

Business leadership generally owns business risk according to the organization’s governance model.

18. Control Library

Organizations often maintain an enterprise control library.

Example:

IAM-001
Privileged MFA

IAM-002
Quarterly Access Review

NET-001
Network Segmentation

LOG-001
Security Logging

VM-001
Vulnerability Remediation

DAT-001
Data Classification

19. Why a Common Control Library?

Without one:

PCI Control 1

ISO Control 47

SOC Control 22

Internal Control 81

may all represent essentially the same requirement.

This creates duplication.

20. Common Control Framework

Better:

Enterprise Control
      ↓
IAM-001
Privileged MFA

mapped to:

PCI DSS

ISO 27001

SOC 2

NIST

Internal Policy

21. Many-to-Many Mapping

One control can support multiple requirements.

                PCI DSS
                   ↑
                   |
ISO 27001 ← IAM-001 → SOC 2
                   |
                   ↓
                 NIST

This is one of the major benefits of an integrated GRC platform.

22. Control Record

Example:

Control ID:
IAM-001

Control:
Privileged accounts must use MFA.

Owner:
IAM Manager

Frequency:
Continuous

Type:
Preventive

Automation:
Automated

Evidence:
Identity Configuration

23. Control Types

Controls may be categorized as:

Preventive

Detective

Corrective

Directive

They may also be:

Manual

Automated

Hybrid

24. Control Ownership

Every control should have a clear owner responsible for:

Implementation

Operation

Evidence

Remediation

Periodic Review

25. Control Assessment

A control assessment evaluates whether a control:

Exists

Is Properly Designed

Is Implemented

Operates Effectively

26. Design Effectiveness

Question:

If this control operates as designed, can it reasonably address the identified risk or requirement?

27. Operating Effectiveness

Question:

Did the control actually operate as expected during the assessment period?

These are different concepts.

28. Control Assessment Workflow

Control
      ↓
Assessment
      ↓
Evidence
      ↓
Testing
      ↓
Conclusion
      ↓
Finding

29. Assessment Result

Example:

Effective

Partially Effective

Ineffective

Not Applicable

Not Tested

Organizations should define their own approved assessment vocabulary.

30. Evidence Management

Evidence can include:

Policies

Procedures

Configurations

System Reports

Logs

Screenshots

Tickets

Meeting Records

Assessment Results

31. Evidence Record

Example:

Evidence ID:
EVD-2026-001

Control:
IAM-001

Type:
System Report

Period:
Q2 2026

Owner:
IAM Operations

Source:
Identity Platform

Status:
Validated

32. Evidence Traceability

Good traceability:

Requirement
      ↓
Control
      ↓
Assessment
      ↓
Evidence
      ↓
Test Result

33. Compliance Management

Archer can support structured compliance programs involving:

Regulations

Standards

Requirements

Controls

Assessments

Evidence

Findings

34. Compliance Hierarchy

Conceptually:

Framework
      ↓
Domain
      ↓
Requirement
      ↓
Control
      ↓
Assessment

35. Example — PCI DSS

PCI DSS
      ↓
Requirement
      ↓
Access Control
      ↓
IAM-001
      ↓
MFA Evidence
      ↓
Assessment

36. Multiple Frameworks

The same organization may manage:

PCI DSS

SOC 2

ISO 27001

Privacy Requirements

Internal Policies

Contractual Requirements

A GRC platform helps prevent each program from becoming an isolated compliance silo.

37. Regulatory Mapping

Conceptually:

Regulatory Requirement
      ↓
Enterprise Control
      ↓
Implementation
      ↓
Evidence

38. Policy Management

Policies establish organizational expectations.

Examples:

Information Security Policy

Access Control Policy

Data Protection Policy

Vendor Risk Policy

Incident Response Policy

39. Policy Lifecycle

Draft
      ↓
Review
      ↓
Approval
      ↓
Publication
      ↓
Attestation
      ↓
Periodic Review
      ↓
Retirement

40. Policy Ownership

Policy records should identify:

Policy Owner

Approver

Effective Date

Review Date

Version

Related Controls

Related Requirements

41. Policy Exceptions

Sometimes business requirements prevent full compliance with policy.

Example:

Legacy Application
Cannot Support MFA

Exception:

Request
      ↓
Risk Assessment
      ↓
Compensating Controls
      ↓
Approval
      ↓
Expiry

42. Never Lose Exceptions in Email

Weak:

Email:

Approved.
Proceed without MFA.

Better:

Exception Record

Owner

Risk

Approver

Compensating Control

Expiry

Review

43. Issue Management

An issue represents a confirmed problem requiring management.

Sources may include:

Audit

Control Assessment

Risk Assessment

Security Finding

Vendor Assessment

Compliance Review

Incident

44. Issue Record

Example:

Issue ID:
ISS-00421

Title:
Privileged Accounts Without MFA

Source:
Control Assessment

Control:
IAM-001

Severity:
High

Owner:
IAM Manager

Due Date:
30 September

Status:
Open

45. Finding vs Issue

Organizations may use different terminology.

Conceptually:

Observation
      ↓
Validation
      ↓
Finding
      ↓
Management Issue

The important point is consistent governance.

46. Issue Lifecycle

Identify
      ↓
Validate
      ↓
Rate
      ↓
Assign
      ↓
Remediate
      ↓
Retest
      ↓
Close

47. Remediation Plan

Example:

Issue:
7 Privileged Accounts
Without MFA

Action:
Enable MFA

Owner:
IAM Operations

Target:
15 September

Evidence:
Updated MFA Report

48. Corrective Action Plan

A stronger corrective action plan addresses:

Immediate Fix

Root Cause

Preventive Improvement

Owner

Timeline

Evidence

49. CAPA Concept

Corrective and Preventive Action:

Problem
      ↓
Corrective Action
      ↓
Root Cause
      ↓
Preventive Action
      ↓
Verification

50. Retesting

Never close solely because:

Owner Says:
Fixed

Prefer:

Remediation
      ↓
Evidence
      ↓
Retest
      ↓
Validated
      ↓
Closure

51. Audit Management

GRC platforms can support the audit lifecycle.

Audit Universe
      ↓
Audit Planning
      ↓
Fieldwork
      ↓
Testing
      ↓
Findings
      ↓
Reporting
      ↓
Remediation

52. Audit Universe

The audit universe may include:

Business Units

Applications

Processes

Locations

Third Parties

Regulatory Areas

53. Risk-Based Audit Planning

Instead of auditing everything equally:

Risk Assessment
      ↓
Audit Priority
      ↓
Annual Audit Plan

54. Audit Engagement

Example:

Audit:
Cloud Security Review

Scope:
Production AWS Environment

Owner:
Internal Audit

Period:
Q3 2026

55. Audit Findings

Audit findings can be connected to:

Risk

Control

Business Unit

Application

Requirement

Remediation Plan

56. Third-Party Risk

Archer can also support third-party risk processes.

Lifecycle:

Vendor
      ↓
Due Diligence
      ↓
Risk Tiering
      ↓
Assessment
      ↓
Findings
      ↓
Contract
      ↓
Monitoring
      ↓
Offboarding

57. Vendor Record

Example:

Vendor:
CloudPay Ltd.

Service:
Payment Processing

Data:
Cardholder Data

Criticality:
Critical

Risk Tier:
Tier 1

58. Vendor Assessment

Assessment may examine:

Security

Privacy

Business Continuity

Compliance

Financial Risk

Operational Risk

59. Vendor Findings

Example:

Vendor
      ↓
Missing MFA
      ↓
Finding
      ↓
High Risk
      ↓
Remediation
      ↓
Monitoring

60. Integrated Risk View

This is where GRC platforms become powerful.

Suppose:

Critical Vendor

supports:

Payment Processing

and has:

High Security Finding

The platform can connect:

Vendor
      ↓
Service
      ↓
Business Process
      ↓
Risk
      ↓
Control
      ↓
Finding

61. Workflow Automation

GRC processes contain repetitive activities.

Examples:

Assessment Assignment

Evidence Requests

Approval Requests

Reminder Emails

Escalations

Finding Notifications

Risk Reviews

These can often be automated.

62. Assessment Workflow

Assessment Created
      ↓
Assigned
      ↓
Notification
      ↓
Response
      ↓
Review
      ↓
Approval

63. Evidence Request Workflow

Evidence Required
      ↓
Control Owner
      ↓
Request
      ↓
Upload
      ↓
Review
      ↓
Accept / Reject

64. Finding Escalation

Finding
      ↓
Due Date
      ↓
Overdue
      ↓
Reminder
      ↓
Escalation
      ↓
Management

65. Approval Workflow

Risk acceptance:

Risk Owner
      ↓
Business Justification
      ↓
GRC Review
      ↓
Executive Approval

depending on severity.

66. Notifications

Useful notifications include:

Assessment Due

Evidence Due

Risk Review Due

Finding Overdue

Policy Review Due

Exception Expiring

67. Avoid Notification Fatigue

Bad design:

500 Emails
Per Week

Good design:

Risk-Based

Role-Based

Priority-Based

Escalation-Based

notifications.

68. Role-Based Access Control

GRC platforms contain sensitive information.

Examples:

Security Findings

Legal Issues

Audit Findings

Vendor Risks

Executive Risks

Employee Information

Access should therefore follow:

Least Privilege

69. Example Roles

GRC Administrator

Risk Manager

Compliance Analyst

Internal Auditor

Control Owner

Risk Owner

Vendor Manager

Executive Reviewer

70. Separation of Duties

Avoid unnecessary ability for one person to:

Create Control

Test Control

Approve Result

Close Finding

71. Dashboards

Dashboards translate GRC records into management information.

Examples:

Top Enterprise Risks

Control Effectiveness

Compliance Status

Open Findings

Overdue Remediation

Vendor Risk

Audit Status

Exceptions

72. Risk Dashboard

Possible widgets:

Risks by Severity

Risks by Business Unit

Residual Risk Trend

Overdue Risk Reviews

Top Critical Risks

73. Compliance Dashboard

Possible information:

Framework Coverage

Control Effectiveness

Open Compliance Findings

Evidence Status

Assessment Progress

74. Audit Dashboard

Audits Planned

Audits In Progress

Open Findings

Overdue Actions

Findings by Severity

75. Executive Dashboard

Executives need:

Top Risks

Risk Trend

Material Findings

Control Failures

Regulatory Exposure

Remediation Progress

76. Avoid Dashboard Overload

Executives usually do not need:

8,421 Individual
Control Records

They need:

Decision-Relevant
Risk Information

77. Key Risk Indicators

KRIs help monitor changes in risk exposure.

Examples:

Critical Vulnerabilities Overdue

Privileged Accounts Without MFA

High-Risk Vendors

Open Critical Findings

Cloud Resources Publicly Exposed

78. KRI Threshold

Example:

KRI:
Critical Vulnerabilities
Overdue

Green:
0

Amber:
1–5

Red:
>5

Thresholds should follow the organization’s risk appetite and governance model.

79. KPI

KPIs measure process performance.

Example:

Percentage of
Findings Closed
Within SLA

80. KCI

Organizations may also use Key Control Indicators.

Example:

Percentage of
Privileged Accounts
Protected by MFA

81. Integrated Dashboard

KRI
      ↓
Risk

KCI
      ↓
Control

KPI
      ↓
Process

Together they provide a stronger governance picture.

82. Risk Appetite

Risk appetite defines the broad amount and type of risk an organization is willing to accept in pursuit of objectives.

Example:

Critical Cyber Risk
      ↓
Very Low Appetite

83. Risk Tolerance

Tolerance translates appetite into more measurable boundaries.

Example:

Privileged Accounts
Without MFA

Tolerance:
0

84. Threshold Breach

KRI
      ↓
Threshold
      ↓
Breach
      ↓
Escalation

85. GRC Platform Integration

Archer may receive information from other enterprise systems.

Conceptually:

Security Platforms

IAM

CMDB

Vulnerability Tools

Cloud Platforms

HR

Vendor Systems
      ↓
RSA Archer

86. Security Integration

Example:

Security Platform
      ↓
Critical Finding
      ↓
Control Mapping
      ↓
Archer Issue

87. CMDB Integration

CMDB
      ↓
Applications
      ↓
Assets
      ↓
Business Services
      ↓
GRC Relationships

88. Identity Integration

Identity Platform
      ↓
MFA Coverage
      ↓
Control Evidence
      ↓
Assessment

89. Automated Evidence

Instead of:

Email Control Owner
      ↓
Request Screenshot

organizations can move toward:

Source System
      ↓
Integration
      ↓
Evidence
      ↓
Control Assessment

90. Data Quality

A GRC platform is only as useful as its data.

Poor data creates:

Wrong Risk Reports

Incorrect Compliance Status

Missing Owners

Duplicate Records

Misleading Dashboards

91. Garbage In, Garbage Out

Poor GRC Data
      ↓
Poor Reporting
      ↓
Poor Decisions

92. Required Fields

Important records should require appropriate fields.

Risk:

Risk Owner

Business Unit

Impact

Likelihood

Treatment

Review Date

Control:

Control Owner

Frequency

Type

Evidence

Related Risks

Finding:

Severity

Owner

Due Date

Root Cause

Remediation

93. Naming Standards

Avoid:

Risk 1

New Risk

Risk Final

Risk Updated

Use consistent identifiers:

RISK-CYB-001

CTRL-IAM-001

ISS-AUD-004

POL-SEC-001

94. Duplicate Records

One major GRC-platform challenge is duplicate information.

Example:

Privileged MFA

MFA for Admins

Administrator MFA

Admin Multi-Factor Authentication

may all represent the same control.

Governance should prevent unnecessary duplication.

95. Record Ownership

Every important record should have an owner.

Risk
→ Risk Owner

Control
→ Control Owner

Policy
→ Policy Owner

Finding
→ Remediation Owner

Vendor
→ Vendor Owner

96. Record Review

Records should not remain unchanged forever.

Record
      ↓
Review Frequency
      ↓
Owner Review
      ↓
Update / Confirm

97. Audit Trail

A mature platform should preserve relevant history such as:

Who Changed It?

What Changed?

When?

Previous Value?

Approval?

This supports accountability and assurance.

98. GRC Platform Governance

The GRC platform itself needs governance.

Define:

Platform Owner

Data Owners

Administrators

Workflow Owners

Reporting Owners

Access Model

Change Management

99. Configuration Management

Changes to important GRC workflows should follow controlled processes.

Example:

Change Request
      ↓
Impact Assessment
      ↓
Testing
      ↓
Approval
      ↓
Deployment

100. Why?

Imagine someone changes:

Critical Risk Threshold

from:

15

to:

25

This could materially alter executive risk reporting.

101. Platform Access Review

Periodically review:

Administrators

Auditors

Risk Managers

Compliance Users

External Users

to ensure access remains appropriate.

102. Backup and Resilience

Because the platform may contain critical GRC records, organizations should consider:

Availability

Backup

Recovery

Business Continuity

Data Retention

103. Common Mistake — Automating Bad Processes

Avoid:

Broken Spreadsheet
Process
      ↓
Automate It

Automation does not fix poor governance.

Better:

Understand Process
      ↓
Simplify
      ↓
Standardize
      ↓
Automate

104. Common Mistake — Building Everything

A GRC platform can support many processes.

That does not mean:

Implement
Everything
Immediately

Prefer phased implementation.

105. Practical Implementation Roadmap

Phase 1
Foundation

Phase 2
Risk

Phase 3
Controls

Phase 4
Compliance

Phase 5
Issues

Phase 6
Audit

Phase 7
Third Parties

Phase 8
Automation

Phase 9
Reporting

Phase 10
Continuous Assurance

106. Phase 1 — Foundation

Establish:

Governance

Taxonomies

Roles

Naming Standards

Access Model

Data Model

107. Phase 2 — Risk

Implement:

Risk Register

Risk Assessments

Risk Ratings

Ownership

Treatment

108. Phase 3 — Controls

Implement:

Control Library

Control Ownership

Control Assessments

Evidence

109. Phase 4 — Compliance

Map:

Frameworks
      ↓
Requirements
      ↓
Controls

110. Phase 5 — Issues

Implement:

Finding Management

Remediation

CAPA

Retesting

Closure

111. Phase 6 — Audit

Implement:

Audit Universe

Planning

Engagements

Testing

Findings

112. Phase 7 — Third Parties

Implement:

Vendor Inventory

Tiering

Assessments

Findings

Monitoring

113. Phase 8 — Automation

Automate:

Assignments

Notifications

Evidence Requests

Escalations

Approvals

114. Phase 9 — Reporting

Build:

Operational Dashboards

Management Dashboards

Executive Dashboards

115. Phase 10 — Continuous Assurance

Integrate:

Security Platforms

Cloud Platforms

IAM

Vulnerability Systems

CMDB

to support:

Continuous
Control Monitoring

116. End-to-End Example — Privileged MFA

Requirement:

Privileged Access
Must Use MFA

Control:

IAM-001
Privileged MFA

Risk:

Unauthorized
Privileged Access

Evidence:

Identity Platform
MFA Report

Assessment:

7 Accounts
Without MFA

Finding:

ISS-00421

Remediation:

Enable MFA

Retest:

100% Coverage

Closure:

Validated

Complete relationship:

Requirement
      ↓
Control
      ↓
Risk
      ↓
Evidence
      ↓
Assessment
      ↓
Finding
      ↓
Remediation
      ↓
Retest

117. End-to-End Example — PCI DSS

PCI DSS
      ↓
Access Requirement
      ↓
IAM-001
      ↓
Payment Application
      ↓
MFA Evidence
      ↓
Control Test
      ↓
Exception
      ↓
Remediation

118. End-to-End Example — Vendor Risk

Vendor:

CloudPay

Criticality:

Critical

Assessment identifies:

No Tested
Disaster Recovery Plan

Risk:

Service
Availability

Finding:

High

Workflow:

Vendor
      ↓
Assessment
      ↓
Finding
      ↓
Risk
      ↓
Remediation
      ↓
Evidence
      ↓
Closure

119. End-to-End Example — Audit

Audit Plan
      ↓
Cloud Security Audit
      ↓
Control Testing
      ↓
Finding
      ↓
Business Owner
      ↓
Corrective Action
      ↓
Retest
      ↓
Closure

RSA Archer Operational Checklist

Platform Governance

• platform owner assigned.

• governance model established.

• access roles defined.

• naming standards established.

• data-quality requirements defined.

• change-management process established.

Risk Management

• risk taxonomy established.

• risk register created.

• risk owners assigned.

• inherent-risk methodology defined.

• residual-risk methodology defined.

• treatment options established.

• risk review frequency defined.

Control Management

• enterprise control library created.

• duplicate controls eliminated.

• control owners assigned.

• control types defined.

• control frequency recorded.

• evidence requirements defined.

• assessment methodology established.

Compliance

• applicable frameworks identified.

• requirements maintained.

• requirements mapped to controls.

• assessments scheduled.

• evidence maintained.

• compliance findings tracked.

Policy

• policies inventoried.

• policy owners assigned.

• review dates defined.

• approvals documented.

• exceptions governed.

• version history maintained.

Issues

• finding taxonomy established.

• severity methodology defined.

• owners assigned.

• remediation plans required.

• due dates established.

• overdue escalation configured.

• retesting required before closure.

Audit

• audit universe established.

• risk-based planning implemented.

• engagements tracked.

• testing documented.

• findings linked to controls.

• remediation monitored.

Third Parties

• vendor inventory established.

• criticality defined.

• risk tiers assigned.

• assessments configured.

• findings monitored.

• ongoing monitoring established.

Workflow

• assignments automated.

• notifications configured.

• approvals established.

• escalations configured.

• workflow ownership assigned.

Reporting

• operational dashboards created.

• management dashboards created.

• executive dashboards created.

• KRIs established.

• KPIs established.

• KCIs established.

• trend reporting implemented.

Integration

• source systems identified.

• security integration evaluated.

• CMDB integration evaluated.

• IAM integration evaluated.

• evidence automation evaluated.

• data reconciliation established.

RSA Archer Deliverables

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

01 Enterprise Risk Register

02 Risk Taxonomy

03 Common Control Library

04 Regulatory Control Mapping

05 Control Assessment Workflow

06 Evidence Management Model

07 Policy Governance Workflow

08 Finding & Issue Register

09 CAPA Workflow

10 Risk Acceptance Workflow

11 Audit Management Workflow

12 Third-Party Risk Workflow

13 GRC Approval Matrix

14 GRC Platform Access Model

15 KRI / KPI / KCI Register

16 Executive Risk Dashboard

17 Compliance Dashboard

18 Archer Integration Architecture

19 GRC Data Governance Standard

20 Continuous Assurance Model

Practical Activity — Build a Risk Register

Create five risks:

Cybersecurity Risk

Cloud Risk

Vendor Risk

Privacy Risk

Compliance Risk

For each define:

Risk ID

Risk Statement

Category

Owner

Likelihood

Impact

Inherent Risk

Controls

Residual Risk

Treatment

Practical Activity — Build a Control Library

Create controls for:

MFA

Access Reviews

Vulnerability Management

Security Logging

Data Classification

Vendor Assessment

For each define:

Control ID

Objective

Owner

Frequency

Type

Automation

Evidence

Practical Activity — Regulatory Mapping

Take:

IAM-001
Privileged MFA

Map it conceptually to applicable requirements from:

PCI DSS

ISO 27001

SOC 2

Internal Security Policy

Then determine what evidence would demonstrate that the control operates effectively.

Practical Activity — Issue Management

Scenario:

12 Administrator
Accounts

Without MFA

Create:

Issue ID

Source

Related Control

Severity

Root Cause

Owner

Corrective Action

Preventive Action

Due Date

Evidence

Retest Procedure

Practical Activity — Design an Archer Workflow

Build:

Finding Created
      ↓
Risk Rating
      ↓
Owner Assigned
      ↓
Remediation
      ↓
Evidence Submitted
      ↓
GRC Review
      ↓
Retest
      ↓
Closure

Define:

Notifications

Approvals

Escalations

SLA

Exception Process

Practical Activity — Build an Executive Dashboard

Include:

Top 10 Enterprise Risks

Critical Open Findings

Overdue Remediation

Control Effectiveness

Compliance Status

High-Risk Vendors

Risk Acceptance

Risk Trend

For each metric determine:

Data Source

Owner

Refresh Frequency

Threshold

Escalation

RSA Archer GRC Mindset

When working with an enterprise GRC platform, ask:

What Business
Objective Are
We Protecting?

What Risk
Exists?

Who Owns
the Risk?

What Control
Reduces It?

Who Owns
the Control?

Which Requirements
Does the Control
Support?

What Evidence
Demonstrates It?

Is the Control
Designed Properly?

Does It
Operate Effectively?

What Assessment
Was Performed?

Was a Finding
Identified?

What Is
the Root Cause?

Who Owns
Remediation?

What Is
the Due Date?

What Evidence
Proves Remediation?

Was It
Retested?

What Residual
Risk Remains?

Does Management
Accept It?

Which Business
Processes Are
Affected?

Which Applications
Are Affected?

Which Vendors
Are Affected?

Can Evidence
Be Automated?

What KRI
Should Monitor
the Risk?

What KCI
Should Monitor
the Control?

What Should
Executives See?

Is the GRC
Data Accurate?

Are Relationships
Maintained?

Can We Trace
Requirement
to Control
to Evidence
to Finding?

That is the mindset required to use RSA Archer as an enterprise GRC professional rather than simply as a workflow tool.

Key Takeaways

• RSA Archer is an enterprise GRC platform used to structure and manage interconnected governance, risk, compliance, audit, control, issue, and third-party information.

• The value of a GRC platform comes from relationships between records, not merely storing information.

• Risk registers provide structured visibility into enterprise risks.

• Inherent risk represents risk before considering controls.

• Residual risk represents the remaining risk after considering control effectiveness.

• Business leaders normally own business risk; GRC facilitates the process.

• A common control library reduces duplication across regulatory frameworks.

• One enterprise control can support multiple compliance requirements.

• Control assessments should distinguish design effectiveness from operating effectiveness.

• Evidence must be traceable to controls and assessment conclusions.

• Compliance frameworks should be mapped to enterprise controls rather than managed as isolated silos.

• Policy management requires ownership, approvals, versioning, review, and exception governance.

• Findings should have clear ownership, severity, remediation, due dates, evidence, and retesting.

• Corrective action should address root cause, not simply symptoms.

• Audit findings can be connected to risks, controls, requirements, processes, and applications.

• Third-party risk can be integrated into the broader enterprise risk model.

• Workflow automation improves consistency but should not automate poorly designed processes.

• Dashboards should be designed for their intended audience.

• KRIs monitor risk, KPIs monitor process performance, and KCIs can monitor control performance.

• GRC-platform data quality is critical to trustworthy reporting.

• The GRC platform itself requires access governance, change management, data ownership, and operational controls.

• Integration with security, IAM, CMDB, cloud, and vulnerability systems can enable continuous assurance.

Knowledge Check

Before continuing, make sure you can answer:

1. What is RSA Archer?

2. Why do organizations use enterprise GRC platforms?

3. Why are relationships between GRC records important?

4. What is a risk register?

5. What is a risk taxonomy?

6. What is inherent risk?

7. What is residual risk?

8. Who should own enterprise risk?

9. What is a common control library?

10. Why should duplicate controls be avoided?

11. How can one control support several compliance frameworks?

12. What is control design effectiveness?

13. What is control operating effectiveness?

14. What constitutes control evidence?

15. Why is evidence traceability important?

16. How can Archer support compliance management?

17. What is regulatory mapping?

18. What stages make up the policy lifecycle?

19. How should policy exceptions be managed?

20. What is an issue-management lifecycle?

21. Why should findings be retested before closure?

22. What is CAPA?

23. How can Archer support internal audit?

24. What is an audit universe?

25. How can Archer support third-party risk?

26. What GRC activities can be automated?

27. Why should notification fatigue be avoided?

28. Why is least privilege important within a GRC platform?

29. What is separation of duties?

30. What is a KRI?

31. What is a KPI?

32. What is a KCI?

33. What is risk appetite?

34. What is risk tolerance?

35. Why is GRC data quality important?

36. Why should GRC-platform changes be controlled?

37. How can security platforms integrate with Archer?

38. How can automated evidence improve compliance?

39. Why should organizations avoid implementing every GRC capability at once?

40. What is continuous assurance?

What’s Next?

➡️ Next: 05 — OneTrust

In the next lesson, you will examine how OneTrust can support enterprise privacy, GRC, third-party risk, data governance, consent and preference management, risk assessments, compliance activities, and regulatory operations.

You will explore the relationship:

Enterprise Data
      ↓
Privacy
      ↓
Third Parties
      ↓
Risk
      ↓
Controls
      ↓
Assessments
      ↓
Compliance
      ↓
Evidence
      ↓
Remediation
      ↓
Reporting

The focus will be on understanding how a platform such as OneTrust can connect privacy governance, data protection, third-party risk, compliance management, and enterprise GRC operations.