06 Drata

Traditional compliance programs often rely on:

Spreadsheets

Screenshots

Email Requests

Shared Folders

Manual Evidence Collection

Point-in-Time Reviews

This creates recurring problems:

Evidence Becomes Stale

Control Owners Miss Requests

Auditors Ask for the Same Data Again

Compliance Teams Repeat Manual Work

Control Failures Are Identified Too Late

Modern compliance automation platforms such as Drata aim to reduce this manual burden by connecting directly to enterprise systems and continuously evaluating selected compliance controls.

A simplified model looks like:

Cloud Platforms
      ↓
Identity Providers
      ↓
Endpoints
      ↓
HR Systems
      ↓
Source Control
      ↓
Security Tools
      ↓
Drata
      ↓
Automated Tests
      ↓
Control Evidence
      ↓
Framework Mapping
      ↓
Compliance Readiness
      ↓
Audit Support

For a GRC professional, Drata should not be viewed simply as:

A Tool That
Makes You Compliant

Instead:

Compliance Program
      +
Controls
      +
Connected Systems
      +
Automated Evidence
      +
Human Validation
      =
Continuous Compliance

Learning Objectives

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

Explain what Drata is.
understand compliance automation.
distinguish continuous compliance from point-in-time assessments.
understand automated control testing.
understand evidence automation.
understand framework mapping.
understand control libraries.
understand personnel compliance.
understand device compliance.
understand identity evidence.
understand cloud-security evidence.
understand source-control evidence.
understand policy management.
understand risk management concepts.
understand issue and remediation tracking.
understand audit readiness.
understand auditor collaboration.
understand security questionnaire workflows.
understand integrations.
understand continuous monitoring.
understand compliance dashboards.
understand automated evidence limitations.
validate automated evidence.
design a practical Drata operating model.
integrate Drata with broader enterprise GRC processes.

1. What Is Drata?

Drata is a compliance automation and security assurance platform.

It can help organizations manage activities such as:

Controls

Frameworks

Evidence

Automated Tests

Policies

Risks

Personnel Compliance

Device Compliance

Audit Readiness

Remediation

Exact functionality depends on the organization’s subscription, integrations, and platform version.

2. Traditional Compliance Model

Traditional compliance often works like:

Audit Scheduled
      ↓
Compliance Team
Requests Evidence
      ↓
Control Owners
Send Screenshots
      ↓
Evidence Reviewed
      ↓
Auditor Tests
      ↓
Findings
      ↓
Audit Ends

Several months later:

Repeat
Everything

3. Continuous Compliance Model

Drata-style automation attempts to move toward:

Systems
      ↓
Continuous Data
      ↓
Control Tests
      ↓
Evidence
      ↓
Exceptions
      ↓
Remediation
      ↓
Readiness

4. Why Compliance Automation Matters

Consider an organization supporting:

SOC 2

ISO 27001

PCI DSS

HIPAA

Internal Security Controls

Without mapping and automation:

SOC 2 Team
Requests MFA Evidence

ISO Team
Requests MFA Evidence

PCI Team
Requests MFA Evidence

Internal Audit
Requests MFA Evidence

This creates:

Duplicate Work

5. Common Control Model

Better:

Enterprise MFA Control
      ↓
Automated Evidence
      ↓
Mapped to:
SOC 2
ISO 27001
PCI DSS
Internal Policy

where requirements and testing criteria align.

6. Controls

A control represents:

An activity designed to satisfy a security, compliance, privacy, or governance objective.

Example:

IAM-001

All privileged accounts
must use multi-factor
authentication.

7. Control Record

A useful control record may include:

Control ID

Description

Owner

Frequency

Evidence

Framework Mapping

Automation Status

Test Status

8. Control Framework Mapping

One control can potentially support several compliance requirements.

Example:

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

9. Why Mapping Matters

Without mapping:

Multiple Frameworks
      ↓
Duplicate Controls
      ↓
Duplicate Evidence
      ↓
Duplicate Testing

With mapping:

Common Controls
      ↓
Shared Evidence
      ↓
Multiple Frameworks

10. Automated Tests

An automated test uses connected system data to evaluate whether a control condition is satisfied.

Example:

Control:

Administrators
Must Use MFA

Automated test:

Identity Provider
      ↓
Privileged Accounts
      ↓
MFA Status
      ↓
Pass / Fail

11. Test Result Example

