07 Vanta

Organizations increasingly need to demonstrate that their security controls are operating effectively—not only during an annual audit, but throughout the year.

Traditional compliance programs often depend on:

Spreadsheets

Screenshots

Email Requests

Shared Folders

Manual Checklists

Point-in-Time Evidence

This creates a repetitive cycle:

Audit Approaches
      ↓
Collect Evidence
      ↓
Contact Control Owners
      ↓
Find Missing Evidence
      ↓
Fix Compliance Gaps
      ↓
Complete Audit
      ↓
Wait
      ↓
Repeat Next Year

Modern compliance automation platforms such as Vanta help organizations move toward a more continuous approach.

Conceptually:

Cloud Platforms
      +
Identity Systems
      +
Endpoints
      +
HR Systems
      +
Source Control
      +
Security Tools
      ↓
Vanta
      ↓
Automated Tests
      ↓
Control Monitoring
      ↓
Evidence
      ↓
Framework Mapping
      ↓
Audit Readiness
      ↓
Trust

For a GRC professional, Vanta should not be viewed as:

Install Platform
      ↓
Become Compliant

Instead:

Governance
      +
Controls
      +
Technology
      +
Evidence
      +
Monitoring
      +
Human Review
      ↓
Compliance Assurance

Learning Objectives

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

Explain the purpose of Vanta.
understand compliance automation.
understand continuous control monitoring.
understand Vanta’s control model.
understand framework mapping.
understand automated tests.
understand automated evidence.
understand manual evidence.
understand integration architecture.
understand integration health.
understand personnel compliance.
understand device compliance.
understand identity controls.
understand cloud controls.
understand source-control controls.
understand vulnerability-management evidence.
understand policy management.
understand risk management.
understand vendor security.
understand security reviews.
understand audit readiness.
understand auditor collaboration.
understand Trust Centers.
understand security questionnaire workflows.
understand remediation.
understand compliance exceptions.
understand dashboards and reporting.
understand limitations of compliance automation.
design a practical Vanta operating model.

1. What Is Vanta?

Vanta is a trust and compliance platform that helps organizations manage security and compliance activities.

Organizations may use it to support areas such as:

Compliance Frameworks

Security Controls

Automated Tests

Evidence Collection

Personnel Compliance

Device Monitoring

Risk Management

Vendor Security

Audit Preparation

Security Reviews

Trust Management

Available capabilities can vary depending on the organization’s subscription and current platform configuration.

2. Why Organizations Use Vanta

Organizations may need to demonstrate compliance with multiple frameworks.

Examples include:

SOC 2

ISO 27001

PCI DSS

HIPAA

GDPR-related controls

Internal Security Requirements

Customer Security Requirements

Without automation:

Framework
      ↓
Control
      ↓
Email Evidence Request
      ↓
Screenshot
      ↓
Shared Folder
      ↓
Auditor

With automation:

Framework
      ↓
Control
      ↓
Connected System
      ↓
Automated Test
      ↓
Evidence
      ↓
Monitoring

3. Traditional vs Continuous Compliance

Traditional compliance is often:

Periodic

For example:

January
Prepare

February
Collect Evidence

March
Audit

April
Finish

Then control visibility may decrease until the next assessment.

Continuous compliance aims for:

Controls
      ↓
Regular Monitoring
      ↓
Failures
      ↓
Remediation
      ↓
Retesting

throughout the year.

4. Compliance Automation Architecture

Conceptually:

AWS ───────────────┐
Azure ─────────────┤
Identity ──────────┤
HR ────────────────┤
Endpoints ─────────┼──→ Vanta
Source Control ────┤
Security Tools ────┤
Ticketing ─────────┘
                    ↓
               Automated Tests
                    ↓
                  Controls
                    ↓
                 Evidence
                    ↓
                Frameworks

5. Frameworks

A compliance framework defines requirements or criteria the organization must address.

Examples may include:

SOC 2

ISO 27001

PCI DSS

HIPAA

Custom Requirements

The organization must first determine:

Which Frameworks
Actually Apply?

6. Framework Scope

Before implementing controls, define scope.

Scope may include:

Legal Entities

Products

Applications

Cloud Accounts

Employees

Locations

Vendors

Data

Business Processes

Poor scope creates poor compliance conclusions.

7. Example Scope

A SaaS organization might define:

Product:
Customer SaaS Platform

Cloud:
Production AWS Accounts

Employees:
All Personnel Supporting Product

Repositories:
Production Application Repositories

Endpoints:
Corporate Managed Devices

8. Controls

A control is an activity designed to address:

Risk

Requirement

Security Objective

Compliance Objective

