Runbook 01 Security Control Assessment & Evidence Collection

Runbook Information

Item	Details
Runbook	01 — Security Control Assessment & Evidence Collection
Module	01 — GRC Fundamentals
Difficulty	Intermediate
Estimated Time	90–120 Minutes
Primary Role	GRC Analyst / Control Assessor
Supporting Roles	Control Owner, Internal Audit, Security, Compliance
Primary Output	Control Assessment Record & Evidence Package
Runbook Type	Operational GRC Procedure

Purpose

This runbook provides a repeatable process for assessing enterprise security controls and collecting sufficient evidence to determine whether controls are:

Designed Appropriately
        +
Implemented
        +
Operating Consistently
        =
Effective Control

The procedure can support:

Internal control assessments.
Compliance reviews.
Certification programs.
Internal audits.
External audits.
Customer assurance.
Risk assessments.
Continuous control monitoring.

The objective is not simply to collect documents.

The objective is to answer:

Does the control actually reduce the intended risk, and can we demonstrate that conclusion with reliable evidence?

Runbook Outcomes

After following this runbook, the assessor should be able to produce:

Defined control scope.
Confirmed control ownership.
Control design assessment.
Evidence request.
Evidence inventory.
Population validation.
Sampling methodology.
Test procedures.
Test results.
Exceptions.
Effectiveness conclusion.
Findings.
Remediation actions.
Retest results.
Final control status.

Operational Workflow

Control Selected
      ↓
Understand Requirement
      ↓
Confirm Scope
      ↓
Identify Owner
      ↓
Understand Control Design
      ↓
Define Evidence
      ↓
Request Evidence
      ↓
Validate Evidence
      ↓
Validate Population
      ↓
Select Samples
      ↓
Test Design
      ↓
Test Operating Effectiveness
      ↓
Document Exceptions
      ↓
Determine Control Effectiveness
      ↓
Create Finding
      ↓
Remediation
      ↓
Retest
      ↓
Close / Continue Monitoring

Phase 1 — Initiate the Assessment

Step 1 — Identify the Control

Start with the control being assessed.

Example:

Control ID:
IAM-010

Control Name:
Quarterly Privileged Access Review

Control Objective:
Ensure privileged access remains appropriate and authorized.

Frequency:
Quarterly

Control Owner:
IAM Manager

Record the authoritative control definition.

Do not begin testing using only an auditor request or informal description.

Step 2 — Identify the Requirement

Determine why the control exists.

The control may support:

Enterprise risk treatment.
Internal policy.
Regulatory requirement.
Contractual obligation.
Security framework.
Audit requirement.

Example:

Risk
   ↓
Unauthorized Privileged Access

Policy
   ↓
Access Control Policy

Control
   ↓
IAM-010 Quarterly Privileged Access Review

Evidence
   ↓
Completed Access Reviews

This establishes traceability.

Step 3 — Identify Framework Mappings

One control may satisfy multiple requirements.

Example:

IAM-010
   │
   ├── ISO/IEC 27001
   ├── SOC 2
   ├── PCI DSS
   ├── NIST
   └── Internal Policy

Record applicable mappings in the assessment record.

This allows the same testing to support multiple assurance activities.

Phase 2 — Confirm Assessment Scope

Step 4 — Define the Scope

Document exactly what is being assessed.

For IAM-010:

Systems:
Production Applications

Accounts:
Privileged Accounts

Business Units:
All

Locations:
Global

Assessment Period:
Q2 2026

Control Frequency:
Quarterly

Scope should be precise enough that another assessor can reproduce the test.

Step 5 — Define Out-of-Scope Items

Document exclusions.

Example:

Excluded:

Development sandbox accounts

Non-production test identities

Service accounts governed by IAM-011

Every material exclusion should have a reason.

Step 6 — Validate Scope

Confirm scope with:

Control owner.
System owner.
Compliance team.
Relevant policy documentation.

Ask:

Does this scope represent the complete population subject to the control?

This question is critical.

Incomplete scope can make otherwise good testing unreliable.