Population:

250 Privileged Accounts

Results:

248 MFA Enabled

2 MFA Disabled

Automated test:

Fail

if the requirement is:

100%

12. Automation Does Not Replace Control Judgment

The platform may tell you:

Test Failed

GRC still needs to determine:

What Failed?

What Is In Scope?

Is the Population Complete?

Is There an Approved Exception?

What Is the Risk?

Is the Control Ineffective?

13. Evidence Automation

Traditional evidence:

Screenshot
      ↓
Uploaded
      ↓
Reviewed

Automated evidence:

Source System
      ↓
Integration
      ↓
System Data
      ↓
Control Evidence

14. Potential Evidence Sources

Organizations may connect systems such as:

Cloud Platforms

Identity Providers

Endpoint Management

HR Platforms

Source Control

Ticketing Systems

Security Tools

15. Evidence Example — Identity

Control:

All Employees
Must Have MFA

Source:

Identity Provider

Evidence:

User Population

MFA Enrollment

Privileged Role Status

16. Evidence Example — Cloud

Control:

Production Data
Must Be Encrypted

Source:

Cloud Platform

Evidence:

Resource Inventory

Encryption Configuration

17. Evidence Example — Endpoint

Control:

Company Endpoints
Must Use Disk Encryption

Source:

Endpoint Management

Evidence:

Managed Devices

Encryption Status

18. Evidence Example — Source Control

Control:

Production Code
Changes Require Review

Source:

Source Control Platform

Evidence may include:

Repository Settings

Branch Protection

Pull Requests

Approvals

19. Evidence Example — HR

Control:

Security Training
Must Be Completed
by Employees

Sources may include:

HR System

Training Platform

Evidence:

Employee Population

Completion Status

Termination Status

20. Evidence Freshness

A major advantage of automation is:

Current Evidence

rather than:

Screenshot
from
6 Months Ago

21. Continuous Evidence

Conceptually:

Monday
Pass

Tuesday
Pass

Wednesday
Fail

Thursday
Fail

Friday
Pass

This tells a very different story than:

Friday Screenshot
=
Pass

22. Point-in-Time vs Continuous Control

Point-in-time evidence:

Control Status
Today

Continuous evidence:

Control Status
Throughout
the Period

This distinction is important during audit testing.

23. Control Monitoring

A monitored control may follow:

Evidence Source
      ↓
Automated Test
      ↓
Pass / Fail
      ↓
Control Status

24. Test Failure

When a test fails:

Failure
      ↓
Investigation
      ↓
Exception?
      ↓
Remediation?
      ↓
Retest

25. Not Every Failed Test Is a Formal Finding

Example:

One Laptop
Not Encrypted

could represent:

Recently Issued Device

Decommissioned Device

Temporary Configuration Gap

Actual Control Failure

The GRC professional must validate context.

26. Population Completeness

Suppose Drata reports:

950 Devices

940 Compliant

10 Failed

But the enterprise inventory contains:

1,200 Devices

The bigger issue is:

Where Are
the Missing 250?

27. Evidence Pipeline Validation

Always understand:

Source
      ↓
Integration
      ↓
Data Collection
      ↓
Transformation
      ↓
Control Test
      ↓
Result

28. Integration Scope

Ask:

Which Accounts?

Which Subscriptions?

Which Cloud Regions?

Which Repositories?

Which Users?

Which Devices?

29. Integration Risk

An automated test may incorrectly show:

Pass

if:

Production Account
Was Never Connected

30. Integration Health

A mature compliance program should monitor:

Integration Connected?

Last Sync?

Errors?

Missing Scope?

Authentication Valid?

31. Frameworks

Drata can help organizations organize compliance activities against frameworks and standards.

Examples may include:

SOC 2

ISO 27001

PCI DSS

HIPAA

Privacy Requirements

Custom Frameworks

Availability depends on the platform and subscription.

32. Framework Readiness

Conceptually:

Framework
      ↓
Requirements
      ↓
Mapped Controls
      ↓
Evidence
      ↓
Tests
      ↓
Readiness

33. Readiness Is Not Certification

A dashboard might show:

95%
Ready

This does not automatically mean:

Certified

or:

Compliant

34. Why?

Formal assurance may require:

Auditor Testing

Defined Scope

Period of Operation

Evidence Evaluation

Exceptions

Management Assertions

35. Compliance Score

Treat platform-generated scores as:

Management
Readiness Indicators

not:

Legal Determinations

36. Multi-Framework Compliance

Imagine:

Control:
Employee MFA

It may support:

SOC 2

ISO 27001

PCI DSS

Internal Security Policy

A shared control model allows:

Evidence Once
      ↓
Use Across
Mapped Requirements

37. Common Control Library

A practical enterprise library might include:

IAM-001
MFA

IAM-002
Access Review

HR-001
Background Checks

HR-002
Security Training

DEV-001
Code Review

DEV-002
Branch Protection

END-001
Endpoint Encryption

VM-001
Vulnerability Management

38. Control Ownership

Every control should have:

Control Owner

Examples:

IAM
→ Identity Team

Security Training
→ HR / Security

Code Review
→ Engineering

Endpoint Encryption
→ IT

39. Control Owner Responsibilities

Control owners should:

Operate Control

Maintain Control

Resolve Exceptions

Provide Context

Support Testing

40. GRC Team Responsibility

GRC typically:

Defines Requirements

Maps Controls

Reviews Evidence

Tracks Exceptions

Coordinates Audits

Monitors Readiness

41. Personnel Compliance

Compliance programs frequently include personnel-related controls.

Examples:

Employment Agreements

Background Screening

Security Training

Policy Acknowledgment

Termination Procedures

42. Personnel Population

A key requirement:

Who Is
an Active Employee?

Source should generally be:

Authoritative
HR System

43. Employee Example

HR population:

500 Employees

Security training:

493 Complete

7 Overdue

Control coverage:

98.6%

44. Is 98.6% Effective?

Depends on:

Requirement

Timing

New Hire Grace Period

Approved Exceptions

Risk

45. Policy Acknowledgment

Organizations may require employees to acknowledge policies.

Example:

Information Security Policy

Acceptable Use Policy

Code of Conduct

46. Policy Lifecycle

Draft
      ↓
Review
      ↓
Approval
      ↓
Publish
      ↓
Employee Acknowledgment
      ↓
Periodic Review

47. Policy Evidence

Potential evidence:

Policy Version

Approver

Effective Date

Employee Acknowledgment

Review Date

48. Device Compliance

Endpoint controls may include:

Disk Encryption

Screen Lock

Antivirus / EDR

OS Version

Device Management

Firewall

49. Device Example

Population:

600 Managed Devices

Encryption status:

590 Encrypted

10 Unencrypted

50. Device Exception Analysis

Ask:

Which Devices?

Who Owns Them?

Production Access?

Sensitive Data?

New Device?

Decommissioned?

Approved Exception?

51. Identity Controls

Identity integrations can support controls such as:

MFA

User Lifecycle

Privileged Roles

Password Requirements

Account Disablement

52. Termination Example

Control:

Terminated Employee
Access Removed
Within 24 Hours

Evidence sources:

HR System

Identity Provider

Testing:

Termination Time
      ↓
Account Disable Time
      ↓
SLA Result

53. Automated Cross-System Evidence

This is powerful because:

HR
      +
Identity
      ↓
Control Test

can evaluate lifecycle controls more reliably than a single screenshot.

54. Cloud Compliance

Cloud integrations may help monitor controls such as:

Encryption

Logging

Public Exposure

MFA

Backup

Network Configuration

55. Example — Public Storage

Control:

Cloud Storage
Must Not Be
Public

Automated test:

Cloud Inventory
      ↓
Storage Resources
      ↓
Public Access
      ↓
Pass / Fail

56. Source-Control Compliance

Engineering controls may include:

Branch Protection

Code Review

Change Approval

Restricted Repository Access

Secure SDLC

57. Code Review Example

Control:

Production Changes
Require Independent
Review

Evidence:

Pull Request

Reviewer

Approval

Merge

58. Important Limitation

A configuration saying:

Branch Protection
Enabled

does not always prove:

Every Production
Change Followed
the Process

Operating-effectiveness testing may still be necessary.

59. Risk Management

Compliance automation platforms may also support organizational risk registers.

A risk record may include:

Risk

Owner

Likelihood

Impact

Controls

Residual Risk

Treatment

60. Risk Example

Risk:
Unauthorized Access
to Production Systems

Owner:
CTO

Inherent Risk:
High

Controls:
MFA
Access Review
Logging

Residual Risk:
Medium

61. Compliance Failure → Risk

Example:

MFA Test
Fails
      ↓
Privileged Accounts
Without MFA
      ↓
Unauthorized Access
Risk

62. Risk Is Not the Same as Failed Test

Failed test:

2 Accounts
Without MFA

Risk:

Stolen credentials
could allow unauthorized
privileged access to
production systems.

63. Risk Treatment

Common approaches:

Mitigate

Accept

Avoid

Transfer

64. Risk Acceptance

A GRC program should capture:

Risk

Business Reason

Residual Exposure

Compensating Controls

Approver

Review Date

65. Issues and Findings

A failed test may lead to:

Control Exception

A broader pattern may lead to:

Compliance Finding

66. Issue Workflow

Issue
      ↓
Validate
      ↓
Assign
      ↓
Remediate
      ↓
Evidence
      ↓
Retest
      ↓
Close

67. Example

Test:

Endpoint Encryption

Result:

10 Devices
Unencrypted

Root cause:

New Device Provisioning
Workflow Does Not
Enforce Encryption

Remediation:

Encrypt Devices
+
Update Provisioning
+
Monitor Continuously

68. Remediation Tracking

Useful fields:

Issue ID

Control

Owner

Severity

Action

Due Date

Status

Evidence

Retest

69. Exceptions

Some failed tests may have legitimate approved exceptions.

Example:

Legacy Server
Cannot Support
Required Agent

Exception process:

Request
      ↓
Risk
      ↓
Compensating Control
      ↓
Approval
      ↓
Expiry

70. Exception ≠ Pass

The automated test may still show:

Fail

while the governance process shows:

Approved Exception

Both pieces of information matter.

71. Audit Readiness

One major use case for Drata is reducing the burden of preparing for external audits.

Traditional:

Audit Starts
      ↓
Find Evidence
      ↓
Organize Files
      ↓
Answer Requests

Automated:

Controls
      ↓
Evidence
      ↓
Continuous Monitoring
      ↓
Audit Workspace

72. Audit Evidence Package

For each control, auditors may need:

Control Description

Owner

Evidence

Population

Sample

Configuration

Exceptions

Period

73. Auditor Collaboration

A compliance platform can help centralize:

Requests

Evidence

Comments

Control Status

Exceptions

instead of managing everything by email.

74. Auditor Independence

Important:

A platform helping collect evidence does not replace the auditor’s independent judgment.

The auditor may still:

Request More Evidence

Validate Population

Select Samples

Reperform Tests

Challenge Conclusions

75. Evidence Reuse

Evidence may sometimes support multiple audits.

Example:

MFA Evidence
      ↓
SOC 2

ISO 27001

PCI DSS

but the required:

Scope

Period

Control Objective

must align.

76. Evidence Reuse Limitation

Do not assume:

Evidence Exists
      ↓
Evidence Valid
for Every Framework

77. Security Questionnaires

Organizations frequently receive customer questionnaires.

Typical questions:

Do You Use MFA?

Do You Encrypt Data?

Do You Conduct
Penetration Testing?

Do You Have
Incident Response?

Are Employees
Security Trained?

78. Questionnaire Challenge

A security team may answer:

Same 200 Questions

for:

50 Customers

79. Questionnaire Automation

A compliance platform may help reuse:

Approved Responses

Evidence

Policies

Control Information

to speed up responses.

80. Response Governance

Avoid automatically sending:

Old

Unapproved

Inaccurate

responses.

Maintain:

Approved Answer

Owner

Evidence

Last Review

81. Trust Center Concept

Organizations may publish selected assurance information for:

Customers

Prospects

Partners

Examples:

Certifications

Security Overview

Policies

Trust Documentation

82. Do Not Overshare

A trust center should not expose:

Security Weaknesses

Sensitive Architecture

Internal Findings

Confidential Evidence

83. Integration Architecture

Conceptually:

HR ───────────┐
IAM ──────────┤
Cloud ────────┤
Endpoints ────┼──→ Drata
Source Control┤
Security ─────┘
               ↓
          Control Tests
               ↓
            Evidence
               ↓
          Compliance

84. Integration Governance

For each integration define:

Owner

Authentication

Scope

Permissions

Sync Frequency

Failure Alerting

Data Retention

85. Least Privilege

Drata integrations should receive only the permissions necessary to perform their intended function.

Avoid:

Administrator Access
Everywhere

when:

Read-Only

access is sufficient.

