Security Architecture
Cloud, container, network, and infrastructure configurations are monitored for insecure settings, exposed services, privilege drift, image risk, and deviations from approved 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
Insecure cloud, container, network, identity, and infrastructure settings are detected across the complete environment, assigned by risk, and verified after remediation or an approved exception.
First SOC 2 program
Enable native cloud-security findings in every account and region, select a focused set of high-impact checks, route findings to one owned queue, and preserve weekly or monthly review and remediation evidence rather than trying to deploy an overly broad platform immediately.
As the company scales
Use a centralized cloud posture or application-protection platform across organizations and clusters, connect findings to infrastructure code and asset criticality, prioritize attack paths and privilege drift, automate tickets, and measure age, recurrence, and exception expiry.
Enumerate cloud organizations, accounts, subscriptions, projects, regions, clusters, registries, and deployment environments, and reconcile each one to an enabled posture source.
You should end up with: A scope-to-sensor coverage map that exposes unmonitored accounts, regions, and clusters.
Enable checks for exposure, logging, encryption, identity privilege, risky network paths, vulnerable images, and baseline drift, then document intentional suppressions to reduce noise without hiding risk.
You should end up with: Enabled standards and rules with severity, scope, and approved tuning decisions.
Enrich findings with asset owner and criticality, define response targets by risk, and route actionable issues into a queue where responsibility and due date are visible.
You should end up with: Finding-to-owner routing, response targets, and representative assigned records.
Correct the configuration through reviewed infrastructure changes where possible; when immediate correction is not appropriate, record risk, safeguards, owner, approval, and expiry.
You should end up with: Linked configuration changes or time-limited exception decisions for sampled findings.
Rescan or query live state to confirm remediation, reopen recurring findings, and review aging, repeated causes, coverage gaps, and expiring exceptions with infrastructure leadership.
You should end up with: Verified closure evidence and a posture summary showing age, recurrence, coverage, and exceptions.
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.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
A known difference from the approved setting is explicit, risk-assessed, owned, approved, protected by stated safeguards, and bounded by an expiry and re-evaluation date.
Include this context
Exception and finding ID
Include this context
Resource and observed deviation
Include this context
Risk and safeguards
Include this context
Owner and approver
Include this context
Approval and expiry dates
Include this context
Re-evaluation status
Weak evidence to avoid
A permanently suppressed finding with no observed deviation, risk reasoning, safeguards, accountable owner, approval, or expiry.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
The monitoring service compared observed current resource state with enabled checks or approved settings and recorded every deviation with affected asset, severity, status, and ownership.
Include this context
Finding ID
Include this context
Account and resource
Include this context
Observed current state
Include this context
Check or expected setting
Include this context
Severity and owner
Include this context
First and last observed times
Weak evidence to avoid
A dashboard risk score with no exported findings, affected resources, observed settings, enabled check, owner, status, or observation dates.
Confirm what the record proves
A reviewer compared the approved infrastructure definition or baseline with deployed current state, investigated differences, and assigned correction or exception decisions.
Include this context
Review ID and date
Include this context
Resource population
Include this context
Approved definition or baseline
Include this context
Observed difference
Include this context
Reviewer and decision
Include this context
Remediation or exception link
Weak evidence to avoid
A statement that drift was reviewed without the approved reference, current resource population, observed differences, reviewer decisions, or follow-up.
Confirm what the record proves
A posture finding was assigned and corrected through a traceable infrastructure change, then verified against current deployed state or a rescan.
Include this context
Ticket and finding ID
Include this context
Resource and owner
Include this context
Required correction
Include this context
Infrastructure change reference
Include this context
Completion timestamp
Include this context
Rescan or state verification
Weak evidence to avoid
A ticket closed after code was merged with no finding link, deployed resource change, rescan, current-state verification, or recurrence check.
Type 1
As of the selected date, retain the current monitored-scope map, enabled posture checks, complete current finding export, and sampled current-state verification for remediated findings and active approved exceptions.
Type 2
Include every expected posture evaluation for each in-scope account, subscription, project, region, cluster, registry, and infrastructure environment; every finding opened, changed, suppressed, excepted, remediated, closed, or recurring; and every required drift review during the review period.
Reconcile every cloud account, region, cluster, registry, and deployment environment to an active posture source and enabled check history, then reconcile native finding exports to tickets, current-state rescans, suppressions, and unexpired exception records.
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: Insecure cloud, container, network, identity, and infrastructure settings are detected across the complete environment, assigned by risk, and verified after remediation or an approved exception.
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 every cloud account, region, cluster, registry, and deployment environment to an active posture source and enabled check history, then reconcile native finding exports to tickets, current-state rescans, suppressions, and unexpired exception records.
As of the selected date, retain the current monitored-scope map, enabled posture checks, complete current finding export, and sampled current-state verification for remediated findings and active approved exceptions.
Include every expected posture evaluation for each in-scope account, subscription, project, region, cluster, registry, and infrastructure environment; every finding opened, changed, suppressed, excepted, remediated, closed, or recurring; and every required drift review during the review period.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates A known difference from the approved setting is explicit, risk-assessed, owned, approved, protected by stated safeguards, and bounded by an expiry and re-evaluation date.
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 monitoring service compared observed current resource state with enabled checks or approved settings and recorded every deviation with affected asset, severity, status, and ownership.
For each selected record, confirm it demonstrates A reviewer compared the approved infrastructure definition or baseline with deployed current state, investigated differences, and assigned correction or exception decisions.
For each selected record, confirm it demonstrates A posture finding was assigned and corrected through a traceable infrastructure change, then verified against current deployed state or a rescan.
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.