Phase 3 — Identify Control Ownership

Step 7 — Identify the Control Owner

Every control should have an accountable owner.

Record:

Control Owner:
IAM Manager

Business Function:
Identity & Access Management

Evidence Provider:
IAM Operations Analyst

Escalation:
Director of Security Engineering

Step 8 — Distinguish Control Owner From Evidence Provider

These are not necessarily the same person.

Control Owner
      ↓
Accountable for Control

Evidence Provider
      ↓
Provides Supporting Evidence

An analyst exporting a report does not automatically own the control.

Step 9 — Confirm Responsibilities

Ask the control owner:

What does the control do?
Why does it exist?
Who performs it?
How frequently?
Which systems are included?
What happens when exceptions are found?
Where is evidence retained?
Has the control changed recently?

Document important responses.

Phase 4 — Understand the Control Design

Step 10 — Determine Control Type

Classify the control.

Preventive

Stops an event.

MFA
Firewall
Deployment Policy

Detective

Identifies an event.

SIEM Alert
Access Review
Vulnerability Scan

Corrective

Restores or remediates.

Account Disablement
Patch Deployment
Backup Restoration

For IAM-010:

Type:
Detective

Step 11 — Determine Control Method

Classify as:

Manual

Automated

IT-Dependent Manual

Hybrid

IAM-010 might be:

IT-Dependent Manual

because a system generates the access population while managers manually review access.

Step 12 — Determine Frequency

Examples:

Continuous

Daily

Weekly

Monthly

Quarterly

Annual

Event Driven

Frequency affects testing methodology.

Step 13 — Evaluate Control Design

Ask:

If this control operates exactly as designed, could it reasonably achieve its objective?

For example:

Control:
Quarterly privileged access review

Process:
IAM generates privileged account list.

Managers review access.

Unnecessary access is identified.

IAM removes access.

Completion is recorded.

This appears capable of addressing inappropriate privileged access.

Therefore:

Design:
Adequate

Phase 5 — Define Evidence Requirements

Step 14 — Determine Required Evidence

Do this before requesting documents.

For IAM-010, evidence may include:

Access Review Procedure

Privileged Account Population

Review Campaign Export

Reviewer Decisions

Access Removal Tickets

Completion Report

Exception Records

Step 15 — Create the Evidence Request

Create an evidence request record.

Example:

Field	Value
Request ID	EVD-001
Control	IAM-010
Evidence	Q2 Privileged Access Review
Period	Apr–Jun 2026
Owner	IAM
Requested	10 Jul 2026
Due	17 Jul 2026
Status	Open

Step 16 — Write Precise Evidence Requests

Avoid:

Please send access-review evidence.

Use:

Provide the complete Q2 2026 privileged access population, completed reviewer decisions, review completion report, and evidence of access removal for users identified as no longer requiring privileged access.

Precise requests reduce unnecessary back-and-forth.

Phase 6 — Collect Evidence

Step 17 — Receive Evidence

When evidence arrives, record:

Evidence ID

Document Name

Source

Owner

Period Covered

Date Received

Assessment Status

Never rely on your inbox as the evidence repository.

Step 18 — Store Evidence

Use a structured repository.

Example:

IAM-010
│
├── 2026-Q1
│
├── 2026-Q2
│   ├── Population
│   ├── Review Results
│   ├── Removal Tickets
│   └── Assessment
│
├── 2026-Q3
└── 2026-Q4

Evidence should be easy to retrieve later.

Phase 7 — Validate Evidence Quality

Step 19 — Validate Relevance

Ask:

Does this evidence actually demonstrate the control being tested?

A security policy may describe the requirement.

It does not prove the quarterly access review occurred.

Step 20 — Validate Period

Confirm that evidence covers the assessment period.

Example:

Assessment:
Q2 2026

Evidence:
Q4 2025

Result:
Not sufficient for Q2 operating-effectiveness testing.

Step 21 — Validate Authenticity

Consider:

Source system.
Evidence provider.
Metadata.
Export date.
System-generated characteristics.
Whether evidence appears manually altered.