86. Connector Security

Integrations themselves create:

Security Dependencies

Protect:

API Credentials

Service Accounts

Tokens

Integration Permissions

87. Integration Monitoring

Track:

Connected?

Healthy?

Last Sync?

Errors?

Scope Changed?

88. Continuous Monitoring

The strongest compliance-automation model moves from:

Audit Preparation

to:

Control Monitoring
Every Day

89. Example Continuous Controls

MFA Coverage

Device Encryption

Endpoint Protection

Cloud Encryption

Public Cloud Exposure

User Termination

Security Training

Repository Protection

90. Manual Controls Remain

Not every control can be automated.

Examples:

Annual Risk Assessment

Board Oversight

Incident Exercise

Vendor Due Diligence

Policy Approval

Internal Audit

91. Hybrid Control Model

Automated Controls
      +
Manual Controls
      ↓
Compliance Program

92. Manual Evidence

Examples:

Meeting Minutes

Signed Policy

Risk Assessment

Training Material

Penetration Test Report

Board Report

93. Evidence Governance

All evidence should still be:

Relevant

Reliable

Complete

Current

Traceable

94. Evidence Status

Possible states:

Collected

Pending

Needs Review

Accepted

Rejected

Expired

95. Evidence Expiration

Some evidence becomes stale.

Example:

Penetration Test
Older Than
Required Period

The platform should support identifying:

Evidence
Needs Refresh

96. Compliance Dashboard

A useful dashboard might display:

Controls Passing

Controls Failing

Automated Tests

Outstanding Evidence

Framework Readiness

Open Issues

Overdue Actions

Integration Health

97. Executive Dashboard

Executives need:

Major Compliance Gaps

Material Risks

Audit Readiness

Overdue Remediation

Framework Status

Risk Trend

98. Control Owner Dashboard

Control owners may need:

My Controls

Failed Tests

Evidence Due

Issues

Upcoming Reviews

99. GRC Dashboard

GRC needs:

Framework Coverage

Control Effectiveness

Evidence Health

Exceptions

Findings

Remediation

Audit Status

100. Readiness Trend

Example:

January
82%

February
87%

March
93%

April
96%

This may indicate improving readiness.

But always ask:

What Controls
Still Fail?

101. Percentage Can Mislead

Imagine:

99%
Controls Passing

but the 1% failure is:

Privileged MFA

A simple score may hide material risk.

102. Risk-Based Readiness

Use:

Control Status
      +
Control Criticality
      +
Risk

not just:

Percentage

103. Continuous Compliance ≠ Continuous Certification

Important distinction:

Continuous Monitoring

does not automatically mean:

Continuous Formal
Certification

External assurance remains governed by the relevant standard and audit methodology.

104. Automated Test ≠ Audit Opinion

An automated result may contribute to:

Audit Evidence

but does not independently provide:

Audit Opinion

105. Compliance Automation Maturity

A practical maturity model:

Level 1
Manual Evidence

Level 2
Centralized Evidence

Level 3
Connected Systems

Level 4
Automated Testing

Level 5
Continuous Assurance

106. Level 1 — Manual

Spreadsheets

Screenshots

Email

107. Level 2 — Centralized

Controls

Evidence

Policies

stored in one platform.

108. Level 3 — Integrated

Cloud

IAM

HR

Endpoints

Repositories

connected.

109. Level 4 — Automated

Data
      ↓
Automated Tests
      ↓
Pass / Fail

110. Level 5 — Continuous Assurance

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

111. Implementation Roadmap

A practical Drata implementation could follow:

Phase 1
Scope

Phase 2
Frameworks

Phase 3
Controls

Phase 4
Owners

Phase 5
Integrations

Phase 6
Evidence

Phase 7
Automation

Phase 8
Remediation

Phase 9
Audit

Phase 10
Continuous Monitoring

112. Phase 1 — Scope

Define:

Legal Entities

Products

Systems

Cloud Accounts

Employees

Locations

Audit Boundaries

113. Phase 2 — Frameworks

Identify:

SOC 2

ISO 27001

PCI DSS

Other Requirements

that actually apply.

114. Phase 3 — Controls

Establish:

Control Library

Mappings

Control Frequency

Evidence Requirements

115. Phase 4 — Ownership

Assign:

Control Owners

Policy Owners

Risk Owners

Evidence Owners

116. Phase 5 — Integrations

