Runbook 03 — Enterprise Governance Audit

Runbook Information

Item	Details
Runbook ID	K8S-COMPLIANCE-RUNBOOK-03
Runbook Type	Enterprise Governance and Assurance Audit
Difficulty	Advanced
Estimated Time	8–12 Hours
Environment	Enterprise Kubernetes Estate
Platform	Kubernetes, Kyverno, Gatekeeper, kubectl, Git, CI/CD, SIEM and GRC Platforms
Primary Role	Kubernetes Security Auditor
Supporting Roles	Kubernetes Security Engineer, Cloud Security Engineer, Platform Engineer, DevSecOps Engineer, Compliance Analyst, Internal Auditor, Risk Manager
Module	Kubernetes Benchmarks, Governance and Compliance
Previous Runbook	Runbook 02 — Enterprise Policy Review
Review Frequency	Annually, After Major Organisational Change, or Before External Audit
Classification	Internal — Security Restricted

Executive Summary

This runbook provides a structured enterprise process for auditing the governance of Kubernetes environments.

The audit evaluates whether Kubernetes security controls are supported by effective:

Organisational accountability
Policy ownership
Technical enforcement
Privileged-access governance
Change management
Exception management
Risk acceptance
Compliance oversight
Evidence retention
Audit readiness
Executive reporting
Continuous improvement

A Kubernetes environment may contain strong technical security controls and still present significant enterprise risk when:

Ownership is unclear.
Policies are not approved or maintained.
Administrative access is not accountable.
Exceptions remain active indefinitely.
Production changes bypass approved workflows.
Security findings are not tracked.
Evidence cannot demonstrate that controls are operating.
Management does not receive reliable risk information.

The objective of this audit is to determine whether Kubernetes governance is designed appropriately, implemented consistently, and operating effectively across the enterprise.

Enterprise Scenario

CloudNova Technologies has expanded its Kubernetes estate across:

Multiple cloud providers
Regional production clusters
Development and testing environments
Financial services workloads
Healthcare applications
Artificial intelligence platforms
Customer-facing services
Internal enterprise applications

The organisation has implemented:

CIS Benchmark assessments
Kyverno policies
OPA Gatekeeper policies
Pod Security Admission
Secure container registries
Image scanning and signing
Compliance automation
Centralised logging
SIEM integration
Formal Kubernetes security standards

During preparation for an external audit, senior management identified several concerns:

Cluster ownership differs between business units.
Some policies have no current owner.
Privileged access is not reviewed consistently.
Production changes are occasionally performed directly.
Risk acceptances are stored across different systems.
Exception expiry is not centrally monitored.
Governance metrics are incomplete.
Evidence retention varies by team.
No single executive view exists for Kubernetes risk.
Governance maturity has not been independently assessed.

The Audit Committee has requested an enterprise Kubernetes governance audit.

Your mission is to assess whether CloudNova Technologies has established effective governance, accountability, oversight, evidence, and risk-management practices for operating Kubernetes securely at scale.

Audit Objectives

The audit objectives are to:

Confirm governance scope and audit authority
Evaluate organisational accountability
Verify cluster and namespace ownership
Assess policy governance
Review privileged-access oversight
Evaluate separation of duties
Review change-management controls
Assess production-deployment governance
Review exception and risk-acceptance processes
Validate compliance oversight
Assess evidence quality and integrity
Review incident-governance responsibilities
Evaluate lifecycle governance
Assess multi-cluster consistency
Measure governance maturity
Identify control-design and operating-effectiveness gaps
Create an audit findings register
Produce a management remediation plan
Deliver an executive audit opinion

Enterprise Governance Audit Architecture

                         Board and Audit Committee

                                   │

                                   ▼

                          Executive Risk Oversight

                                   │

              ┌────────────────────┼────────────────────┐
              │                    │                    │

       Business Ownership     Security Governance   Compliance Oversight

              │                    │                    │

              └────────────────────┼────────────────────┘

                                   │

                                   ▼

                       Kubernetes Governance Framework

       ┌───────────────────────────┼───────────────────────────┐
       │                           │                           │

 Cluster Ownership          Policy Governance          Access Governance

 Namespace Ownership        Admission Controls         Privileged Access

 Change Management          Exception Management       Separation of Duties

 Compliance Reporting       Evidence Management        Risk Acceptance

       └───────────────────────────┼───────────────────────────┘

                                   │

                                   ▼

                       Independent Audit and Assurance

                                   │

                 ┌─────────────────┼─────────────────┐
                 │                 │                 │

           Audit Findings     Management Actions    Executive Opinion

Governance Audit Workflow

Plan Audit

    │

    ▼

Confirm Authority and Scope

    │

    ▼

Understand Governance Framework

    │

    ▼

Perform Design Assessment

    │

    ▼

Test Operating Effectiveness

    │

    ▼

Validate Evidence

    │

    ▼

Interview Control Owners

    │

    ▼

Identify Findings

    │

    ▼

Rate Risk and Maturity

    │

    ▼

Agree Management Actions

    │

    ▼

Issue Final Audit Report

    │

    ▼

Track Remediation

Audit Principles

The audit must follow these principles:

Independence
Objectivity
Evidence-based conclusions
Least-privilege access
Confidentiality
Traceability
Professional scepticism
Repeatability
Risk-based sampling
Clear ownership
Separation of audit and control operation
Documented limitations
Timely escalation of critical issues

Audit Scope

The audit may include:

Enterprise Kubernetes governance framework
Organisational ownership
Cluster ownership
Namespace ownership
Policy ownership
Policy lifecycle
RBAC governance
Privileged access
Service Account governance
Admission-control governance
Production-readiness approval
GitOps and CI/CD governance
Change management
Emergency changes
Exceptions
Risk acceptance
Compliance reporting
Evidence retention
Incident governance
Backup and recovery governance
Cluster lifecycle
Multi-cluster consistency
Governance metrics
Management oversight

