Security Architecture
Sensitive data, telemetry, logs, backups, administrative sessions, secrets, and keys are protected through approved encryption and key-management controls.
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
Sensitive data is encrypted across storage and transmission paths, while access to keys and cryptographic administration remains narrower than access to the protected data.
First SOC 2 program
Use managed encryption for databases, object stores, disks, logs, and backups; require modern transport encryption at public and administrative boundaries; store secrets separately; and limit key administration to a small group outside ordinary application access.
As the company scales
Maintain a cryptographic inventory, use service-specific keys where risk warrants, automate certificate renewal and key rotation, monitor key use and policy changes, and design recovery so key loss does not make protected data permanently unavailable.
Map where sensitive customer and company data is stored, copied, logged, backed up, exported, and transmitted, including internal service and administrator connections.
You should end up with: A data-to-encryption inventory covering primary stores, replicas, logs, backups, exports, and network paths.
Record the managed encryption, transport, certificate, key, and secret-handling mechanism used for each path, plus the accountable service and security owners.
You should end up with: A cryptographic decision record with expected settings and ownership by data path.
Configure encryption for data stores, object storage, disks, telemetry, logs, and backups, and enforce encrypted connections for public, administrative, and sensitive internal traffic.
You should end up with: Service configuration exports and connection tests demonstrating protected storage and transmission.
Grant applications only the cryptographic operations they need, restrict policy changes and deletion, log key use, and prevent broad data administrators from automatically becoming key administrators.
You should end up with: Key policies, administrator memberships, and audit events showing constrained key operations.
Rotate keys or certificates according to risk, verify consumers adopted the new material, monitor expiry, and test recovery or restore paths without exposing key material.
You should end up with: Rotation and renewal events plus a successful recovery or restore result for protected data.
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.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
The current state of identified databases, object stores, disks, logs, replicas, exports, and backups uses the approved at-rest protection and key reference.
Include this context
Resource ID and data type
Include this context
Environment
Include this context
Encryption status and mechanism
Include this context
Key reference
Include this context
Scope or coverage
Include this context
Generated-at timestamp
Weak evidence to avoid
A provider page saying encryption is available without the production resource ID, enabled state, key reference, backup coverage, or timestamp.
Confirm what the record proves
Current key and secret administration, usage permissions, rotation or expiry settings, deletion safeguards, and logging are restricted for identified production resources.
Include this context
Key or secret ID
Include this context
Purpose and environment
Include this context
Usage policy
Include this context
Administrator policy
Include this context
Rotation or expiry setting
Include this context
Generated-at timestamp
Weak evidence to avoid
A key alias or secret name with no effective policies, administrators, protected-resource link, rotation setting, deletion safeguard, or timestamp.
Confirm what the record proves
The current public, administrative, service, and data-store endpoints enforce approved encrypted protocols and valid certificates for the scoped paths.
Include this context
Endpoint or service
Include this context
Environment
Include this context
Protocol and minimum version
Include this context
Certificate identity and expiry
Include this context
Enforcement mode
Include this context
Test or capture timestamp
Weak evidence to avoid
A browser padlock on one public page with no administrative, internal, or database path coverage and no protocol, certificate, or test detail.
Confirm what the record proves
Key use and administration are attributable, and rotations activate the intended replacement, preserve needed access, and retire or constrain prior key material.
Include this context
Key ID
Include this context
Actor or service
Include this context
Access or rotation action
Include this context
Event timestamp
Include this context
Affected resource
Include this context
Outcome and prior-key state
Weak evidence to avoid
A ticket stating ‘key rotated’ without provider events, key ID, affected resources, consumer validation, prior-key state, or completion time.
Type 1
As of the selected date, retain the current data-to-encryption inventory, current resource, key, secret, and TLS configurations, current administrator assignments, and the latest completed key or certificate rotation or recovery exercise.
Type 2
Include every in-scope sensitive store, log destination, replica, backup, export path, administrative connection, and sensitive service connection at each required review point, plus every encryption-state, key-policy, key-administrator, rotation, certificate, expiry, deletion, and cryptographic exception event during the review period.
Reconcile the data-flow and asset inventories to cloud resources, log destinations, backups, certificate endpoints, and key references, then reconcile configuration and audit histories to all cryptographic changes, rotations, expiry events, and approved exceptions.
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: Sensitive data is encrypted across storage and transmission paths, while access to keys and cryptographic administration remains narrower than access to the protected data.
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 data-flow and asset inventories to cloud resources, log destinations, backups, certificate endpoints, and key references, then reconcile configuration and audit histories to all cryptographic changes, rotations, expiry events, and approved exceptions.
As of the selected date, retain the current data-to-encryption inventory, current resource, key, secret, and TLS configurations, current administrator assignments, and the latest completed key or certificate rotation or recovery exercise.
Include every in-scope sensitive store, log destination, replica, backup, export path, administrative connection, and sensitive service connection at each required review point, plus every encryption-state, key-policy, key-administrator, rotation, certificate, expiry, deletion, and cryptographic exception event during the review period.
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 state of identified databases, object stores, disks, logs, replicas, exports, and backups uses the approved at-rest protection and key reference.
For each selected record, confirm it demonstrates Current key and secret administration, usage permissions, rotation or expiry settings, deletion safeguards, and logging are restricted for identified production resources.
For each selected record, confirm it demonstrates The current public, administrative, service, and data-store endpoints enforce approved encrypted protocols and valid certificates for the scoped paths.
For each selected record, confirm it demonstrates Key use and administration are attributable, and rotations activate the intended replacement, preserve needed access, and retire or constrain prior key material.
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.