Connect authoritative systems.

Prioritize high-value sources such as:

IAM

HR

Cloud

Endpoints

Source Control

117. Phase 6 — Evidence

Validate:

Evidence Source

Scope

Period

Quality

Completeness

118. Phase 7 — Automation

Enable:

Automated Tests

Evidence Sync

Notifications

Reminders

119. Phase 8 — Remediation

Define:

Issue

Owner

Severity

Due Date

Evidence

Retest

Closure

120. Phase 9 — Audit

Prepare:

Control Evidence

Policies

Populations

Exceptions

Audit Requests

121. Phase 10 — Continuous Monitoring

Track:

Control Drift

Integration Health

New Assets

New Employees

New Risks

Failed Tests

122. Common Mistake — Connect Everything Immediately

Weak:

Connect 50 Systems
on Day One

Better:

Prioritize
High-Value
Authoritative Systems

123. Common Mistake — Trust Every Automated Test

A test can be wrong because of:

Bad Scope

Broken Integration

Wrong Logic

Missing Population

Incorrect Mapping

124. Common Mistake — Pass = Effective

A test showing:

Pass

today does not necessarily prove:

Control Effective
for Entire Audit Period

125. Common Mistake — Fail = Finding

A failed test needs:

Validation

Context

Risk Assessment

126. Common Mistake — Compliance Score = Compliance

Never assume:

100% Dashboard

automatically equals:

Formal Compliance

127. Common Mistake — Ignore Manual Controls

Important governance controls cannot always be automated.

128. Common Mistake — GRC Owns Every Remediation

The responsible business or technical owner should remediate the control.

129. Common Mistake — Ignore Integration Failures

A disconnected connector may silently create:

False Assurance

130. Common Mistake — Evidence Dump

Uploading:

Thousands of Files

without:

Control Mapping

Period

Owner

Context

creates weak assurance.

131. Common Mistake — Audit Preparation Only

If the platform is used only:

Two Months
Before Audit

the organization misses much of the value of continuous monitoring.

132. End-to-End Example — MFA

Control:

IAM-001

Privileged accounts
must use MFA.

Integration:

Identity Provider

Population:

250 Accounts

Test:

MFA Enabled?

Result:

248 Pass

2 Fail

Workflow:

Automated Test
      ↓
Failed
      ↓
Validate Accounts
      ↓
Control Exception
      ↓
Risk
      ↓
Remediation
      ↓
Retest
      ↓
Pass

133. End-to-End Example — Endpoint Encryption

Control:

END-001

Corporate endpoints
must use full-disk
encryption.

Population:

600 Devices

Results:

590 Pass

10 Fail

Investigation:

6 New Devices

2 Decommissioned

2 Production

Actual exceptions:

134. End-to-End Example — User Termination

HR:

Employee Terminated
10:00

Identity:

Account Disabled
16:00

Control:

Within 24 Hours

Result:

Pass

This shows the value of:

Cross-System
Automated Evidence

135. End-to-End Example — Code Review

Control:

All Production
Changes Require
Independent Review

Integration:

Source Control

Evidence:

Pull Requests

Approvals

Branch Protection

But audit may still need to determine:

Were All Production
Changes Included?

136. End-to-End Example — Security Training

HR population:

500 Employees

Training:

493 Complete

7 Overdue

Assessment:

Requirement:
100%
Within 30 Days
of Hire

Investigate whether the seven users are:

New Hires

Late

Terminated

Approved Exceptions

137. End-to-End Audit Readiness

Framework
      ↓
Controls
      ↓
Owners
      ↓
Evidence
      ↓
Automated Tests
      ↓
Manual Tests
      ↓
Exceptions
      ↓
Remediation
      ↓
Auditor

Drata Operational Checklist

Governance

compliance operating model defined.
applicable frameworks identified.
scope approved.
control owners assigned.
risk owners assigned.
evidence responsibilities defined.

Controls

control library established.
duplicate controls rationalized.
framework mappings reviewed.
control frequency documented.
automated vs manual status defined.
evidence requirements documented.

Integrations

authoritative systems identified.
connection owner assigned.
scope validated.
permissions reviewed.
least privilege applied.
synchronization monitored.
integration failures alerted.

Evidence

evidence source documented.
evidence scope validated.
population completeness assessed.
assessment period confirmed.
freshness monitored.
expired evidence refreshed.
evidence mapped to controls.