Out-of-Scope Examples

Document exclusions such as:

Application source-code assurance
Full penetration testing
Cloud-account financial review
Third-party SaaS internal controls
Physical data-centre security
End-user device controls
External identity-provider internal operations
Detailed business-continuity testing

Every exclusion must include:

Reason
Business owner
Risk impact
Alternative assurance source

Audit Criteria

The audit should use approved criteria such as:

Organisational Kubernetes Security Standard
CIS Kubernetes Benchmark
NIST Cybersecurity Framework
NIST SP 800-53
ISO/IEC 27001
SOC 2 Trust Services Criteria
PCI DSS
Cloud-provider security standards
Internal access-control policy
Internal change-management policy
Internal risk-management policy
Internal evidence-retention policy

Required Roles

Role	Responsibility
Audit Lead	Owns the audit plan, execution and final opinion
Security Auditor	Tests security governance controls
Kubernetes Security Engineer	Provides technical context and evidence
Platform Owner	Explains cluster operation and ownership
Cloud Security Owner	Provides cloud identity and platform evidence
DevSecOps Owner	Provides pipeline and release evidence
Compliance Analyst	Maps controls to regulatory requirements
Risk Manager	Reviews findings and residual risk
Business Owner	Confirms accountability and accepts business risk
CISO Delegate	Reviews critical security findings
Audit Committee Sponsor	Receives the final audit opinion

Required Tools

Tool	Purpose
kubectl	Kubernetes governance evidence collection
Kyverno	Policy and reporting review
Gatekeeper	Constraint and violation review
kube-bench	Benchmark evidence
Trivy	Configuration and image evidence
Git	Policy and configuration history
CI/CD Platform	Change and deployment evidence
SIEM	Security monitoring and audit-event evidence
Ticketing Platform	Remediation and change records
GRC Platform	Control, exception and risk records
Cloud CLI	Managed-cluster and identity evidence
jq	JSON processing
VS Code	Audit analysis and reporting

Required Audit Evidence

Collect evidence including:

Audit charter or approval
Audit scope
Stakeholder register
Organisational governance standard
Cluster inventory
Ownership register
Namespace inventory
Policy inventory
RBAC exports
Privileged-access records
Access-review records
Admission policies
PolicyReports
Gatekeeper violations
Change tickets
Pull-request approvals
Pipeline records
Emergency-change records
Exception register
Risk-acceptance records
Compliance reports
Governance dashboards
Incident-response records
Backup and recovery evidence
Lifecycle records
Training records
Previous audit findings
Remediation evidence
Executive reporting packs

Recommended Audit File Structure

runbook-03-enterprise-governance-audit/
├── planning/
│   ├── audit-charter.md
│   ├── audit-scope.md
│   ├── audit-plan.md
│   ├── stakeholder-register.md
│   └── sampling-plan.md
├── governance/
│   ├── governance-framework.md
│   ├── accountability-matrix.md
│   ├── ownership-register.md
│   ├── policy-register.md
│   └── risk-register.md
├── evidence/
│   ├── cluster-inventory.yaml
│   ├── namespaces.yaml
│   ├── clusterroles.yaml
│   ├── clusterrolebindings.yaml
│   ├── serviceaccounts.yaml
│   ├── kyverno-policies.yaml
│   ├── gatekeeper-constraints.yaml
│   ├── policyreports.yaml
│   ├── webhooks.yaml
│   ├── change-records/
│   ├── access-reviews/
│   └── screenshots/
├── testing/
│   ├── ownership-testing.md
│   ├── access-testing.md
│   ├── policy-testing.md
│   ├── change-testing.md
│   ├── exception-testing.md
│   ├── evidence-testing.md
│   └── management-oversight-testing.md
└── reports/
    ├── audit-workpaper.md
    ├── findings-register.md
    ├── governance-scorecard.md
    ├── management-action-plan.md
    ├── executive-summary.md
    └── final-audit-report.md

Phase 01 — Audit Planning

Step 01 — Confirm Audit Authority

Obtain documented approval containing:

Audit Name:

Audit Sponsor:

Audit Committee Reference:

Audit Lead:

Organisation:

Business Units:

Clusters in Scope:

Audit Start Date:

Audit End Date:

Approved Access:

Approved Evidence Sources:

Data-Handling Classification:

Escalation Contact:

Final Report Recipients:

Step 02 — Define Audit Scope

Create planning/audit-scope.md.

Document:

Business Units:

Cloud Providers:

Clusters:

Regions:

Environments:

Namespaces:

Applications:

Governance Processes:

Policies:

Compliance Frameworks:

Evidence Period:

Audit Period:

Exclusions:

Known Limitations:

Step 03 — Define Audit Objectives and Criteria

Create a control-objective matrix.

Audit Objective	Audit Criteria	Evidence Required
Cluster ownership is accountable	Kubernetes Governance Standard	Ownership register
Privileged access is controlled	Access Control Policy	Access reviews and bindings
Policies are governed	Policy Management Standard	Policy inventory and approvals
Changes are authorised	Change Management Policy	Tickets and pull requests
Exceptions are time limited	Risk Policy	Exception register
Compliance is monitored	Compliance Standard	Reports and dashboards

Step 04 — Create the Stakeholder Register

Stakeholder	Role	Responsibility	Interview Required	Escalation Level

Step 05 — Create the Sampling Plan

Create planning/sampling-plan.md.

The sample should include:

Production clusters
Non-production clusters
High-risk namespaces
Critical workloads
Cluster-admin identities
Recently changed policies
Active exceptions
Expired exceptions
Emergency changes
Failed compliance controls
Recently remediated findings

Document:

Population:

Sample Size:

Selection Method:

Risk Factors:

Sample Period:

Limitations:

Auditor:

Phase 02 — Governance Framework Assessment

Step 06 — Obtain the Governance Framework

Review whether the organisation has a documented Kubernetes governance framework.

The framework should define:

Scope
Authority
Roles
Ownership
Security standards
Compliance requirements
Change processes
Exception processes
Risk acceptance
Review frequency
Escalation
Evidence requirements

Step 07 — Assess Governance Approval

Confirm the framework has:

Executive sponsor
Security approval
Platform approval
Compliance approval
Effective date
Version
Review date
Publication location

Step 08 — Assess Governance Coverage

Determine whether the framework covers:

All cloud providers
Managed clusters
Self-managed clusters
Development
Testing
Staging
Production
Disaster recovery
Temporary clusters
Acquired environments
Edge or specialised Kubernetes platforms

Step 09 — Review Governance Exceptions

Identify business units or clusters operating outside the governance framework.

For each exclusion, document:

Reason
Owner
Risk
Approval
Compensating controls
Expiry
Review date

Phase 03 — Organisational Accountability Audit

Step 10 — Review the Ownership Register

Create or review governance/ownership-register.md.

Asset	Business Owner	Technical Owner	Security Owner	Compliance Owner	Status

Step 11 — Test Cluster Ownership

For each sampled cluster, verify:

Business owner
Platform owner
Security owner
Incident owner
Backup owner
Cost owner
Risk owner
Lifecycle owner

Evidence may include:

CMDB
Cloud tags
Governance register
Approval records
Service catalogue

Step 12 — Test Namespace Ownership

Collect namespace metadata.

kubectl get namespaces \
  --show-labels

Export evidence.

kubectl get namespaces \
  -o yaml \
  > evidence/namespaces.yaml

Check for:

Owner labels
Application labels
Environment labels
Data classification
Cost centre
Criticality
Business purpose

Step 13 — Identify Ownership Conflicts

Identify cases where:

Multiple teams claim ownership.
No team accepts ownership.
Technical and business ownership disagree.
Ownership records conflict across systems.
Former employees remain listed.
Shared namespaces have no accountable owner.

Step 14 — Review the Accountability Matrix

Assess whether responsibilities are clearly defined for:

Cluster creation
Cluster operation
Policy management
RBAC management
Security monitoring
Incident response
Exception approval
Risk acceptance
Production approval
Decommissioning

Phase 04 — Policy Governance Audit

Step 15 — Export the Policy Inventory

Export Kyverno policies.

kubectl get clusterpolicies \
  -o yaml \
  > evidence/kyverno-clusterpolicies.yaml

kubectl get policies \
  -A \
  -o yaml \
  > evidence/kyverno-policies.yaml

Export Gatekeeper controls.

kubectl get constrainttemplates \
  -o yaml \
  > evidence/gatekeeper-templates.yaml

kubectl get constraints \
  -o yaml \
  > evidence/gatekeeper-constraints.yaml

Step 16 — Test Policy Ownership

For each sampled policy, verify:

Named owner
Maintainer
Approver
Business purpose
Severity
Scope
Review date
Version
Compliance mapping

Step 17 — Test Policy Approval

Obtain evidence of:

Technical review
Security review
Testing
Change approval
Production approval
Rollback plan

Step 18 — Test Policy Enforcement

Review whether critical policies are in:

Enforce

or the equivalent denying mode.

Identify critical controls left in:

Audit

Review supporting risk acceptance.

Step 19 — Review Policy Exclusions

Identify:

Namespace exclusions
User exclusions
Service Account exclusions
Resource exclusions
Cluster-wide bypasses
Emergency exclusions

Verify each exclusion is:

Specific
Approved
Time limited
Monitored
Supported by compensating controls

Step 20 — Review Policy Lifecycle

Determine whether policies follow:

Request

   │

   ▼

Design

   │

   ▼

Review

   │

   ▼

Test

   │

   ▼

Approve

   │

   ▼

Deploy

   │

   ▼

Monitor

   │

   ▼

Review

   │

   ▼

Retire

Step 21 — Review Policy Drift

Compare clusters for:

Missing policies
Different policy versions
Different enforcement modes
Different exclusions
Different trusted registries
Different security baselines
Different policy owners

Phase 05 — Privileged-Access Governance Audit

Step 22 — Export RBAC Evidence

kubectl get clusterroles \
  -o yaml \
  > evidence/clusterroles.yaml

kubectl get clusterrolebindings \
  -o yaml \
  > evidence/clusterrolebindings.yaml

kubectl get roles \
  -A \
  -o yaml \
  > evidence/roles.yaml

kubectl get rolebindings \
  -A \
  -o yaml \
  > evidence/rolebindings.yaml

Step 23 — Identify Cluster-Admin Bindings

kubectl get clusterrolebindings \
  -o json \
  | jq -r '
      .items[]
      | select(.roleRef.name == "cluster-admin")
      | {
          binding: .metadata.name,
          subjects: .subjects
        }'

Step 24 — Test Privileged-Access Approval

For sampled privileged identities, verify:

Named identity
Business justification
Manager approval
Security approval
MFA
Time limitation
Access-review evidence
Usage logging
Revocation process

Step 25 — Review Shared Privileged Access

Identify:

Shared administrator users
Generic accounts
Shared kubeconfig files
Long-lived tokens
Shared Service Accounts
Emergency accounts used routinely

Step 26 — Review Just-in-Time Access