Example:

IAM-001

Multi-factor authentication
must be enabled for
privileged accounts.

9. Control Structure

A mature control record may contain:

Control ID

Control Objective

Description

Owner

Frequency

Evidence

Test

Framework Mapping

Exceptions

10. Common Controls

Instead of creating:

SOC2-MFA

ISO-MFA

PCI-MFA

create:

IAM-001
Privileged MFA

and map it appropriately.

11. Framework Mapping

Conceptually:

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

This reduces duplicated compliance work.

12. Control Ownership

Every control should have a clear owner.

Examples:

Control	Owner
MFA	Identity Team
Endpoint Encryption	IT
Security Training	Security / HR
Code Review	Engineering
Vulnerability Management	Security
Vendor Assessment	GRC / Procurement

13. Control Owner vs GRC

Control owner:

Operates
the Control

GRC:

Defines

Coordinates

Monitors

Assesses

Reports

GRC should not automatically become the operational owner of every control.

14. Automated Tests

An automated test evaluates system information against defined conditions.

Example:

Control:
Employees Must Use MFA

Test:

Identity Provider
      ↓
Active Users
      ↓
MFA Status
      ↓
Pass / Fail

15. Automated Test Example

Population:

500 Employees

Results:

496 MFA Enabled

4 MFA Disabled

If the control requires:

100%

the test may fail.

16. What Does a Failed Test Mean?

Not necessarily:

Organization
Is Non-Compliant

It means:

Test Condition
Was Not Satisfied

The next step is:

Investigate

17. Failed Test Investigation

Ask:

Which Objects Failed?

Are They In Scope?

Is the Population Correct?

Is There an Approved Exception?

Is the Integration Current?

Is the Test Logic Correct?

Does This Represent
a Control Failure?

18. False Positives

Suppose an account appears without MFA.

Investigation finds:

Service Account

No Interactive Login

Compensating Controls

The test may still require governance review rather than automatic classification as a material finding.

19. Automated Evidence

Traditional:

Control Owner
      ↓
Screenshot
      ↓
Upload

Automated:

Source System
      ↓
Integration
      ↓
Evidence
      ↓
Control

20. Why Automated Evidence Helps

Potential benefits:

Freshness

Consistency

Traceability

Reduced Manual Work

Repeatability

Continuous Visibility

21. Evidence Does Not Equal Assurance

Having evidence does not automatically mean:

Control Effective

Evidence must still be evaluated for:

Relevance

Reliability

Completeness

Accuracy

Period

Scope

22. Evidence Sources

Potential evidence sources include:

Identity Providers

Cloud Platforms

Endpoint Management

HR Systems

Source Control

Vulnerability Platforms

Ticketing Systems

Security Platforms

23. Identity Evidence

Example control:

All Employees
Use MFA

Potential evidence:

Active Users

MFA Enrollment

Privileged Roles

Account Status

24. Cloud Evidence

Example:

Production Storage
Must Be Encrypted

Potential evidence:

Cloud Resource Inventory

Encryption Configuration

Account Scope

25. Endpoint Evidence

Example:

Corporate Devices
Must Use
Full-Disk Encryption

Evidence:

Device Inventory

Encryption Status

Device Owner

Management Status

26. Source-Control Evidence

Example:

Production Code
Requires Review

Evidence may include:

Repository Settings

Branch Protection

Pull Requests

Reviewers

Approvals

27. HR Evidence

Example:

Security Training
Required for
All Employees

Evidence:

Employee Population

Hire Date

Training Completion

Termination Date

28. Vulnerability Evidence

Example control:

Critical Vulnerabilities
Must Be Remediated
Within Defined SLA

Evidence may include:

Vulnerability

Severity

Asset

Discovery Date

Remediation Date

Status

29. Manual Evidence

Some controls require human-generated evidence.

Examples:

Board Meeting Minutes

Risk Assessment

Penetration Test Report

Incident Exercise

Policy Approval

Vendor Assessment

30. Hybrid Compliance

A mature compliance program uses:

Automated Controls
        +
Manual Controls
        ↓
Compliance Assurance

31. Evidence Freshness

Consider:

January Screenshot

used during:

November Audit

The evidence may no longer represent the current environment.

Continuous collection can reduce this problem.

32. Evidence Period

Auditors may need evidence covering:

Entire Assessment Period

rather than:

Today

This is a crucial distinction.

33. Design vs Operating Effectiveness

Design effectiveness asks:

If this control operates as designed, can it reasonably achieve the intended objective?

Operating effectiveness asks:

Did the control actually operate as required during the relevant period?

34. Example — Code Review

Configuration:

Branch Protection
Enabled

may support:

Control Design

But operating effectiveness may require:

Sample Production Changes

Pull Requests

Approvals

Reviewer Independence

35. Integration Architecture

Compliance automation depends heavily on integrations.

Source System
      ↓
Authentication
      ↓
Integration
      ↓
Data
      ↓
Test Logic
      ↓
Compliance Result

36. Integration Scope

Always define:

Which Accounts?

Which Users?

Which Devices?

Which Repositories?

Which Cloud Subscriptions?

Which Business Units?

37. Missing Scope

Imagine Vanta monitors:

AWS Account A

but production exists in:

AWS Account B

A green dashboard could create:

False Assurance

38. Population Completeness

Suppose HR says:

1,000 Employees

but Vanta evaluates:

850 Users

Before evaluating compliance, investigate:

Missing 150

39. Integration Health

Monitor:

Connection Status

Last Synchronization

Errors

Authentication

Scope Changes

Permissions

40. Integration Permissions

Apply:

Least Privilege

Avoid unnecessary:

Administrator Permissions

when read-only access is sufficient.

41. Integration Credentials

Protect:

API Tokens

Service Accounts

OAuth Grants

Integration Secrets

because compliance integrations themselves can become security-sensitive.

42. Personnel Compliance

Personnel controls may include:

Background Checks

Security Training

Policy Acceptance

Confidentiality Agreements

Access Provisioning

Termination

43. Authoritative Personnel Source

Use an authoritative source such as:

HR System

to establish:

Who Is
an Employee?

44. New Hire Workflow

Employee Hired
      ↓
HR Record
      ↓
Identity Created
      ↓
Security Training
      ↓
Policy Acknowledgment
      ↓
Device Assigned

45. New Hire Grace Period

A new employee may appear:

Non-Compliant

because training is incomplete.

But policy may allow:

7 Days

after hiring.

Therefore context matters.

46. Termination Control

Example:

Access Must Be
Removed Within
24 Hours of
Termination

Evidence can compare:

HR Termination Time
      ↓
Identity Disable Time

47. Device Compliance

Typical device controls:

Disk Encryption

Screen Lock

Endpoint Protection

Firewall

OS Version

Device Management

48. Device Population

Suppose:

Employee Count:
1,000

but:

Managed Devices:
750

Do not immediately conclude:

750 Devices Compliant

First understand:

Why Are
250 Missing?

49. Device Exception

Example:

Device:
Engineering Test Machine

Encryption:
Disabled

Reason:
Technical Requirement

Compensating Controls:
Restricted Network
No Sensitive Data

Expiry:
30 Days

50. Identity Compliance

Identity controls may monitor:

MFA

Privileged Access

Inactive Accounts

Termination

Password Requirements

SSO

51. Privileged Access

Example:

12 Administrators

Test:

11 MFA Enabled

1 MFA Disabled

A single failure may be highly material.

52. Risk-Based Interpretation

Do not evaluate only:

Percentage Passing

Evaluate:

Asset Criticality

Privilege

Data Sensitivity

Exposure

Risk

53. Cloud Security Monitoring

Potential cloud checks may involve:

Encryption

Logging

Public Exposure

Backups

Security Configuration

Identity

54. Example — Cloud Storage

Control:

Production Storage
Must Not Be
Publicly Accessible

Workflow:

Cloud Integration
      ↓
Storage Inventory
      ↓
Public Access Check
      ↓
Pass / Fail

55. Cloud Scope

For every integration, document:

Accounts

Subscriptions

Projects

Regions

Environment

Owner

56. Source-Control Compliance

Engineering controls may include:

Branch Protection

Code Review

Change Approval

Repository Access

Secure Development

57. Repository Scope

Identify:

Production Repositories

Infrastructure Repositories

Security-Critical Repositories

Do not assume every repository has the same compliance importance.

58. Vulnerability Management

A compliance program may require:

Regular Scanning

Risk-Based Prioritization

Remediation SLAs

Exception Management

Verification

59. Vulnerability Workflow

Scan
      ↓
Finding
      ↓
Severity
      ↓
Asset
      ↓
SLA
      ↓
Remediation
      ↓
Verification

60. Vulnerability Exception

If remediation cannot occur within SLA:

Exception
      ↓
Risk Assessment
      ↓
Compensating Controls
      ↓
Approval
      ↓
Expiry

61. Policy Management

Compliance frameworks commonly require documented policies.

Examples:

Information Security Policy

Access Control Policy

Risk Management Policy

Incident Response Policy

Vendor Management Policy

Business Continuity Policy

62. Policy Lifecycle