Automated Tests

test logic understood.
control mapping validated.
test population understood.
thresholds approved.
failures investigated.
false positives managed.
test changes governed.

Personnel

HR population reconciled.
training monitored.
policy acknowledgments tracked.
new hires monitored.
terminations monitored.

Devices

device inventory validated.
encryption monitored.
endpoint protection monitored.
device exceptions investigated.
unmanaged devices identified.

Identity

MFA monitored.
privileged roles monitored.
termination timing monitored.
lifecycle exceptions reviewed.

Cloud

cloud accounts in scope identified.
encryption monitored.
logging monitored.
public exposure monitored.
critical configuration failures tracked.

Source Control

repositories identified.
branch protection reviewed.
code-review controls assessed.
access reviewed.
production-change population understood.

Policies

required policies maintained.
owners assigned.
reviews scheduled.
approvals documented.
acknowledgments captured where required.

Risks

risk register maintained.
control failures linked to risk.
risk owners assigned.
treatments documented.
accepted risks reviewed.

Issues

failed tests triaged.
control exceptions documented.
systemic issues identified.
owners assigned.
due dates defined.
remediation evidence collected.
retesting required.

Audit

audit scope aligned.
evidence organized.
periods validated.
auditor requests tracked.
populations available.
exceptions disclosed.
evidence reuse validated.

Reporting

readiness dashboard maintained.
failed controls visible.
outstanding evidence visible.
integration health visible.
overdue remediation visible.
material risks highlighted.

Drata Deliverables

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

01 Compliance Automation Operating Model

02 Common Control Library

03 Framework Mapping Matrix

04 Integration Inventory

05 Automated Evidence Matrix

06 Automated Test Register

07 Manual Control Register

08 Personnel Compliance Dashboard

09 Device Compliance Dashboard

10 Identity Compliance Dashboard

11 Cloud Compliance Dashboard

12 Evidence Validation Procedure

13 Compliance Exception Register

14 Remediation Tracker

15 Risk Register

16 Audit Readiness Dashboard

17 Auditor Evidence Index

18 Security Questionnaire Response Library

19 Continuous Compliance Dashboard

20 Drata-to-Enterprise-GRC Integration Model

Practical Activity — Design a Drata Environment

Scenario:

Your organization uses:

AWS

Microsoft 365

GitHub

Okta

Jamf

HR Platform

and wants to prepare for:

SOC 2

ISO 27001

Design:

Integrations

Common Controls

Automated Tests

Manual Controls

Evidence

Owners

Exceptions

Audit Workflow

Practical Activity — MFA Control

Control:

All Privileged
Accounts Require MFA

Identity population:

300 Accounts

Results:

296 MFA Enabled

4 MFA Disabled

Determine:

Control Coverage

Evidence Quality

Test Result

Exception Validation

Business Risk

Remediation

Retest

Practical Activity — Device Encryption

Inventory:

1,000 Devices

Drata-connected device population:

Of the 900:

890 Encrypted

10 Not Encrypted

Determine:

Is Encryption
Coverage 98.9%?

Or Is There
a Population Problem?

What Must
Be Investigated
First?

Practical Activity — Security Training

HR:

700 Employees

Training platform:

680 Completed

The remaining 20 include:

8 New Hires
Within Grace Period

4 Terminated Users

8 Overdue

Determine:

Actual Exceptions

Control Result

Remediation

Evidence

Practical Activity — Code Review

Requirement:

Production Code
Requires Independent
Review

Repository configuration:

Branch Protection
Enabled

Determine what additional evidence is required to prove:

Operating Effectiveness

rather than just:

Control Design

Practical Activity — Continuous Monitoring

Build automated monitoring for:

MFA

Endpoint Encryption

Security Training

Cloud Encryption

Public Storage

Repository Protection

For each define:

Control

Source System

Population

Automated Test

Threshold

Frequency

Owner

Exception Rule

Escalation

Practical Activity — Audit Readiness

Formal audit starts in:

60 Days

Dashboard shows:

120 Controls

108 Passing

7 Failing

5 Evidence Missing

Determine:

Which Controls
Are Critical?

What Evidence
Needs Refresh?

Which Failures
Require Remediation?

Which Controls
Need Operating History?

Are We
Actually Ready?

Drata GRC Mindset

When working with Drata, ask:

What Frameworks
Actually Apply?

What Is
in Scope?