Evidence directly generated from authoritative systems generally provides stronger assurance than manually prepared summaries.

Step 22 — Validate Completeness

Ask:

Is this the complete evidence set?

Example:

The control owner provides:

Completed Review Spreadsheet

but no evidence showing how the account population was generated.

You may not know whether the review covered all privileged accounts.

That creates a completeness problem.

Phase 8 — Validate the Population

Step 23 — Define the Population

A population is the complete set of items subject to testing.

Example:

Control:
Quarterly Privileged Access Review

Population:
All privileged accounts included in the Q2 review.

Step 24 — Obtain Population Evidence

Request:

System-generated privileged account export

Generation date

Filters used

Systems included

Total account count

Suppose:

Total Population:
487 Privileged Accounts

Step 25 — Validate Population Completeness

Possible procedures:

Compare against source-system totals.
Reconcile multiple systems.
Review report parameters.
Compare with prior periods.
Confirm excluded account types.
Interview system administrator.

Do not sample from a population you cannot reasonably trust.

Phase 9 — Determine Sampling Methodology

Step 26 — Decide Whether Sampling Is Required

Some controls can be tested using the entire population.

Examples:

Automated MFA Configuration

Encryption Configuration

Centralized Logging Setting

Manual controls may require sampling.

Examples:

Access Approvals

Change Approvals

Vendor Reviews

Termination Processing

Step 27 — Define Sample Size

Sample size should consider:

Population size.
Control frequency.
Risk.
Testing objective.
Applicable audit methodology.
Prior findings.

Do not invent a universal sample size.

Document the methodology used.

Step 28 — Select Samples

Suppose:

Population:
487

Selected Samples:
25

Record each selected item.

Sample	Account	Reviewer	Result
01	Admin-A	Manager 1	Pending
02	Admin-B	Manager 2	Pending
03	Admin-C	Manager 3	Pending

Selection should be reproducible.

Phase 10 — Test Control Design

Step 29 — Perform Design Effectiveness Testing

Verify:

Control objective is clear.
Control addresses the relevant risk.
Responsible roles are defined.
Frequency is appropriate.
Population is defined.
Exceptions are handled.
Evidence is retained.

Document:

Design Effectiveness:
Effective

or:

Design Effectiveness:
Ineffective

Step 30 — Design Failure Example

Policy says:

Privileged access must be reviewed quarterly.

Actual procedure says:

Review selected critical systems annually.

Even if the annual review occurs perfectly, the control design does not satisfy the stated requirement.

Result:

Design Failure

Phase 11 — Test Operating Effectiveness

Step 31 — Define the Test Procedure

For each sample, verify:

Account existed in population.

Correct reviewer performed review.

Review occurred during required period.

Decision was documented.

Inappropriate access was removed.

Removal occurred within required timeframe.

Step 32 — Execute Testing

Example:

Sample	Reviewed	Authorized	Timely	Result
01	Yes	Yes	Yes	Pass
02	Yes	Yes	Yes	Pass
03	Yes	No	No	Exception
04	Yes	Yes	Yes	Pass

Document exactly what was tested.

Step 33 — Preserve Testing Evidence

Maintain:

Sample Selected

Evidence Reviewed

Test Procedure

Test Result

Assessor Notes

Exception Reference

Another qualified assessor should be able to understand how you reached your conclusion.

Phase 12 — Handle Exceptions

Step 34 — Identify an Exception

Suppose:

Sample 03

User:
Former Infrastructure Administrator

Review Decision:
Remove Access

Actual Removal:
18 Days After Review

Requirement:
5 Business Days

This is an exception.

Step 35 — Validate the Exception

Before creating a finding:

Confirm evidence.
Confirm requirement.
Ask control owner for context.
Determine whether compensating controls existed.
Determine whether this is isolated or systemic.

Do not assume every unusual result is automatically a control failure.

Step 36 — Expand Testing if Required

If one sample fails, determine whether additional testing is appropriate.

Example:

Original Sample:
25

Exceptions:
3

Decision:
Expand Testing