Draft
      ↓
Review
      ↓
Approve
      ↓
Publish
      ↓
Acknowledge
      ↓
Review
      ↓
Update

63. Policy Ownership

Every policy should identify:

Owner

Approver

Effective Date

Review Date

Version

64. Policy Evidence

Evidence may include:

Approved Policy

Approval History

Version

Employee Acknowledgment

Review History

65. Risk Management

Compliance automation should connect with enterprise risk management.

Example:

Failed MFA Control
      ↓
Unauthorized Access Risk

66. Risk Register

Example:

Risk	Owner	Inherent	Controls	Residual
Account Compromise	Security	High	MFA, Monitoring	Medium
Data Exposure	Engineering	Critical	Encryption	Medium
Vendor Failure	Procurement	High	TPRM	Medium
Service Outage	Operations	High	DR, Backup	Low

67. Risk Statement

Avoid:

MFA Missing

as the risk.

Better:

Unauthorized access to
production systems may occur
if privileged credentials
are compromised.

68. Risk Treatment

Common options:

Mitigate

Accept

Avoid

Transfer

69. Risk Acceptance

Capture:

Risk

Business Justification

Residual Risk

Compensating Controls

Approver

Expiry

Review Date

70. Vendor Security

Organizations rely heavily on:

Cloud Providers

SaaS Vendors

Payment Providers

Consultants

Data Processors

Each can introduce risk.

71. Vendor Inventory

Maintain information such as:

Vendor

Service

Owner

Criticality

Data Access

System Access

Risk Tier

Assessment Status

72. Vendor Tiering

Example:

Tier 1
Critical

Tier 2
High

Tier 3
Moderate

Tier 4
Low

Assessment depth should reflect risk.

73. Vendor Security Assessment

Questions may cover:

Security Governance

Access Control

Encryption

Vulnerability Management

Incident Response

Business Continuity

Privacy

Compliance

74. Vendor Workflow

Vendor Requested
      ↓
Initial Screening
      ↓
Risk Tier
      ↓
Security Review
      ↓
Privacy Review
      ↓
Contract
      ↓
Approval
      ↓
Monitoring

75. Vendor Monitoring

Assessment should not end after onboarding.

Onboard
      ↓
Monitor
      ↓
Reassess
      ↓
Incident?
      ↓
Contract Change?
      ↓
Offboard

76. Vendor Finding

Example:

Critical Vendor
Does Not Require
MFA for Administrators

Workflow:

Finding
      ↓
Risk
      ↓
Vendor Owner
      ↓
Remediation
      ↓
Acceptance / Approval

77. Security Reviews

Organizations frequently need to prove their security posture to customers.

This may involve:

Security Questionnaires

Evidence Requests

Policies

Certifications

Architecture Questions

Vendor Reviews

78. Security Questionnaire Problem

Imagine receiving:

200 Questions

from:

50 Customers

Many questions are repeated.

79. Response Library

Organizations can maintain:

Approved Security Responses

Control Information

Policies

Supporting Evidence

to reduce repetitive work.

80. Response Governance

Each response should ideally have:

Owner

Approval

Evidence

Last Review

Version

Never automatically reuse an answer without verifying:

Current?

Accurate?

Applicable?

Approved?

Safe to Share?

82. Trust Center

A Trust Center can provide approved security and compliance information to:

Customers

Prospects

Partners

83. Trust Center Content

Organizations may share selected:

Certifications

Attestations

Security Overview

Policies

Compliance Information

Security FAQs

84. Public vs Controlled Content

Some information may be:

Public

while sensitive documents may require:

Access Request

NDA

Approval

85. Never Expose Sensitive Evidence

Avoid publishing:

Internal Vulnerabilities

Detailed Penetration Test Findings

Sensitive Architecture

Internal Audit Findings

Credentials

Confidential Risk Registers

86. Trust as a Business Process

Trust management connects:

Security
      +
Compliance
      +
Sales
      +
Legal
      ↓
Customer Assurance

87. Audit Readiness

Compliance automation can improve audit preparation.

Traditional:

Auditor Request
      ↓
Find Evidence
      ↓
Email Owner
      ↓
Upload

Improved:

Control
      ↓
Evidence
      ↓
Monitoring
      ↓
Auditor Review

88. Audit Workspace

An audit workflow may centralize:

Controls

Evidence

Requests

Comments

Exceptions

Testing Status

89. Auditor Independence

The platform does not replace:

Independent
Auditor Judgment

Auditors may:

Inspect Evidence

Select Samples

Validate Population

Reperform Testing

Challenge Exceptions

90. Audit Population

Example:

Control:

Quarterly
Access Reviews

Auditor may request:

All Access Reviews
During Audit Period

then select:

Samples

91. Evidence Reuse

One piece of evidence may support multiple requirements where appropriate.

MFA Evidence
      ↓
SOC 2

ISO 27001

PCI DSS

But verify:

Scope

Period

Objective

Population

92. Audit Readiness Dashboard

Potential indicators:

Controls Passing

Failed Tests

Missing Evidence

Policies Due

Risks Open

Vendor Reviews Due

Audit Requests

93. Readiness ≠ Certification

Important:

100%
Tests Passing

does not automatically mean:

Certified

or:

Audit Passed

94. Why?

Formal assurance may require:

Independent Assessment

Evidence Sampling

Period Testing

Professional Judgment

Scope Validation

95. Remediation

When a control problem is identified:

Issue
      ↓
Owner
      ↓
Root Cause
      ↓
Action
      ↓
Evidence
      ↓
Retest
      ↓
Closure

96. Example

Issue:

5 Corporate Laptops
Not Encrypted

Immediate action:

Enable Encryption

Root cause:

Provisioning Workflow
Did Not Enforce
Encryption

Corrective action:

Fix Provisioning
Process

97. Why Root Cause Matters

Without fixing root cause:

Encrypt 5 Devices
      ↓
Next Month
5 More Devices
Fail

98. Exception Management

Not every control requirement can always be immediately met.

Example:

Legacy System
Cannot Support
Required Configuration

Exception:

Request
      ↓
Risk Assessment
      ↓
Compensating Control
      ↓
Approval
      ↓
Expiry

99. Exceptions Must Expire

Avoid:

Permanent
Exception

without review.

Use:

Expiry Date
      ↓
Reassessment

100. Continuous Monitoring

Vanta’s strongest operational value comes when organizations use the platform continuously.

Monitor areas such as:

MFA

Devices

Security Training

Cloud Configuration

Repositories

Policies

Vulnerabilities

Vendor Reviews

Evidence

101. Control Drift

A control may be compliant today and fail tomorrow.

Example:

Monday
MFA = 100%

Tuesday
New Admin Created

Wednesday
MFA = 99%

Continuous monitoring identifies:

Control Drift

102. Drift Workflow

Test Passes
      ↓
Environment Changes
      ↓
Test Fails
      ↓
Alert
      ↓
Investigation
      ↓
Remediation

103. Compliance Dashboard

A GRC dashboard may show:

Framework Readiness

Controls

Tests

Evidence

Risks

Vendors

Audit Status

104. Failed Tests Dashboard

Prioritize by:

Control Criticality

Risk

Asset

Framework Impact

Duration

not merely:

Number of Failures

105. Executive Dashboard

Executives need:

Material Compliance Risks

Audit Readiness

Critical Control Failures

Overdue Remediation

Vendor Risk

Security Assurance Trend

106. Operational Dashboard

Control owners need:

My Failed Tests

My Evidence

My Controls

My Remediation

Upcoming Tasks

107. Compliance Metrics

Useful metrics may include:

Control Pass Rate

Failed Critical Controls

Evidence Completion

Policy Completion

Training Completion

Device Compliance

Vendor Assessment Completion

Remediation SLA

108. KRI Example

Privileged Accounts
Without MFA

Threshold:

Green = 0

Red > 0

109. KPI Example

Percentage of
Compliance Issues
Closed Within SLA

110. KCI Example

Percentage of
Corporate Devices
Encrypted

111. Compliance Score Limitations

Suppose:

99.5%
Tests Passing

but failed test:

Production Database
Publicly Accessible

The percentage is misleading.

Always consider:

Risk

112. Risk-Based Compliance

Better:

Control Status
      +
Control Criticality
      +
Asset Criticality
      +
Business Risk

113. Continuous Compliance ≠ Continuous Certification

Continuous monitoring provides:

Continuous
Visibility

It does not necessarily provide:

Continuous
Formal Certification

114. Compliance Automation Maturity

A practical maturity model:

Level 1
Manual

Level 2
Centralized

Level 3
Integrated

Level 4
Automated

Level 5
Continuous Assurance

115. Level 1 — Manual

Spreadsheets

Screenshots

Email

116. Level 2 — Centralized

Controls

Policies

Evidence

maintained centrally.

117. Level 3 — Integrated

Cloud

IAM

HR

Endpoints

Repositories

connected.

118. Level 4 — Automated

System Data
      ↓
Automated Test
      ↓
Control Result

119. Level 5 — Continuous Assurance

Controls
      ↓
Continuous Evidence
      ↓
Risk
      ↓
