Logical Access
Service accounts, API keys, tokens, certificates, automation credentials, and privileged secrets are inventoried where feasible, least-privileged, protected, rotated or reviewed based on risk, and removed when no longer required.
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
Service accounts, API keys, tokens, certificates, automation credentials, and privileged secrets have known owners, constrained permissions, protected storage, monitored use, and a reliable retirement path.
First SOC 2 program
Place production secrets in a managed secrets service, stop committing credentials to source control or build settings, assign an owner to every machine identity, separate credentials by service and environment, and scan repositories for exposed values.
As the company scales
Prefer workload identity and short-lived credentials, automate rotation and certificate renewal, centralize machine-identity inventory, detect stale or unusual use, and make revocation part of service and employee lifecycle workflows.
Scan source, delivery settings, cloud accounts, application runtimes, integrations, and certificate stores for credentials and machine identities, including values that are no longer referenced.
You should end up with: An initial secret and service-identity inventory with location, purpose, environment, and last-known use.
Record the service owner, target systems, permissions, exposure impact, creation method, expiry or review date, and approved consumers for each active identity.
You should end up with: An accountable inventory that highlights unknown owners, broad privilege, and long-lived credentials.
Move secrets into a managed service, restrict read and administration permissions, inject values only at runtime, mask them from logs, and separate production from nonproduction.
You should end up with: Secrets-service configuration and access policies showing controlled retrieval and environment separation.
Rotate exposed, shared, ownerless, or aging credentials using a tested sequence that supports overlap where needed, confirms the new value works, and revokes the old value.
You should end up with: Rotation events, deployment confirmation, and revocation evidence tied to the affected identity.
Alert on unusual secret retrieval, failed machine authentication, expired certificates, dormant keys, and use from unexpected workloads; retire credentials when integrations or services end.
You should end up with: Usage alerts, expiry monitoring, periodic review decisions, and credential revocation records.
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 current machine-identity population records a responsible owner, purpose, environment, privileges, consumers, and lifecycle state for each service account.
Include this context
Service identity
Include this context
Owner and purpose
Include this context
Environment and systems
Include this context
Privileges
Include this context
Credential type
Include this context
Review or expiry date
Weak evidence to avoid
A list of account names with no owner, workload, environment, effective privilege, credential type, or lifecycle date.
Confirm what the record proves
The current managed store identifies protected production secrets, their locations, access policies, versions, owners, and recent use without exposing secret values.
Include this context
Secret identifier
Include this context
Environment
Include this context
Owner or service
Include this context
Access policy
Include this context
Version or rotation date
Include this context
Last-used or status field
Weak evidence to avoid
A screenshot of secret names that omits environment, access policy, owner, version age, usage status, and the scope of the export.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
Confirm what the record proves
The owner evaluated a credential’s need and privilege or completed a rotation sequence that activated the replacement and retired the prior value.
Include this context
Credential or secret ID
Include this context
Owner or reviewer
Include this context
Review or rotation date
Include this context
New-version activation
Include this context
Old-version revocation
Include this context
Consumer validation result
Weak evidence to avoid
A new secret version exists, but there is no proof consumers adopted it, the previous credential was revoked, or an owner reviewed continued need.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
An expired, exposed, dormant, or retired service credential was disabled and subsequent attempts or use no longer succeed.
Include this context
Credential identifier
Include this context
Revocation reason
Include this context
Revocation timestamp
Include this context
Actor or automation
Include this context
Affected consumers
Include this context
Resulting status
Weak evidence to avoid
A ticket says a key was removed without a provider event, credential identifier, revocation time, consumer impact, or final disabled state.
Type 1
As of the selected date, retain the current service-account and managed-secret inventories, effective access policies, and the latest completed credential review or rotation with confirmed prior-version revocation.
Type 2
Include every active service account, API key, token, certificate, automation credential, and privileged secret at each required review point, plus every creation, permission change, retrieval-policy change, rotation, expiry, revocation, exposure, and retirement event during the review period.
Reconcile cloud service identities, managed secrets, certificates, delivery variables, and discovered credentials to the service-account register, then reconcile rotation and revocation events to active versions and actual recent use so dormant or unmanaged credentials cannot disappear from the population.
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: Service accounts, API keys, tokens, certificates, automation credentials, and privileged secrets have known owners, constrained permissions, protected storage, monitored use, and a reliable retirement path.
Compare the documented owner with the intended role (IT / Infrastructure Owner / System Owners), then compare dated records with the stated cadence: Per request/change; periodic review quarterly/annually by risk.
Reconcile cloud service identities, managed secrets, certificates, delivery variables, and discovered credentials to the service-account register, then reconcile rotation and revocation events to active versions and actual recent use so dormant or unmanaged credentials cannot disappear from the population.
As of the selected date, retain the current service-account and managed-secret inventories, effective access policies, and the latest completed credential review or rotation with confirmed prior-version revocation.
Include every active service account, API key, token, certificate, automation credential, and privileged secret at each required review point, plus every creation, permission change, retrieval-policy change, rotation, expiry, revocation, exposure, and retirement event 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 current machine-identity population records a responsible owner, purpose, environment, privileges, consumers, and lifecycle state for each service account.
For each selected record, confirm it demonstrates The current managed store identifies protected production secrets, their locations, access policies, versions, owners, and recent use without exposing secret values.
Records showing that an accountable person reviewed, approved, challenged, or accepted the work.
For each selected record, confirm it demonstrates The owner evaluated a credential’s need and privilege or completed a rotation sequence that activated the replacement and retired the prior value.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates An expired, exposed, dormant, or retired service credential was disabled and subsequent attempts or use no longer succeed.
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.