Assess whether production privileged access uses:

Temporary elevation
Approval workflow
Automatic expiry
Session recording
Command logging
Post-access review

Step 27 — Review Access Certification

Confirm periodic access reviews include:

Privileged users
Cloud IAM groups
Kubernetes groups
Service Accounts
Automation identities
Former staff
Third parties

Phase 06 — Separation of Duties Audit

Step 28 — Identify Incompatible Responsibilities

Determine whether one identity can:

Create a policy
Approve a policy
Deploy a policy
Create an exception
Approve the exception
Deploy production workloads
Approve production
Delete audit evidence
Close its own finding

Step 29 — Review Pipeline Separation

Assess whether:

Developers can merge their own production changes.
Pipeline administrators can bypass approvals.
Security gates can be disabled without independent approval.
Production credentials are separated from development access.
Image signers are separated from image builders.

Step 30 — Review Audit Independence

Confirm that:

Auditors do not own the controls they assess.
Control owners do not approve their own findings.
Risk owners are independent from remediation teams where required.
Critical findings receive peer review.

Phase 07 — Change-Management Audit

Step 31 — Obtain the Change Population

Collect changes involving:

Cluster configuration
RBAC
Admission policies
NetworkPolicies
Namespace labels
Registry controls
Logging
Secrets configuration
Backups
Kubernetes upgrades

Step 32 — Test Standard Changes

For each sampled change, verify:

Change request
Business reason
Risk assessment
Testing
Approvals
Implementation evidence
Rollback plan
Post-change validation
Closure

Step 33 — Review GitOps and CI/CD Controls

Assess:

Protected branches
Required reviewers
Signed commits
Pipeline security gates
Deployment identity
Environment protection
Secret handling
Artifact retention
Rollback capability
Audit logs

Step 34 — Identify Direct Production Changes

Review logs for:

Direct kubectl apply
Direct kubectl edit
Direct RBAC changes
Direct policy deletion
Direct image replacement
Direct namespace modifications

For every direct change, verify:

Approved exception
Emergency ticket
Operator
Time
Reason
Post-change review

Step 35 — Review Emergency Changes

Verify emergency changes include:

Defined trigger
Authorised personnel
Immediate logging
Retrospective approval
Maximum duration
Rollback
Evidence
Post-incident review

Phase 08 — Production-Deployment Governance Audit

Step 36 — Review Production Approval Criteria

Production approval should require:

Business owner
Technical owner
Security review
Compliance review
RBAC review
Network review
Secrets review
Image scan
Signature verification
SBOM
Admission validation
Logging
Backup
Rollback plan
Risk acceptance

Step 37 — Test Production Releases

Select a sample of production deployments and verify:

Pull request
Reviewer approval
Pipeline result
Image digest
Security scan
Signature verification
Policy result
Change ticket
Deployment record
Post-deployment validation

Step 38 — Review Deployment Bypass

Identify whether users can:

Deploy directly to production
Skip security scans
Override failed policy gates
Use unapproved images
Disable admission controls
Use emergency accounts without review

Phase 09 — Exception-Management Audit

Step 39 — Obtain the Exception Register

The register should include:

Field	Required
Exception ID	Yes
Control	Yes
Resource	Yes
Owner	Yes
Business justification	Yes
Severity	Yes
Approver	Yes
Compensating controls	Yes
Start date	Yes
Expiration date	Yes
Review date	Yes
Status	Yes

Step 40 — Test Active Exceptions

For each sampled exception, verify:

The resource exists.
The exception is still required.
The owner is current.
The approver is authorised.
The risk is accurate.
Compensating controls operate.
The expiry date has not passed.
Monitoring is active.

Step 41 — Identify Expired Exceptions

Escalate:

Expired critical exceptions
Exceptions with no expiry
Repeated extensions
Cluster-wide exceptions
Exceptions without owners
Exceptions without compensating controls

Step 42 — Review Exception Modification Rights

Assess who can:

Create exceptions
Approve exceptions
Modify expiry
Delete exception evidence
Change compensating controls
Close exceptions

Phase 10 — Risk-Acceptance Audit

Step 43 — Review Risk-Acceptance Records

Every record should include:

Risk ID:

Finding:

Severity:

Business Impact:

Likelihood:

Affected Assets:

Compensating Controls:

Security Recommendation:

Risk Owner:

Acceptance Period:

Expiry Date:

Approval:

Residual Risk:

Step 44 — Test Risk-Owner Authority

Confirm the accepting individual:

Owns the affected business risk.
Has delegated authority.
Understands the impact.
Is independent from the technical control owner where required.
Has approved a time-limited acceptance.

Step 45 — Review Residual-Risk Monitoring

Confirm accepted risks are:

Monitored
Reported
Reassessed
Escalated if conditions change
Removed at expiry
Linked to remediation where applicable

Phase 11 — Compliance Oversight Audit

Step 46 — Review Compliance Reporting

Assess whether reports include:

Cluster coverage
Control pass rate
Critical findings
High findings
Policy failures
Benchmark failures
Expired exceptions
Overdue remediation
Unsupported clusters
Evidence gaps

Step 47 — Review Reporting Frequency

Confirm:

Report	Expected Frequency
Operational policy report	Daily or Weekly
Security compliance report	Monthly
Governance scorecard	Quarterly
Executive risk report	Quarterly
Full audit report	Annually
Critical-risk escalation	Immediate

Step 48 — Test Management Review

Obtain evidence that management:

Receives reports
Reviews findings
Challenges control owners
Assigns actions
Approves risks
Tracks overdue remediation
Escalates critical issues

Step 49 — Review Compliance Coverage

Determine whether all clusters are included.

Identify:

Unassessed clusters
Temporary clusters
Acquired clusters
Disaster-recovery clusters
Unsupported clusters
Clusters with failed automation

Phase 12 — Evidence and Audit-Trail Audit

Step 50 — Review Evidence Standards

Evidence should be:

Complete
Accurate
Current
Attributable
Time stamped
Protected
Searchable
Retained
Tamper evident
Linked to the relevant control

Step 51 — Test Evidence Integrity

For selected evidence, verify:

Source
Collection time
Collector
File hash
Storage location
Access permissions
Retention
Version
Reviewer

Step 52 — Review Evidence Access

Identify who can:

Upload evidence
Modify evidence
Delete evidence
Approve evidence
Change retention
Export confidential evidence

Step 53 — Review Evidence Retention

Assess retention for:

Benchmark reports
Access reviews
Policy reports
Change records
Pipeline logs
Admission denials
Exceptions
Risk acceptances
Incident records
Audit reports

Step 54 — Identify Evidence Gaps

Document:

Control	Required Evidence	Available	Gap	Owner	Due Date

Phase 13 — Security Operations Governance Audit

Step 55 — Review Monitoring Ownership

Confirm named owners exist for:

Audit logs
Admission events
Runtime alerts
Identity alerts
Registry alerts
Image-signing failures
Public exposure
Policy changes
Privileged access

Step 56 — Review Alert Escalation

Test whether critical events are escalated.

Examples:

New cluster-admin binding
Policy engine unavailable
Audit logging disabled
Privileged Pod deployed
Untrusted image admitted
Exception modified without approval
Production policy deleted

Step 57 — Review Incident-Response Governance

Confirm procedures define:

Incident commander
Kubernetes technical lead
Cloud-security lead
Application owner
Legal and compliance contacts
Evidence custodian
Executive escalation

Step 58 — Test Incident Records

Review selected incidents for:

Detection
Triage
Containment
Evidence preservation
Communication
Root-cause analysis
Corrective action
Governance lessons

Phase 14 — Backup, Recovery and Resilience Governance Audit

Step 59 — Review Backup Ownership

Confirm owners for:

etcd backups
Cluster-resource backups
Persistent-volume backups
Secrets references
Policy backups
Recovery testing

Step 60 — Review Recovery Governance

Assess whether:

Recovery objectives are approved.
Restore tests are scheduled.
Failed tests are tracked.
Evidence is retained.
Business owners review recovery results.
Disaster-recovery clusters follow the same security baseline.

Step 61 — Test Restore Evidence

Select restore tests and verify:

Scope
Date
Operator
Result
Recovery time
Recovery point
Issues
Remediation
Approval

Phase 15 — Cluster Lifecycle Governance Audit

Step 62 — Review Cluster Provisioning

Confirm new clusters require:

Business request
Architecture review
Security review
Ownership assignment
Data classification
Compliance classification
Logging
Backup
Approved baseline
Production approval

Step 63 — Review Upgrade Governance

Assess:

Supported-version policy
Upgrade schedule
Test environment
Security validation
Change approval
Rollback
Post-upgrade assessment

Step 64 — Identify Unsupported Clusters

Unsupported production clusters should normally be rated high risk.

Review:

Kubernetes version
Operating system
Container runtime
Policy-engine versions
Ingress controller
Service mesh
Security agents

Step 65 — Review Decommissioning

Confirm cluster retirement includes:

Business approval
Workload migration
Data retention
Backup disposition
Credential revocation
Identity removal
DNS removal
Logging retention
Evidence retention
Cost closure

Phase 16 — Multi-Cluster Governance Audit

Step 66 — Build the Multi-Cluster Comparison

Control	Cluster A	Cluster B	Cluster C	Standard
Pod Security				Restricted
Kyverno				Required
Gatekeeper				Approved
Audit logging				Enabled
Image signing				Enforced
NetworkPolicy				Default deny
Cluster-admin review				Monthly
Compliance assessment				Scheduled

Step 67 — Identify Governance Drift

Examples:

Different policies
Different policy versions
Different exclusions
Missing monitoring
Missing owners
Different access-review schedules
Different evidence retention
Different exception processes

Step 68 — Review Central Oversight

Assess whether a central team can:

Discover all clusters
Measure policy coverage
Identify drift
Review ownership
View exceptions
Track critical findings
Compare maturity
Escalate overdue risks

Phase 17 — Training and Competency Audit

Step 69 — Review Role-Based Training

Verify training for:

Cluster administrators
Platform engineers
Developers
DevSecOps engineers
Security engineers
Incident responders
Compliance staff
Business owners
Risk owners

Step 70 — Review Competency Evidence

Evidence may include:

Training completion
Skills assessments
Certifications
Practical exercises
Incident simulations
Secure-deployment reviews
Access eligibility criteria

Step 71 — Review Privileged-Access Training

Privileged users should understand:

RBAC
Admission control
Change management
Emergency access
Evidence handling
Incident escalation
Risk acceptance
Production safety

Phase 18 — Governance Metrics and Management Oversight

Step 72 — Review Governance Metrics

Recommended metrics include:

Metric	Purpose
Clusters with assigned owners	Ownership coverage
Namespaces with owners	Namespace accountability
Critical policies enforced	Technical enforcement
Cluster-admin identities	Privileged-access exposure
Access reviews completed	Access governance
Expired exceptions	Exception risk
Overdue critical findings	Remediation risk
Direct production changes	Change-control maturity
Policy drift	Multi-cluster consistency
Evidence completeness	Audit readiness
Unsupported clusters	Lifecycle risk
Repeated control failures	Control effectiveness

Step 73 — Review Metric Quality

Assess whether metrics are:

Accurate
Complete
Timely
Reproducible
Owned
Reviewed
Actionable
Consistent across clusters

Step 74 — Review Executive Oversight

Confirm executives receive:

Current risk posture
Critical findings
Trend analysis
Overdue remediation
Accepted risks
Expired exceptions
Coverage gaps
Maturity score
Investment requirements

Phase 19 — Governance Maturity Assessment

Step 75 — Apply the Maturity Model

Level 1 — Initial

Governance is informal.
Ownership is unclear.
Policies are inconsistent.
Evidence is incomplete.
Risk decisions are reactive.

Level 2 — Developing

Basic standards exist.
Ownership is partially assigned.
Reviews are manual.
Exceptions are inconsistently managed.
Management reporting is limited.

Level 3 — Defined

Governance is documented.
Roles are assigned.
Policies are approved.
Compliance reviews are scheduled.
Risk acceptance is formal.

Level 4 — Managed

Controls are measured.
Compliance is automated.
Remediation is tracked.
Multi-cluster drift is reviewed.
Executive reporting is established.

Level 5 — Optimised

Governance is continuous.
Policy drift is automatically detected.
Exceptions expire automatically.
Risk decisions are data driven.
Governance continuously improves.

Step 76 — Score Governance Domains

Score each domain from 0 to 5.

Domain	Score
Governance framework
Cluster ownership
Namespace ownership
Policy governance
Privileged access
Separation of duties
Change management
Production governance
Exception management
Risk acceptance
Compliance oversight
Evidence governance
Security operations
Lifecycle governance
Multi-cluster consistency
Training
Executive oversight

Step 77 — Calculate the Governance Score

Governance Score =

Total Achieved Score
÷
Maximum Possible Score
×
100

Step 78 — Assign the Maturity Rating

Score	Rating
90–100	Optimised
75–89	Managed
60–74	Defined
40–59	Developing
Below 40	Initial

Phase 20 — Control Design and Operating Effectiveness

Step 79 — Assess Control Design

A control is appropriately designed when:

It addresses the intended risk.
Ownership is defined.
Frequency is appropriate.
Evidence requirements are clear.
Exceptions are governed.
Escalation exists.
Responsibilities are separated.

Step 80 — Assess Operating Effectiveness

A control operates effectively when:

It was performed.
It was performed on time.
It covered the full population or approved sample.
Evidence exists.
Findings were escalated.
Remediation was tracked.
Exceptions were approved.

Step 81 — Assign Control Conclusions

Use:

Designed and Operating Effectively
Designed but Not Operating Effectively
Partially Designed
Not Designed
Not Tested
Not Applicable

Phase 21 — Audit Findings

Step 82 — Create the Findings Register

Create reports/findings-register.md.

Finding ID	Control Domain	Finding	Severity	Owner	Due Date	Status
K8S-AUD-001						Open

Step 83 — Document Findings

Use:

Finding ID:

Title:

Control Domain:

Audit Criterion:

Condition:

Expected Control:

Evidence:

Root Cause:

Business Impact:

Security Impact:

Compliance Impact:

Likelihood:

Severity:

Affected Clusters:

Affected Business Units:

Management Owner:

Recommended Action:

Management Response:

Target Date:

Residual Risk:

Validation Method:

Status:

Step 84 — Validate Findings with Management

Before finalising:

Confirm factual accuracy.
Present supporting evidence.
Obtain management response.
Resolve misunderstandings.
Record disagreement.
Retain auditor independence.
Do not reduce severity without evidence.

Risk Classification

Critical

Examples:

No accountable owner for critical production clusters
Unauthorised cluster-admin access
Security policies can be bypassed without approval
Audit evidence is falsified or deleted
Production changes are untraceable
Critical risk has no owner
Admission controls are intentionally disabled
Executive reporting conceals critical risk

High

Examples:

Shared administrative access
Critical policies remain in Audit mode
Exceptions have no expiry
Access reviews are not performed
Direct production changes bypass controls
Unsupported production clusters
Compliance coverage is incomplete
Critical findings are overdue
Policy drift exists across production clusters

Medium

Examples:

Incomplete ownership metadata
Manual reporting
Policy review dates are missing
Training is incomplete
Evidence retention is inconsistent
Governance metrics are weak
Change documentation is incomplete

Low

Examples:

Minor naming inconsistency
Missing annotation
Report-format issue
Non-critical documentation gap

Phase 22 — Management Action Planning

Step 85 — Create the Management Action Plan

Create reports/management-action-plan.md.

Finding ID	Management Action	Owner	Due Date	Priority	Status

Step 86 — Define Remediation Priorities

Immediate — 0 to 7 Days

Revoke unauthorised privileged access.
Restore critical admission controls.
Assign owners to critical clusters.
Remove expired critical exceptions.
Preserve disputed audit evidence.
Investigate untraceable production changes.
Escalate overdue critical findings.

Short-Term — 8 to 30 Days

Complete privileged-access review.
Move critical policies to Enforce mode.
Standardise exception management.
Implement production-deployment gates.
Assign owners to unowned namespaces.
Correct policy drift.
Formalise risk acceptance.

Medium-Term — 31 to 90 Days

Centralise governance reporting.
Automate exception expiry.
Implement continuous ownership validation.
Improve evidence retention.
Establish recurring governance committees.
Standardise multi-cluster controls.
Improve role-based training.

Long-Term — 90+ Days

Implement enterprise policy orchestration.
Integrate Kubernetes governance with GRC platforms.
Automate control testing.
Build executive risk dashboards.
Implement continuous governance assurance.
Conduct recurring independent audits.

Phase 23 — Audit Opinion

Satisfactory

Use when:

Governance is appropriately designed.
Controls operate consistently.
No critical findings exist.
High-risk issues are limited and controlled.
Evidence is reliable.
Management oversight is effective.

Needs Improvement

Use when:

Governance is generally established.
Several controls are inconsistent.
High-risk findings exist.
Management has credible remediation plans.
Critical risk is controlled.

Unsatisfactory

Use when:

Governance is not reliable.
Critical controls are absent or ineffective.
Evidence cannot support compliance claims.
Administrative access is uncontrolled.
Risk ownership is unclear.
Critical findings remain unresolved.

No Assurance

Use when:

Scope was materially restricted.
Evidence was unavailable.
Audit access was insufficient.
Management prevented testing.
Evidence integrity is unreliable.

Escalation Matrix

Condition	Escalation
Evidence tampering suspected	Legal, Compliance, CISO and Audit Committee
Unauthorised cluster-admin access	SOC, CISO and Platform Head
Critical policy bypass	Security Leadership and Risk Owner
Untraceable production change	Change Advisory Board and SOC
Expired critical exception	CISO Delegate and Business Owner
Critical finding has no owner	Executive Sponsor
Audit access obstructed	Audit Committee
Production governance rated unsatisfactory	Business Owner and Executive Risk Committee
Repeated management failure to remediate	Audit Committee and Board Risk Committee

Enterprise Governance Audit Checklist

Audit Control	Status
Audit authority confirmed	☐
Scope documented	☐
Criteria documented	☐
Stakeholders identified	☐
Sampling plan approved	☐
Governance framework reviewed	☐
Governance approval validated	☐
Cluster ownership tested	☐
Namespace ownership tested	☐
Accountability matrix reviewed	☐
Policy inventory collected	☐
Policy ownership tested	☐
Policy approval tested	☐
Policy enforcement tested	☐
Policy exclusions reviewed	☐
Policy lifecycle reviewed	☐
Policy drift assessed	☐
RBAC evidence collected	☐
Cluster-admin access reviewed	☐
Privileged-access approvals tested	☐
Shared access reviewed	☐
Just-in-time access reviewed	☐
Access certification tested	☐
Separation of duties reviewed	☐
Pipeline separation reviewed	☐
Audit independence confirmed	☐
Change population collected	☐
Standard changes tested	☐
GitOps controls reviewed	☐
Direct changes reviewed	☐
Emergency changes reviewed	☐
Production approvals tested	☐
Production releases sampled	☐
Deployment bypass reviewed	☐
Exception register reviewed	☐
Active exceptions tested	☐
Expired exceptions identified	☐
Risk acceptance reviewed	☐
Compliance reporting reviewed	☐
Management review tested	☐
Compliance coverage reviewed	☐
Evidence standards reviewed	☐
Evidence integrity tested	☐
Evidence access reviewed	☐
Evidence gaps documented	☐
Security monitoring ownership reviewed	☐
Incident governance reviewed	☐
Backup governance reviewed	☐
Restore evidence tested	☐
Provisioning governance reviewed	☐
Upgrade governance reviewed	☐
Unsupported clusters identified	☐
Decommissioning reviewed	☐
Multi-cluster consistency assessed	☐
Training reviewed	☐
Governance metrics reviewed	☐
Executive oversight reviewed	☐
Maturity score calculated	☐
Control design assessed	☐
Operating effectiveness assessed	☐
Findings validated	☐
Management actions agreed	☐
Audit opinion issued	☐
Follow-up scheduled	☐

Governance Audit Scorecard

Create reports/governance-scorecard.md.

Governance Domain	Design	Operating Effectiveness	Maturity	Key Finding
Governance framework
Ownership
Policy governance
Privileged access
Separation of duties
Change management
Production governance
Exception management
Risk acceptance
Compliance oversight
Evidence governance
Security operations
Lifecycle governance
Multi-cluster consistency
Training
Executive oversight

Audit Workpaper Template

Create reports/audit-workpaper.md.

Workpaper ID:

Audit Area:

Control Objective:

Audit Procedure:

Population:

Sample:

Evidence Reviewed:

Interviewees:

Test Performed:

Result:

Exceptions Identified:

Finding Reference:

Auditor:

Reviewing Auditor:

Audit Date:

Review Date:

Conclusion:

Executive Summary Template

Create reports/executive-summary.md.

Executive Summary

Audit Title:
Enterprise Kubernetes Governance Audit

Audit Period:

Organisation:

Business Units:

Clusters Reviewed:

Audit Sponsor:

Audit Lead:

Overall Audit Opinion:

Governance Maturity Score:

Governance Maturity Rating:

Critical Findings:

High Findings:

Medium Findings:

Low Findings:

Key Strengths:

Key Weaknesses:

Immediate Actions:

Management Commitment:

Residual Risk:

Next Review Date:

Final Audit Report Template

Create reports/final-audit-report.md.

Audit Title:
Enterprise Kubernetes Governance Audit

Audit ID:

Audit Period:

Report Date:

Organisation:

Audit Sponsor:

Audit Committee Reference:

Audit Lead:

Auditors:

Business Units:

Cloud Providers:

Clusters Reviewed:

Environments Reviewed:

Audit Objectives:

Audit Scope:

Audit Exclusions:

Audit Criteria:

Audit Methodology:

Sampling Method:

Audit Limitations:

Governance Framework Status:

Cluster Ownership Coverage:

Namespace Ownership Coverage:

Policy Ownership Coverage:

Critical Policies Enforced:

Cluster-Admin Identities:

Unapproved Privileged Access:

Access-Review Status:

Separation-of-Duties Status:

Change-Control Status:

Direct Production Changes:

Production-Gate Status:

Active Exceptions:

Expired Exceptions:

Risk-Acceptance Status:

Compliance Coverage:

Evidence Completeness:

Policy Drift Findings:

Unsupported Clusters:

Governance Maturity Score:

Governance Maturity Rating:

Control Design Conclusion:

Operating Effectiveness Conclusion:

Critical Findings:

High Findings:

Medium Findings:

Low Findings:

Management Action Summary:

Residual Risk:

Overall Audit Opinion:

Satisfactory

Needs Improvement

Unsatisfactory

No Assurance

Executive Recommendations:

Follow-Up Date:

Approvals:

Audit Lead:

Head of Internal Audit:

Kubernetes Security:

Platform Engineering:

Cloud Security:

Compliance:

Risk Owner:

CISO:

Audit Committee Sponsor:

Follow-Up Audit Procedure

Step 87 — Track Open Findings

Track:

Finding ID	Severity	Owner	Due Date	Current Status	Evidence

Step 88 — Validate Remediation

For each completed action:

Obtain remediation evidence.
Retest the control.
Confirm the root cause is addressed.
Review new risks.
Confirm owner approval.
Record the validation result.

Step 89 — Close Findings

Close only when:

Remediation is complete.
Evidence is sufficient.
Retesting passes.
Residual risk is acceptable.
Reviewer approval exists.

Step 90 — Escalate Overdue Findings

Escalate based on severity:

Severity	Escalation
Critical	Immediately
High	Weekly until resolved
Medium	Monthly
Low	During routine review

Success Criteria

The governance audit is complete when:

Audit authority and scope are documented.
Audit criteria are defined.
Risk-based samples are selected.
Governance design is assessed.
Operating effectiveness is tested.
Ownership is validated.
Policy governance is reviewed.
Privileged access is tested.
Separation of duties is assessed.
Change controls are tested.
Production governance is reviewed.
Exceptions and risk acceptance are assessed.
Compliance oversight is validated.
Evidence integrity is tested.
Multi-cluster governance is reviewed.
Maturity is scored.
Findings are validated with management.
Management actions are assigned.
An audit opinion is issued.
Follow-up is scheduled.

Operational Best Practices

Use an independent audit identity.
Preserve raw evidence before analysis.
Record UTC timestamps.
Hash critical evidence.
Use risk-based sampling.
Interview both control owners and control users.
Validate documentation against actual implementation.
Do not accept screenshots as the only evidence for critical controls.
Perform peer review of critical findings.
Record scope limitations clearly.
Separate audit findings from improvement suggestions.
Maintain an evidence trail for every conclusion.
Reassess changes made during the audit period.
Escalate evidence-integrity concerns immediately.
Track repeat findings across audit cycles.

Knowledge Check

Question 1

What is the purpose of an enterprise Kubernetes governance audit?

Answer: It determines whether governance controls are appropriately designed, consistently implemented, operating effectively, and supported by reliable evidence and accountability.

Question 2

What is the difference between control design and operating effectiveness?

Answer: Control design assesses whether a control is capable of addressing the intended risk, while operating effectiveness assesses whether the control actually performed consistently during the audit period.

Question 3

Why must auditors remain independent from control owners?

Answer: Independence reduces bias and supports objective assurance over the design and effectiveness of controls.

Question 4

Why is cluster ownership an important audit area?

Answer: Ownership establishes accountability for security, operations, remediation, funding, incidents, risk acceptance, and lifecycle decisions.

Question 5

What is the risk of shared cluster-admin access?

Answer: Shared access prevents reliable attribution, weakens accountability, and increases the risk of unauthorised or untraceable changes.

Question 6

Why should direct production changes be audited?

Answer: Direct changes may bypass review, testing, security gates, separation of duties, rollback controls, and formal evidence collection.

Question 7

Why must risk acceptance be approved by an accountable risk owner?

Answer: The risk owner has authority over the affected business impact and is responsible for accepting residual risk, rather than the technical team that operates the control.

Question 8

What does a No Assurance audit opinion mean?

Answer: It means the auditor could not obtain sufficient reliable evidence or access to form a meaningful conclusion.

Question 9

Why should audit evidence be tamper evident?

Answer: Tamper-evident evidence supports trustworthy conclusions and helps detect unauthorised changes or deletion.

Question 10

When should a follow-up audit be performed?

Answer: A follow-up should occur after remediation deadlines, major governance changes, critical incidents, repeated findings, or according to the audit plan.

Runbook Summary

This runbook established a complete enterprise process for auditing Kubernetes governance.

The audit covered:

Audit planning
Governance framework
Organisational accountability
Cluster ownership
Namespace ownership
Policy governance
Privileged access
Separation of duties
Change management
Production deployment
Exceptions
Risk acceptance
Compliance oversight
Evidence integrity
Security operations
Backup and recovery
Cluster lifecycle
Multi-cluster consistency
Training
Governance metrics
Executive oversight
Maturity assessment
Control design
Operating effectiveness
Findings management
Audit reporting
Follow-up

A strong Kubernetes governance programme ensures that technical security controls are supported by:

Clear authority
Accountable ownership
Independent oversight
Approved policies
Controlled access
Traceable changes
Reliable evidence
Governed exceptions
Informed risk decisions
Continuous improvement

Module Completion

You have completed the Kubernetes Benchmarks, Governance and Compliance module.

The module included:

Labs

CIS Kubernetes Benchmark Assessment
Gatekeeper Policies
Kyverno Policies
Compliance Automation
Kubernetes Governance Assessment

Runbooks

Kubernetes Compliance Assessment
Enterprise Policy Review
Enterprise Governance Audit

These lessons, labs, and runbooks prepare students to assess, implement, automate, govern, and audit Kubernetes security controls in enterprise environments.