Exceptions
      ↓
Remediation
      ↓
Management Visibility

120. Practical Vanta Implementation Roadmap

A structured implementation could follow:

Phase 1
Governance

Phase 2
Scope

Phase 3
Frameworks

Phase 4
Controls

Phase 5
Integrations

Phase 6
Evidence

Phase 7
Testing

Phase 8
Risk & Vendors

Phase 9
Audit

Phase 10
Continuous Assurance

121. Phase 1 — Governance

Define:

Program Owner

Control Owners

Risk Owners

Evidence Owners

Policy Owners

Approval Model

122. Phase 2 — Scope

Identify:

Systems

Applications

Cloud Accounts

Employees

Devices

Repositories

Vendors

123. Phase 3 — Frameworks

Select applicable:

SOC 2

ISO 27001

PCI DSS

Other Requirements

124. Phase 4 — Controls

Establish:

Common Control Library

Framework Mapping

Control Frequency

Ownership

Evidence

125. Phase 5 — Integrations

Prioritize authoritative systems:

HR

IAM

Cloud

Endpoint

Source Control

126. Phase 6 — Evidence

Validate:

Source

Scope

Population

Period

Reliability

Completeness

127. Phase 7 — Testing

Configure:

Automated Tests

Manual Tests

Thresholds

Exception Rules

Escalation

128. Phase 8 — Risk & Vendors

Implement:

Risk Register

Vendor Inventory

Risk Tiering

Assessments

Remediation

129. Phase 9 — Audit

Prepare:

Control Evidence

Populations

Samples

Policies

Exceptions

Auditor Requests

130. Phase 10 — Continuous Assurance

Monitor:

Control Drift

New Assets

New Employees

New Vendors

Integration Health

Evidence Freshness

Failed Tests

131. Common Mistake — Tool Before Governance

Avoid:

Buy Vanta
      ↓
Figure Out
Compliance Later

Better:

Scope
      ↓
Requirements
      ↓
Controls
      ↓
Owners
      ↓
Automation

132. Common Mistake — Trust Every Green Test

A test can pass because:

Wrong Population

Missing Integration

Incorrect Scope

Weak Test Logic

133. Common Mistake — Ignore Integration Health

A disconnected integration may create:

False Assurance

134. Common Mistake — Pass Means Effective

A test passing today does not necessarily demonstrate:

Operating Effectiveness
Throughout the Period

135. Common Mistake — Fail Means Audit Finding

A failed test first requires:

Investigation

136. Common Mistake — Percentage-Only Reporting

Avoid:

98% Compliant

without explaining:

What Is
the Remaining 2%?

137. Common Mistake — Ignore Manual Controls

Not everything can be measured through an API.

Governance controls remain important.

138. Common Mistake — GRC Fixes Everything

GRC should coordinate.

Technical and business owners should remediate their controls.

139. Common Mistake — Permanent Exceptions

Every exception should have:

Owner

Risk

Approval

Compensating Control

Expiry

140. Common Mistake — Trust Center Oversharing

Customer assurance should not compromise organizational security.

141. End-to-End Example — MFA

Control:

IAM-001

Privileged Accounts
Require MFA

Integration:

Identity Provider

Population:

100 Administrators

Result:

99 Pass

1 Fail

Workflow:

Automated Test
      ↓
Failure
      ↓
Validate Account
      ↓
Risk Assessment
      ↓
Remediation
      ↓
Retest
      ↓
Pass

142. End-to-End Example — Endpoint Encryption

Population:

1,000 Devices

Vanta sees:

900 Devices

Results:

890 Encrypted

10 Unencrypted

Do not report:

98.9% Compliance

until resolving:

100 Missing Devices

143. End-to-End Example — Employee Training

HR:

800 Employees

Training:

780 Complete

Remaining:

10 New Hires

5 Terminated

5 Overdue

The GRC analyst determines:

Actual Exceptions
=
5

assuming the new hires are within an approved completion window and terminated personnel are correctly out of scope.

144. End-to-End Example — Vendor Security

New vendor:

Customer Analytics SaaS

Access:

Customer Personal Data

Workflow:

Vendor
      ↓
Risk Tiering
      ↓
Security Review
      ↓
Privacy Review
      ↓
Findings
      ↓
Contract
      ↓
Approval
      ↓
Monitoring

145. End-to-End Example — Audit

SOC 2
      ↓
Controls
      ↓
Automated Evidence
      +
Manual Evidence
      ↓
Control Testing
      ↓
Exceptions
      ↓
Auditor Review
      ↓
Report

Vanta Operational Checklist

Governance

