Why Secrets Manager Is Central to SOC 2 CC6.1

SOC 2 CC6.1 addresses logical access security, including the management of authentication credentials. For AWS environments, this means: application secrets (database passwords, API keys, OAuth tokens) must not be hardcoded in source code, environment variables, or configuration files, and must be rotated on a defined schedule.

AWS Secrets Manager provides secret storage, retrieval via SDK, and — critically for SOC 2 — automatic rotation via Lambda functions.

SecureSpect checks two Secrets Manager conditions:

aws.secretsmanager.rotation_enabled — CC6.1
For secrets that support rotation (RDS, Redshift, DocumentDB, and custom),
verifies that automatic rotation is configured.
aws.secretsmanager.no_hardcoded_credentials — CC6.1
(Checked via ECS/EKS task definition review — no plaintext credentials
in environment variables pointing to managed services.)

Setting Up Secrets Manager for SOC 2

If you're still using SSM Parameter Store or environment variables for application secrets, here's the migration path:

1. Store secrets in Secrets Manager:

# Store a database credential
aws secretsmanager create-secret   --name production/postgres/app   --secret-string '{"username":"appuser","password":"","host":"prod-db.us-east-1.rds.amazonaws.com","port":5432,"dbname":"production"}'

2. Enable automatic rotation for RDS credentials:

Secrets Manager has native rotation for RDS PostgreSQL, MySQL, Aurora, and Oracle. Enable it through the console or CLI:

aws secretsmanager rotate-secret   --secret-id production/postgres/app   --rotation-lambda-arn arn:aws:lambda:us-east-1:123456789:function:SecretsManagerRotationFunction   --rotation-rules AutomaticallyAfterDays=30

For most production databases, a 30-day or 60-day rotation schedule satisfies SOC 2.

3. Update your application to retrieve secrets from Secrets Manager:

import boto3
import json
def get_secret(secret_name: str) -> dict:
    client = boto3.client('secretsmanager', region_name='us-east-1')
    response = client.get_secret_value(SecretId=secret_name)
    return json.loads(response['SecretString'])
# Usage
db_creds = get_secret('production/postgres/app')

What Auditors Ask About Secrets

During a SOC 2 audit, expect these questions:

"How are application credentials stored?" The answer should be: AWS Secrets Manager for all production credentials, with no credentials stored in code, environment variables, or Kubernetes configmaps.

"How often are credentials rotated?" AWS Secrets Manager rotation logs show when each secret was last rotated. 30–90 days is the typical expected cadence for database credentials.

"What happens when an employee leaves?" For human credentials, Secrets Manager isn't the answer — IAM user deactivation and access review processes are. But for application-to-service credentials, Secrets Manager with rotation means employee departure doesn't require credential rotation (the credential belongs to the service, not the person).

Common Findings

• Secrets stored in ECS task definition environment variables instead of Secrets Manager
• Rotation configured but broken (the rotation Lambda function failing silently)
• No alerting on rotation failures
• API keys for third-party services stored as environment variables rather than Secrets Manager

FAQ

Does SSM Parameter Store satisfy SOC 2? SecureString parameters in SSM Parameter Store using KMS encryption are a valid alternative to Secrets Manager for simple credentials. Secrets Manager provides easier rotation and better auditing for complex multi-field credentials.

What if my application can't be updated to use Secrets Manager? This is a real constraint. In the short term, document the compensating control (manual rotation on a defined schedule, access restricted via IAM). In the long term, plan the migration.

How do I know if rotation is actually working? Check the secret's LastRotatedDate via aws secretsmanager describe-secret --secret-id. Set a CloudWatch alarm on the Secrets Manager rotation failure metric.