What Controls
Do We Need?

Can We
Use Common Controls?

Who Owns
Each Control?

Which Controls
Can Be Automated?

Which Must
Remain Manual?

What Is
the Authoritative
Evidence Source?

Is the Integration
Healthy?

Is the Population
Complete?

What Does
the Automated Test
Actually Check?

Is the Test
Mapped Correctly?

What Period
Does the Evidence
Cover?

Is the Evidence
Current?

What Does
a Failed Test Mean?

Is It
a False Positive?

An Exception?

A Control Failure?

A GRC Finding?

What Risk
Does It Create?

Who Owns
Remediation?

How Will
We Retest?

Is There
an Approved Exception?

When Does
the Exception Expire?

Does a
Passing Test
Prove Operating
Effectiveness?

Can the
Auditor Reperform
the Evidence?

Are We
Ready for Audit?

Or Does
the Dashboard
Only Look Green?

What Should
Executives See?

How Does
Drata Connect
to Our Broader
GRC Program?

That is the mindset of a GRC professional using a compliance automation platform.

Key Takeaways

Drata can support compliance automation, continuous monitoring, evidence collection, audit readiness, and control management.
Compliance automation reduces repetitive manual evidence requests.
A common-control approach can reduce duplicate testing across multiple frameworks.
Automated tests use connected system data to evaluate selected control conditions.
Automated tests do not replace professional judgment.
Evidence automation can improve freshness, consistency, and traceability.
Integration scope must be validated before relying on automated evidence.
Population completeness is essential for accurate control conclusions.
A disconnected or incomplete integration can create false assurance.
Point-in-time evidence is different from period-of-operation evidence.
Passing automated tests do not always prove full operating effectiveness.
Failed automated tests do not automatically become formal GRC findings.
Personnel, endpoint, identity, cloud, and source-control systems can provide valuable automated evidence.
Manual governance controls remain important and cannot always be automated.
Platform readiness percentages should not be treated as certification or legal compliance conclusions.
Formal audits still require independent auditor judgment.
Evidence reuse is valuable only when scope, control objective, and assessment period align.
Exceptions should include risk, approval, compensating controls, and expiry.
Remediation should address root cause and should normally be retested before closure.
Integration credentials and permissions should follow least privilege.
Integration health should itself be monitored.
Compliance dashboards should highlight material control failures rather than only percentages.
Continuous compliance is best understood as ongoing control visibility, not continuous certification.
Strong compliance automation connects controls, authoritative data, evidence, risk, remediation, and independent assurance.

Knowledge Check

Before continuing, make sure you can answer:

What is Drata?
What is compliance automation?
How does continuous compliance differ from traditional compliance?
What is an automated control test?
Why does an automated test not replace professional judgment?
What is automated evidence?
What systems can provide automated compliance evidence?
Why is evidence freshness important?
What is the difference between point-in-time and period evidence?
What is a common control?
How can common controls reduce duplicated compliance work?
Why is framework mapping important?
What is control ownership?
What personnel controls can be monitored?
What device controls can be automated?
What identity controls can be monitored?
How can cloud integrations support compliance?
How can source-control integrations support evidence?
Why does branch protection alone not prove operating effectiveness?
Why must population completeness be validated?
What risks arise from incomplete integrations?
Why should integration health be monitored?
Why does a high readiness score not prove formal compliance?
What is audit readiness?
How can auditor collaboration be improved through a compliance platform?
Why does evidence reuse require scope validation?
What is a compliance exception?
Why should approved exceptions expire?
What is a compliance finding?
How should failed automated tests be triaged?
Why should remediation address root cause?
Why should findings be retested?
What is a security questionnaire response library?
Why does continuous monitoring not mean continuous certification?
How should Drata integrate with a broader enterprise GRC program?

What’s Next?

➡️ Next: 07 — Vanta

In the next lesson, you will continue with modern compliance automation and examine how Vanta can support:

Frameworks
      ↓
Controls
      ↓
Integrations
      ↓
Automated Tests
      ↓
Evidence
      ↓
Personnel
      ↓
Devices
      ↓
Risks
      ↓
Vendor Security
      ↓
Audit Readiness
      ↓
Trust

You will learn how Vanta can support continuous compliance monitoring, control testing, evidence automation, security reviews, personnel and device compliance, risk management, vendor security, audit collaboration, trust-center workflows, and multi-framework compliance operations.