compliance owner assigned.
framework scope approved.
control owners assigned.
evidence owners assigned.
risk owners assigned.
escalation model defined.

Controls

common control library established.
framework mappings reviewed.
control objectives documented.
control frequencies defined.
automated controls identified.
manual controls identified.

Integrations

authoritative systems identified.
scope validated.
least privilege applied.
integration credentials protected.
synchronization monitored.
connection failures alerted.
population completeness reconciled.

Automated Tests

test logic understood.
thresholds validated.
population understood.
failures investigated.
false positives managed.
control mappings reviewed.

Evidence

evidence mapped to controls.
evidence freshness monitored.
evidence period documented.
completeness validated.
reliability assessed.
manual evidence reviewed.

Personnel

authoritative HR population connected.
security training monitored.
policy acknowledgment monitored.
new-hire grace periods defined.
terminations monitored.

Devices

device population reconciled.
encryption monitored.
endpoint security monitored.
unmanaged devices identified.
device exceptions governed.

Identity

MFA monitored.
privileged users identified.
lifecycle controls monitored.
inactive accounts reviewed.

Cloud

cloud accounts inventoried.
scope validated.
encryption monitored.
logging monitored.
public exposure monitored.

Source Control

repositories inventoried.
production repositories identified.
branch protection reviewed.
code-review evidence maintained.
repository access reviewed.

Vulnerability Management

vulnerability source connected.
severity methodology defined.
remediation SLAs established.
overdue vulnerabilities monitored.
exceptions governed.

Risk

risk register established.
risk owners assigned.
controls mapped to risks.
treatments documented.
accepted risks reviewed.

Vendor Security

vendor inventory established.
criticality assigned.
risk tiering implemented.
assessments performed.
findings tracked.
reassessment scheduled.

Audit

audit scope confirmed.
evidence periods validated.
populations available.
exceptions documented.
auditor requests tracked.
evidence reuse validated.

Trust

Trust Center content approved.
public vs restricted content defined.
security responses reviewed.
sensitive evidence protected.
assurance documents maintained.

Vanta Deliverables

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

01 Vanta Compliance Operating Model

02 Framework Scope Register

03 Common Control Library

04 Framework Mapping Matrix

05 Control Ownership Matrix

06 Integration Inventory

07 Automated Test Register

08 Automated Evidence Matrix

09 Manual Evidence Register

10 Personnel Compliance Dashboard

11 Device Compliance Dashboard

12 Identity Compliance Dashboard

13 Cloud Compliance Dashboard

14 Vulnerability Compliance Dashboard

15 Compliance Exception Register

16 Risk Register

17 Vendor Security Register

18 Audit Readiness Dashboard

19 Trust Center Governance Model

20 Continuous Assurance Dashboard

Practical Activity — Design a Vanta Environment

Your organization uses:

AWS

Microsoft 365

Okta

GitHub

Jamf

HR Platform

and wants to support:

SOC 2

ISO 27001

Design:

Scope

Integrations

Controls

Automated Tests

Manual Controls

Evidence

Owners

Exceptions

Audit Workflow

Practical Activity — Population Reconciliation

HR population:

1,200 Employees

Identity population:

1,150 Users

Endpoint population:

1,050 Devices

Before reporting compliance, investigate:

Why Do
the Populations
Differ?

Determine:

authoritative source.
legitimate exclusions.
missing users.
unmanaged devices.
integration gaps.
scope differences.

Practical Activity — Failed MFA Test

Population:

150 Privileged Accounts

Result:

148 MFA Enabled

2 MFA Disabled

Determine:

Are Accounts
In Scope?

Interactive?

Approved Exception?

Business Risk?

Control Failure?

Remediation?

Retest?

Practical Activity — Code Review

Control:

Production Changes
Require Independent
Review

Vanta confirms:

Branch Protection
Enabled

Determine what additional evidence is required to establish:

Operating Effectiveness

during a six-month audit period.

Practical Activity — Vendor Assessment

Vendor:

Customer Support SaaS

Vendor processes:

Customer Name

Email

Support Tickets

Determine:

Criticality

Security Risk

Privacy Risk

Assessment Scope

Required Evidence

Contract Requirements

Findings

Residual Risk

Monitoring

Practical Activity — Audit Readiness

Dashboard:

150 Controls

138 Passing

5 Failing

7 Evidence Missing

Do not simply conclude:

92% Ready

Determine:

Which Controls Failed?

How Critical
Are They?

Which Frameworks
Are Affected?

What Evidence
Is Missing?

What Period
Is Required?

What Needs
Remediation?

What Needs
Auditor Review?

Practical Activity — Build a Trust Center

Design a Trust Center containing:

Security Overview

Compliance Certifications

Security FAQs

Approved Policies

Assurance Reports

Classify each item:

Public

Restricted

NDA Required

Internal Only

Vanta GRC Mindset

When working with Vanta, ask:

What Framework
Are We Supporting?

What Is
the Scope?

What Systems
Are In Scope?

What Data
Is In Scope?

What Controls
Apply?

Who Owns
Each Control?

Can the Control
Be Automated?

What Is
the Authoritative
Data Source?

Is the Integration
Healthy?

Is the Population
Complete?

What Does
the Test
Actually Measure?

What Does
Pass Mean?

What Does
Fail Mean?

Is There
an Exception?

What Risk
Does the Failure
Create?

Does the Evidence
Cover the Required
Period?

Does Configuration
Prove Design?

What Proves
Operating Effectiveness?

What Manual
Evidence Is Required?

Who Owns
Remediation?

Was Root Cause
Addressed?

Was the Control
Retested?

What Vendor
Risk Exists?

What Customer
Assurance Information
Can Be Shared?

What Must
Remain Confidential?

Are We
Actually Audit Ready?

Or Does
the Dashboard
Only Look Green?

What Material
Risk Should
Executives See?

How Can We
Move from
Audit Preparation
to Continuous
Assurance?

That is the mindset of a GRC professional using Vanta as a compliance and trust-management platform rather than simply as an automated checklist.

Key Takeaways

Vanta can support compliance automation, control monitoring, evidence collection, risk, vendor security, audit readiness, and trust operations.
Compliance automation does not automatically make an organization compliant.
Framework scope must be clearly defined before relying on platform results.
Common controls can reduce duplicated work across multiple frameworks.
Automated tests provide continuous visibility into selected technical control conditions.
A failed automated test requires investigation and context.
Passing automated tests do not automatically prove complete operating effectiveness.
Evidence must be relevant, reliable, complete, current, and appropriately scoped.
Population completeness is one of the most important considerations in automated compliance.
Missing integrations or incomplete scope can create false assurance.
Personnel, endpoint, identity, cloud, repository, and vulnerability systems can provide useful automated evidence.
Manual governance controls remain necessary.
Risk-based interpretation is more meaningful than simple compliance percentages.
Compliance exceptions should include documented risk, compensating controls, approval, and expiry.
Vendor security should follow a lifecycle from onboarding through monitoring and offboarding.
Security questionnaire automation should use approved and current responses.
Trust Centers can improve customer assurance but must not expose sensitive security information.
External auditors retain independent responsibility for evaluating evidence and reaching assurance conclusions.
Continuous monitoring identifies control drift between formal assessments.
Continuous compliance should be understood as ongoing visibility—not continuous certification.
Vanta should connect technical evidence with GRC governance, risk, remediation, audit, and customer trust.

Knowledge Check

Before continuing, make sure you can answer:

What is Vanta?
What is compliance automation?
What is continuous compliance?
What is a common control?
Why is framework mapping important?
What is an automated test?
What does a failed automated test actually mean?
Why must failed tests be investigated?
What is automated evidence?
What makes evidence reliable?
Why is evidence freshness important?
What is population completeness?
Why can incomplete integrations create false assurance?
What is integration health?
Why should integrations follow least privilege?
What personnel controls can be monitored?
How can termination controls use cross-system evidence?
What device controls can be monitored?
What identity controls can be monitored?
What cloud controls can be monitored?
How can source-control systems support compliance evidence?
What is the difference between design and operating effectiveness?
How can vulnerability management support compliance?
How should compliance exceptions be governed?
How should risk management connect to compliance?
What is vendor security management?
Why should vendors be risk-tiered?
What is a security questionnaire response library?
What is a Trust Center?
What information should not be published in a Trust Center?
How can Vanta support audit readiness?
Why does Vanta not replace an external auditor?
Why does 100% test completion not necessarily mean compliance?
What is control drift?
What is continuous assurance?

What’s Next?

➡️ Next: 08 — AuditBoard

In the next lesson, you will move from compliance automation into a platform focused heavily on audit, risk, controls, compliance, and enterprise assurance management.

You will explore how AuditBoard can support:

Enterprise Risk
      ↓
Risk Assessments
      ↓
Controls
      ↓
Internal Audit
      ↓
Audit Planning
      ↓
Testing
      ↓
Evidence
      ↓
Findings
      ↓
Remediation
      ↓
Executive Reporting

The focus will be on understanding how a modern audit and risk platform can connect internal audit, SOX and controls management, enterprise risk management, compliance, issue management, evidence, remediation, and executive assurance reporting.