Expanded testing may help determine whether the issue is isolated or systemic.

Phase 13 — Determine Control Effectiveness

Step 37 — Use Standard Ratings

Use:

Effective

Partially Effective

Ineffective

Not Tested

Step 38 — Effective

A control may be Effective when:

Design is appropriate.
Control operates consistently.
Evidence is sufficient.
No material exceptions exist.

Step 39 — Partially Effective

Example:

25 Samples

22 Pass

3 Exceptions

The control operates but has meaningful weaknesses.

Depending on severity and methodology:

Partially Effective

may be appropriate.

Step 40 — Ineffective

A control may be Ineffective where:

Design does not address the objective.
Control is not performed.
Exceptions are widespread.
Evidence is unreliable.
Material failures exist.

Phase 14 — Create the Finding

Step 41 — Document Finding Structure

Use:

Finding ID

Title

Condition

Criteria

Cause

Risk / Impact

Severity

Owner

Recommendation

Target Date

Step 42 — Example Finding

Finding ID:
FND-001

Title:
Delayed Removal of Privileged Access

Condition:
Three sampled privileged accounts identified for removal remained active beyond the required five-business-day remediation period.

Criteria:
IAM-010 requires inappropriate privileged access to be removed within five business days.

Cause:
Access-removal tickets are manually assigned and are not automatically escalated when overdue.

Risk:
Users may retain unnecessary privileged access, increasing the likelihood of unauthorized administrative activity.

Severity:
High

Phase 15 — Perform Root Cause Analysis

Step 43 — Identify the Root Cause

Do not stop at:

Team forgot.

Ask why.

Example:

Access removal delayed
      ↓
Ticket not actioned
      ↓
No automated escalation
      ↓
No SLA monitoring
      ↓
Process design weakness

This is more actionable.

Step 44 — Root Cause Categories

Common categories include:

People

Process

Technology

Governance

Training

Resource Constraint

Unclear Ownership

Automation Gap

Root-cause analysis improves remediation quality.

Phase 16 — Define Remediation

Step 45 — Develop Remediation Action

Weak:

IAM team will improve the process.

Better:

Configure automated SLA monitoring and escalation for privileged-access removal tickets and produce a weekly overdue-access report reviewed by the IAM Manager.

Step 46 — Assign Ownership

Record:

Finding Owner:
IAM Manager

Remediation Owner:
IAM Operations Lead

Target Date:
30 September 2026

The responsible party must be clear.

Step 47 — Define Closure Evidence

Before remediation begins, define what will prove completion.

Example:

Updated Procedure

Workflow Configuration

SLA Escalation Screenshot

Overdue Report

Implementation Ticket

Post-Implementation Sample

This prevents ambiguous closure decisions.

Phase 17 — Track Remediation

Step 48 — Create the Remediation Record

Field	Value
Finding	FND-001
Severity	High
Owner	IAM Manager
Action	Automate escalation
Due	30 Sep 2026
Status	In Progress
Retest Required	Yes

Step 49 — Monitor Status

Use standardized statuses:

Open

Remediation Planned

In Progress

Pending Validation

Closed

Risk Accepted

Avoid informal status labels.

Step 50 — Escalate Overdue Findings

Example:

High Finding
      +
Past Due
      +
No Approved Extension
      ↓
Escalation

Escalation may go to:

Security leadership.
Compliance leadership.
Risk committee.
Executive management.

based on severity.

Phase 18 — Retest

Step 51 — Obtain Closure Evidence

When the owner reports completion:

Do not close the finding immediately.

Obtain the agreed evidence.

Step 52 — Validate Implementation

Verify:

New process exists.
Configuration is active.
Required personnel understand it.
Control documentation was updated.

Step 53 — Test Operating Effectiveness

Where appropriate, test transactions after remediation.

Example:

Post-Remediation Population:
Recent privileged removals

Sample:
10

Result:
10 completed within SLA

This provides stronger closure evidence.

Step 54 — Determine Retest Result

Possible results:

Pass

Partial

Fail

Pass

