Security Architecture
Cloud services, organization-managed private cloud/container hosts, registries, images, and runtime environments follow approved secure configuration baselines.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Cloud resources, container images, registries, hosts, clusters, and runtimes begin from approved hardened settings and remain identifiable when they drift from those settings.
First SOC 2 program
Limit the number of approved cloud services and base images, define essential settings for public exposure, identity, logging, encryption, updates, and runtime privilege, deploy them through infrastructure code, and scan images before release.
As the company scales
Maintain versioned baselines by service type, encode them as reusable infrastructure modules and policy checks, continuously compare deployed state with approved settings, and govern exceptions with owners and expiry dates.
List the cloud services, account types, clusters, hosts, registries, base images, and runtime patterns used in production and identify an owner for each baseline family.
You should end up with: A covered-technology inventory with approved use cases and baseline owners.
Specify expected settings for network exposure, administrator access, encryption, logging, backup where relevant, patching, image source, runtime user, capabilities, and secret handling.
You should end up with: Versioned baseline standards with concrete values or decision rules for each deployment type.
Build approved infrastructure modules, image definitions, cluster policies, and registry settings so teams inherit secure defaults rather than configuring every resource manually.
You should end up with: Reviewed deployment modules and image definitions that implement the baseline.
Run infrastructure, image, and runtime-policy checks in delivery pipelines; block or explicitly approve high-risk deviations before they reach production.
You should end up with: Pipeline results tied to a deployment, including resolved findings or approved exceptions.
Compare live state with approved configuration, investigate console changes and obsolete images, and update baseline versions when threats, platform features, or architecture change.
You should end up with: Drift findings, remediation records, expiring exceptions, and dated baseline review decisions.
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Documents that define the control, its scope, ownership, and expected way of working.
Confirm what the record proves
The approved standard defines the expected secure settings by cloud service, image, registry, cluster, host, and runtime type; it establishes the target state rather than proving deployed resources currently match it.
Include this context
Technology or service type
Include this context
Required settings
Include this context
Scope and environment
Include this context
Baseline owner
Include this context
Version and approval date
Include this context
Exception rule
Weak evidence to avoid
A generic hardening article with no approved values, covered service types, environment, internal owner, version, or exception rule.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
An accountable owner compared the approved standard with current deployment and drift findings, then corrected deviations or documented a bounded exception.
Include this context
Baseline version
Include this context
Resource population
Include this context
Reviewer and date
Include this context
Deviation
Include this context
Decision or exception
Include this context
Remediation and closure
Weak evidence to avoid
A statement that the baseline was reviewed with no current-state population, identified drift, exception record, remediation, or closure evidence.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
The current deployed state for identified cloud and runtime resources can be compared field by field with the approved baseline at a stated time.
Include this context
Resource ID and type
Include this context
Account and environment
Include this context
Effective setting values
Include this context
Baseline version
Include this context
Generated-at timestamp
Include this context
Exception reference
Weak evidence to avoid
A cropped resource page with no resource ID, account, environment, baseline version, capture time, or indication of accepted deviations.
Confirm what the record proves
The current registry and image controls enforce approved sources, tag or digest handling, scanning, access, retention, and runtime-relevant restrictions for deployed images.
Include this context
Registry and repository
Include this context
Image tag or digest
Include this context
Scan and access settings
Include this context
Effective policy
Include this context
Environment or consumers
Include this context
Generated-at timestamp
Weak evidence to avoid
One image’s passing scan badge without its digest, registry policy, access restrictions, deployed consumer, effective settings, or timestamp.
Type 1
As of the selected date, retain the current approved baseline standard, current-state exports for representative cloud, registry, image, cluster, and runtime resources, and the latest review showing deviations were remediated or recorded as explicit exceptions.
Type 2
Include every approved baseline version or change; every in-scope cloud resource, image, registry, cluster, host, and runtime evaluated by required deployment or posture checks; every detected deviation; and every remediation, approved exception, expiry, and re-evaluation during the review period.
Reconcile the cloud and runtime asset inventory plus every pushed or deployed image to baseline-check coverage, then reconcile each difference between the approved standard and observed current state to a corrected configuration or an owner-approved, expiring exception.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Cloud resources, container images, registries, hosts, clusters, and runtimes begin from approved hardened settings and remain identifiable when they drift from those settings.
Compare the documented owner with the intended role (Infrastructure / Security Operations / IT), then compare dated records with the stated cadence: Continuous/ongoing; periodic review by risk.
Reconcile the cloud and runtime asset inventory plus every pushed or deployed image to baseline-check coverage, then reconcile each difference between the approved standard and observed current state to a corrected configuration or an owner-approved, expiring exception.
As of the selected date, retain the current approved baseline standard, current-state exports for representative cloud, registry, image, cluster, and runtime resources, and the latest review showing deviations were remediated or recorded as explicit exceptions.
Include every approved baseline version or change; every in-scope cloud resource, image, registry, cluster, host, and runtime evaluated by required deployment or posture checks; every detected deviation; and every remediation, approved exception, expiry, and re-evaluation during the review period.
Documents that define the control, its scope, ownership, and expected way of working.
For each selected record, confirm it demonstrates The approved standard defines the expected secure settings by cloud service, image, registry, cluster, host, and runtime type; it establishes the target state rather than proving deployed resources currently match it.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates An accountable owner compared the approved standard with current deployment and drift findings, then corrected deviations or documented a bounded exception.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates The current deployed state for identified cloud and runtime resources can be compared field by field with the approved baseline at a stated time.
For each selected record, confirm it demonstrates The current registry and image controls enforce approved sources, tag or digest handling, scanning, access, retention, and runtime-relevant restrictions for deployed images.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.