Back to Blog
Controls 5 min read

SOC 2 Password Policy Requirements: What to Configure

Configure your password policy for SOC 2 compliance. Learn minimum length, complexity, rotation, and history requirements auditors expect under CC6.2.

Key Takeaways
  • SOC 2 CC6.2 requires authentication controls — documented password policy is a baseline requirement.
  • NIST 800-63B recommendations (length over complexity, no mandatory rotation without breach) align with modern auditor expectations.
  • AWS IAM password policy must be configured with minimum 14 characters and password history of 24.
  • Password managers should be provisioned to all employees to support strong password hygiene.
  • Enforce the policy technically — auditors prefer enforced policies over honor-system ones.

Why a Password Policy Is Required

A password policy is a CC6.2 requirement — authentication controls must be in place before granting access to the system. A written, enforced password policy demonstrates that access to systems is protected by credentials meeting a minimum security standard.

Even with MFA deployed, password policies matter: weak passwords increase the risk of offline cracking if password hashes are ever exposed, and many systems fall back to password-only authentication in edge cases. A strong password policy is a defense-in-depth measure.

Minimum Requirements for SOC 2

Based on auditor expectations and NIST 800-63B guidance, a SOC 2-compliant password policy for employee accounts should require: minimum 14 characters length (NIST recommends length as the primary security factor), no mandatory complexity rules that encourage predictable patterns (like "P@ssw0rd"), prohibition of commonly used passwords and those found in breach databases, and prohibition of reusing the previous 24 passwords.

On rotation: NIST 800-63B recommends against mandatory periodic rotation unless there is evidence of compromise. Many SOC 2 auditors now accept this position. If you have MFA enforced, you can reasonably set rotation to "only on suspected compromise" rather than annually — document this reasoning in your policy.

For privileged accounts (admin, production access), more stringent requirements are appropriate: 16+ character minimum, mandatory rotation annually, hardware key or TOTP required.

Configuring AWS IAM Password Policy

The AWS IAM password policy applies to all IAM users with console access. Configure it via IAM > Account Settings > Password policy: minimum password length 14, require at least one uppercase letter, one lowercase letter, one number, one non-alphanumeric character, allow users to change their own password, enable password expiration (365 days), prevent password reuse (24 passwords).

Via AWS CLI: aws iam update-account-password-policy --minimum-password-length 14 --require-uppercase-characters --require-lowercase-characters --require-numbers --require-symbols --max-password-age 365 --password-reuse-prevention 24.

Screenshot the configured policy from the IAM console as evidence. Auditors also check the IAM credential report to verify no users have passwords older than the configured maximum.

Employee Password Policy and Password Managers

Your employee password policy should extend beyond AWS to cover all work-related accounts: SSO provider, GitHub, cloud consoles, admin tools. The policy should specify the minimum length, prohibition of password reuse across services, and prohibition of personal passwords for work accounts.

Provision a password manager (1Password Teams, Bitwarden Business, or Dashlane Business) to all employees. This enables compliance with complex password requirements without creating the usability problem that leads to password reuse. Document the password manager as the approved tool in your policy.

Auditors appreciate seeing a provisioned password manager because it demonstrates that the organization has made compliance practical, not just mandatory.

Documenting and Communicating the Policy

The password policy must be written, versioned, and communicated to all employees. Include it in your information security policy or as a standalone document. Reference it in your onboarding checklist — new employees should read and acknowledge the password policy on their first day.

Include in the policy: scope (who it applies to), password requirements for different account types, password manager requirement, process for reporting suspected compromise, and consequences for non-compliance.

Password Policy Evidence

(1) Written password policy document with approval signature and review date. (2) AWS IAM password policy screenshot from console. (3) IdP (Okta, Google Workspace) password policy configuration screenshot. (4) Password manager provisioning — MDM or license report showing all employees have access. (5) Employee acknowledgment that they have read the password policy (onboarding records).

Frequently Asked Questions

Does SOC 2 require annual password rotation?
Not explicitly. The AICPA criteria require authentication controls (CC6.2) but don't specify rotation frequency. NIST 800-63B recommends against mandatory rotation absent evidence of compromise. Configure your policy to align with current best practice, document the rationale, and ensure your auditor agrees during the readiness phase.
If we enforce MFA everywhere, does the password policy still matter?
Yes. MFA and password policy are complementary, not alternative controls. CC6.2 expects both. Additionally, some systems or edge cases may not support MFA — having a strong password policy ensures those cases are not completely unprotected.
Can we use passphrases instead of complex passwords?
Yes. A passphrase like "correct-horse-battery-staple" is 28 characters and extremely strong. NIST 800-63B supports this approach. Configure your policy to accept any 14+ character password and educate employees that passphrases are an excellent option.
What should we do if an employee's password is found in a breach database?
Your password policy should define this: immediate forced reset, investigation of any suspicious activity on the account, and notification to the employee. Some IdP tools (Okta, Microsoft Entra ID) can automatically detect compromised credentials against HaveIBeenPwned and force a reset.
Does the password policy need to cover contractors?
Yes. Your policy should state that it applies to all individuals with access to company systems — employees, contractors, and vendors. If contractors use your IdP (Okta), the policy is enforced automatically. If they access systems with their own credentials, require them to attest to compliance with equivalent standards.

Automate your compliance today

AuditPath runs 86+ automated checks across AWS, GitHub, Okta, and 14 more integrations. SOC 2 and DPDP Act. Free plan available.

Start for free