Remediation operates effectively.

Partial

Some issues remain.

Fail

Remediation does not adequately address the finding.

Phase 19 — Close the Finding

Step 55 — Document Closure

Record:

Finding:
FND-001

Remediation:
Implemented

Retest:
Passed

Closure Date:
15 October 2026

Closed By:
GRC Control Assessor

Final Status:
Closed

Retain closure evidence.

Phase 20 — Evidence Handling Standards

Evidence should satisfy several characteristics.

Relevant

It directly supports the control being tested.

Reliable

It comes from a trustworthy source.

Complete

It covers the required population or scope.

Accurate

It correctly represents the underlying activity.

Timely

It relates to the correct assessment period.

Reproducible

Another assessor can understand and repeat the procedure.

A useful model is:

Evidence Quality
      =
Relevant
+
Reliable
+
Complete
+
Accurate
+
Timely

Phase 21 — Evidence Hierarchy

Evidence strength may vary.

Generally, stronger evidence includes:

Direct System Observation

System-Generated Configuration

System-Generated Logs

Independent Assurance

Approved Records

Screenshots

Manual Statements

Verbal Confirmation

The exact reliability depends on context.

A verbal statement alone is usually weaker than independently verifiable system evidence.

Phase 22 — Screenshot Evidence

Screenshots may be useful but have limitations.

A screenshot might show:

MFA = Enabled

but may not demonstrate:

Complete user coverage.
Historical operation.
Exceptions.
Configuration changes.

Whenever practical, prefer structured system-generated evidence.

Phase 23 — Evidence Freshness

Check:

Evidence Date
      ↓
Assessment Period

Do not use stale evidence for current control conclusions without appropriate justification.

Phase 24 — Evidence Naming Convention

Use consistent naming.

Example:

IAM-010_2026Q2_PrivilegedPopulation.csv

IAM-010_2026Q2_ReviewResults.xlsx

IAM-010_2026Q2_RemovalTickets.pdf

Avoid:

final.xlsx

final2.xlsx

new-final.xlsx

audit-stuff.pdf

Good naming improves audit readiness.

Phase 25 — Evidence Index

Maintain:

Evidence ID	Control	Description	Period	Source
EVD-001	IAM-010	Privileged population	Q2	IAM
EVD-002	IAM-010	Review results	Q2	IAM
EVD-003	IAM-010	Removal tickets	Q2	ITSM

The evidence index creates traceability.

Phase 26 — Assessment Workpaper

Create a standardized assessment workpaper.

Include:

Assessment ID

Control ID

Control Name

Control Objective

Control Owner

Assessment Period

Scope

Control Type

Frequency

Evidence Reviewed

Population

Sampling Method

Sample Size

Test Procedure

Test Results

Exceptions

Design Effectiveness

Operating Effectiveness

Overall Conclusion

Assessor

Review Date

This becomes the official assessment record.

Phase 27 — Example Assessment Conclusion

Example:

IAM-010 is appropriately designed to identify unnecessary privileged access through quarterly management review. Testing of 25 samples identified three instances where access approved for removal was not revoked within the required five-business-day timeframe. The control is therefore assessed as Partially Effective. A High-severity finding has been issued to improve access-removal SLA monitoring and escalation.

This is clearer than:

Control failed.

Phase 28 — Evidence Request Tracker

For larger assessments, maintain:

Request	Control	Owner	Due	Status
REQ-001	IAM-010	IAM	17 Jul	Received
REQ-002	LOG-001	SOC	18 Jul	Open
REQ-003	VUL-004	VM Team	20 Jul	Overdue

This prevents evidence requests from disappearing across email threads.

Phase 29 — Evidence Escalation

Use a predictable process.

Example:

Evidence Requested
      ↓
Due Date
      ↓
Reminder
      ↓
Overdue
      ↓
Control Owner Escalation
      ↓
Management Escalation

GRC should avoid creating unnecessary friction while still enforcing assessment timelines.

Phase 30 — Evidence Reuse

Before requesting evidence, check whether suitable current evidence already exists.

