Controls3 May 2026 6 min read

Secrets Management for SOC 2: AWS Secrets Manager Setup

Manage API keys, database passwords, and credentials securely for SOC 2. Learn AWS Secrets Manager configuration, rotation, and audit trail requirements.

Key Takeaways

Hardcoded secrets in source code are a critical CC6.1 finding — shift to AWS Secrets Manager or Parameter Store.
Secrets Manager supports automatic rotation for RDS, Redshift, and custom Lambda rotators.
All secret access is logged in CloudTrail, providing the audit trail required by CC7.2.
IAM policies should restrict which services and roles can read specific secrets.
Secret scanning in GitHub Actions or pre-commit hooks prevents accidental secret leaks.

In this guide

Why Secrets Management Is a SOC 2 Requirement
AWS Secrets Manager Setup
Automatic Secret Rotation
Access Control for Secrets
Preventing Secret Leaks in Code
Secrets Management Evidence

Why Secrets Management Is a SOC 2 Requirement

Credentials — database passwords, API keys, OAuth tokens, certificate private keys — are the keys to your systems. If they are hardcoded in source code, stored in unencrypted config files, or distributed in plain text, they represent a CC6.1 (access controls) and CC6.6 (protection of data) gap.

Exposed credentials are involved in the majority of cloud breaches. A developer commits an AWS access key to a public GitHub repository; within seconds, automated scanners find it and begin exploiting it. Proper secrets management eliminates this attack vector.

AWS Secrets Manager Setup

AWS Secrets Manager stores, encrypts (using KMS), and provides controlled access to secrets. Create a secret: Secrets Manager console > Store a new secret > choose type (RDS credentials, other database, API key, or other). Specify the key-value pairs (username, password, etc.) and optionally a KMS key for encryption.

Reference secrets in your application using the Secrets Manager SDK — never hardcode the secret value. Example (Node.js): const client = new SecretsManagerClient(); const secret = await client.send(new GetSecretValueCommand({ SecretId: "prod/myapp/db" })); — the application fetches the current value at runtime.

Use resource-based policies on secrets to restrict which AWS accounts, VPCs, or IAM roles can access them. Deny access from outside your production VPC endpoint for database credentials.

Automatic Secret Rotation

Secrets Manager supports automatic rotation for AWS-managed services: RDS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB), Redshift, and DocumentDB. Configure rotation: select the secret > Rotation > Enable automatic rotation > choose rotation interval (30, 60, 90 days) > select or create a Lambda rotation function.

For custom secrets (third-party API keys), write a Lambda rotation function that calls the third-party API to generate a new key, stores it in Secrets Manager, and invalidates the old key. Secrets Manager invokes this Lambda on the rotation schedule.

Automatic rotation eliminates the risk of long-lived static credentials. For RDS specifically, the rotation Lambda updates both the database password and the Secrets Manager value atomically, with no application downtime (using a dual-credential rotation strategy).

Access Control for Secrets

Apply least privilege to secret access. IAM policies for application roles should allow secretsmanager:GetSecretValue only for specific secret ARNs, not "Resource: *". Use condition keys to restrict access to specific VPCs: Condition: {"StringEquals": {"aws:sourceVpc": "vpc-12345"}}.

Deny human access to production secrets except via break-glass procedures. Developers should not be able to read production database passwords directly. If a developer needs to debug a production database issue, they should connect via SSM Session Manager (which establishes a tunnel without exposing credentials) rather than retrieving the password from Secrets Manager.

Enable CloudTrail to log all secretsmanager:GetSecretValue calls. Review these logs as part of your monthly security review — unusual access patterns (a developer account accessing production secrets outside business hours) are a CC7.2 anomaly.

Preventing Secret Leaks in Code

Even with Secrets Manager deployed, developers can accidentally commit secrets to source control. Prevent this with: (1) GitHub Advanced Security secret scanning (free for public repos, paid for private) — automatically scans commits and alerts on detected secrets. (2) Pre-commit hooks using tools like detect-secrets, gitleaks, or truffleHog — block the commit if secrets are detected. (3) CI/CD pipeline step that runs secret scanning on every PR.

If a secret is accidentally committed: rotate the secret immediately (not after the audit), revoke the old secret, investigate CloudTrail to determine if the leaked credential was used, and document the incident for CC7.3.

Secrets Management Evidence

(1) Secrets Manager secrets inventory — list of secrets with last rotated date. (2) Rotation configuration screenshot for RDS and other credentials. (3) IAM policies for application roles showing scoped secretsmanager:GetSecretValue permissions. (4) CloudTrail log showing secret access by authorized roles only. (5) Secret scanning configuration — GitHub Advanced Security settings or CI/CD pipeline step. (6) Policy document prohibiting hardcoded credentials in source code.

Frequently Asked Questions

What is the difference between AWS Secrets Manager and AWS Parameter Store?

Both store secrets securely. Secrets Manager adds automatic rotation and is purpose-built for credentials. Parameter Store (SSM) is cheaper (free for standard parameters) and better for configuration values that don't require rotation. Use Secrets Manager for database passwords, API keys, and OAuth tokens. Use Parameter Store for application configuration (feature flags, environment-specific settings).

We have secrets in environment variables — is that sufficient for SOC 2?

Environment variables are better than hardcoding but worse than Secrets Manager. If the environment variables are injected from Secrets Manager at deploy time (not stored in your CI/CD tool in plaintext), that is acceptable. The risk with env vars is that they can appear in logs, crash dumps, and process listings. Use Secrets Manager SDK calls at runtime for the strongest control.

How do we handle secrets for CI/CD pipelines?

For AWS-hosted CI/CD (CodeBuild, CodePipeline): use IAM roles for the build environment to access Secrets Manager directly — no hardcoded credentials needed. For third-party CI (GitHub Actions, CircleCI): use their secrets management features (GitHub Encrypted Secrets, CircleCI Environment Variables) for pipeline credentials, and use OIDC federation to obtain short-lived AWS credentials rather than storing AWS access keys.

Can Vault (HashiCorp) replace AWS Secrets Manager for SOC 2?

Yes. HashiCorp Vault (or HCP Vault) provides equivalent or stronger secrets management capabilities. It supports dynamic secrets (short-lived credentials generated on demand), fine-grained access policies, and detailed audit logs. It satisfies the same SOC 2 criteria. The evidence approach is similar — document the configuration, show access controls, demonstrate rotation, and export audit logs.

How often should we audit who has access to production secrets?

Review secret access policies as part of your quarterly access review (CC6.3). Additionally, review CloudTrail logs for secretsmanager:GetSecretValue monthly to identify any unexpected access. Secrets with no recent access should be investigated — either they're unused (delete them) or the application accessing them is unhealthy.