Example:

IAM-010 Evidence
      ↓
Internal Assessment
      ↓
SOC 2
      ↓
ISO 27001
      ↓
Customer Assurance

One authoritative evidence set may support several requirements.

This reduces audit fatigue.

Phase 31 — Automated Controls

For automated controls, assess:

Configuration

Logic

Change Management

System Reliability

Exceptions

Monitoring

Example:

Control:
Block public cloud storage.

Implementation:
Policy-as-Code Rule

Testing:
Inspect policy configuration
+
Attempt prohibited deployment
+
Review enforcement logs

Testing should verify the automation rather than merely reading the policy.

Phase 32 — Manual Controls

For manual controls, assess:

Responsible Person

Frequency

Population

Evidence

Reviewer Competence

Approval

Follow-Up

Manual controls often require stronger evidence of consistent execution.

Phase 33 — IT-Dependent Manual Controls

Example:

System Generates Report
      ↓
Manager Reviews Report
      ↓
Manager Records Decision

You may need to assess both:

Reliability of the system-generated report.
Effectiveness of the human review.

If the report is incomplete, the manual review may also be ineffective.

Phase 34 — Continuous Controls

Some controls operate continuously.

Examples:

Endpoint protection.
Firewall enforcement.
Cloud policy.
Security monitoring.

Testing may involve:

Configuration Review

Alert Review

Log Analysis

Exception Review

Change History

The testing method should match the control.

Phase 35 — Evidence Security

Evidence may contain:

Employee information.
System configuration.
Security findings.
Vulnerability details.
Customer data.
Privileged-account information.

Protect evidence using:

Access Control

Encryption

Retention Rules

Secure Sharing

Need-to-Know Access

GRC evidence repositories themselves require security.

Phase 36 — Evidence Retention

Define retention based on:

Regulation.
Certification requirements.
Contract.
Audit requirements.
Corporate retention policy.

Do not retain sensitive evidence indefinitely without purpose.

Phase 37 — Control Assessment Status

Use:

Not Started

Planning

Evidence Collection

Testing

Finding Review

Remediation

Retesting

Completed

This enables portfolio-level tracking.

Phase 38 — Control Assessment Dashboard

Example:

Metric	Count
Controls in Scope	125
Testing Complete	94
Effective	76
Partially Effective	14
Ineffective	4
Evidence Overdue	12
Open Findings	18

Dashboards should help management identify areas requiring attention.

Phase 39 — Control Health

A simple control-health model can combine:

Design
   +
Operating Effectiveness
   +
Open Findings
   +
Evidence Freshness
   =
Control Health

Possible statuses:

Healthy

Needs Attention

Weak

Unknown

Do not use control-health scores without clearly defined criteria.

Phase 40 — Common Mistakes

Mistake 1 — Collecting Evidence Without a Test Objective

Always know what the evidence is supposed to prove.

Mistake 2 — Accepting Policies as Operating Evidence

Policy tells you what should happen.

It does not necessarily prove what happened.

Mistake 3 — Ignoring Population Completeness

A perfect sample from an incomplete population can produce a false conclusion.

Mistake 4 — Testing Only One Transaction

A single successful example rarely demonstrates consistent operation of a recurring manual control.

Mistake 5 — Treating Every Exception as a Finding

Validate context, severity, frequency, and impact first.

Mistake 6 — Closing Findings on Management Statements

“Fixed.”

is not sufficient closure evidence.

Mistake 7 — Ignoring Root Cause

Fixing one failed transaction without fixing the underlying process may lead to recurrence.

Mistake 8 — Duplicate Evidence Requests

Check existing evidence before requesting it again.

Mistake 9 — No Audit Trail

Assessment decisions should be reproducible.

Mistake 10 — No Retesting

Remediation implementation does not automatically prove operating effectiveness.

Operational Checklist

Assessment Planning

Identify control.
Confirm control objective.
Identify requirements.
Confirm framework mappings.
Define scope.
Document exclusions.
Identify control owner.
Identify evidence provider.
Determine control type.
Determine control frequency.

Evidence Collection

Define evidence requirements.
Create evidence request.
Confirm assessment period.
Receive evidence.
Index evidence.
Validate relevance.
Validate reliability.
Validate completeness.
Validate evidence period.
Store evidence securely.

Population & Sampling

Define population.
Obtain population evidence.
Validate population completeness.
Determine sampling approach.
Select samples.
Document methodology.

Testing

Test control design.
Define operating-effectiveness procedure.
Execute testing.
Record results.
Identify exceptions.
Validate exceptions.
Expand testing if necessary.
Determine effectiveness.

Findings

Document condition.
Document criteria.
Determine root cause.
Document risk.
Assign severity.
Agree remediation.
Assign owner.
Establish target date.
Define closure evidence.

Retesting & Closure

Receive remediation evidence.
Validate implementation.
Perform retest.
Document retest result.
Confirm residual issues.
Close finding where appropriate.
Retain final assessment package.

Quick Reference — Control Testing Decision Tree

Select Control
      ↓
Is Scope Defined?
   │
   ├── No → Define Scope
   │
   └── Yes
          ↓
Is Design Adequate?
   │
   ├── No → Design Finding
   │
   └── Yes
          ↓
Is Evidence Sufficient?
   │
   ├── No → Request Evidence
   │
   └── Yes
          ↓
Is Population Reliable?
   │
   ├── No → Resolve Population Issue
   │
   └── Yes
          ↓
Test Operation
          ↓
Exceptions?
   │
   ├── No → Effective
   │
   └── Yes
          ↓
Evaluate Severity / Frequency
          ↓
Finding Required?
   │
   ├── No → Document Rationale
   │
   └── Yes
          ↓
Remediate
          ↓
Retest
          ↓
Close

Runbook Deliverables

A completed assessment package should contain:

01 — Control Assessment Workpaper

02 — Evidence Request

03 — Evidence Index

04 — Population Validation

05 — Sampling Record

06 — Test Results

07 — Exception Log

08 — Finding Record

09 — Remediation Plan

10 — Retest Record

11 — Final Assessment Conclusion

Runbook Success Criteria

The assessment is complete when:

Scope is clear

Control ownership is confirmed

Evidence is sufficient

Population is validated

Testing is reproducible

Exceptions are documented

Effectiveness is concluded

Findings have owners

Remediation is tracked

Required retesting is completed

Final evidence is retained

Practical GRC Mindset

A weak assessment asks:

Did the control owner send us something?

A better assessment asks:

Does the evidence demonstrate that the control operated?

A mature assessment asks:

Is the evidence complete, reliable, and sufficient to demonstrate that the control operated effectively across the required scope and period?

That distinction separates evidence collection from control assurance.

Runbook Complete

You now have a reusable operational procedure for:

Control
   ↓
Scope
   ↓
Evidence
   ↓
Population
   ↓
Sampling
   ↓
Testing
   ↓
Exceptions
   ↓
Findings
   ↓
Remediation
   ↓
Retesting
   ↓
Assurance

This workflow can be reused across security frameworks, compliance programs, internal audits, external audits, and enterprise control-assurance activities.

What’s Next?

➡️ Runbook 02 — Third-Party Risk Assessment & Vendor Onboarding

In the final runbook for Module 01 — GRC Fundamentals, you will operationalize the complete third-party onboarding process.

You will build a repeatable workflow covering:

Business Requests Vendor
        ↓
Vendor Intake
        ↓
Inherent Risk Assessment
        ↓
Risk Tiering
        ↓
Due Diligence
        ↓
Security Questionnaire
        ↓
Assurance Evidence Review
        ↓
Findings
        ↓
Residual Risk
        ↓
Contractual Requirements
        ↓
Risk Decision
        ↓
Approval
        ↓
Onboarding
        ↓
Monitoring

The runbook will define the exact actions a GRC Analyst should take when a new vendor enters the organization, including approval gates, evidence requirements, escalation criteria, conditional approvals, risk acceptance, remediation tracking, and ongoing monitoring.