SOC 2 Password Requirements: CC6.1 Explained

What SOC 2 actually is

SOC 2 is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA) that evaluates how service organisations handle customer data. Unlike prescriptive standards such as PCI-DSS, SOC 2 is principles-based — it describes outcomes rather than specific technical controls. This gives SaaS companies flexibility in implementation, but it also means that the audit is a judgment call by an independent CPA firm, not a checkbox exercise.

SOC 2 evaluates against five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. The Security criterion is mandatory for all SOC 2 reports. Password controls fall primarily under the Security criterion, specifically under Common Criteria 6 (CC6): Logical and Physical Access Controls.

CC6.1 logical access controls

CC6.1 is the specific criterion that governs access controls to protected data and systems. The full text reads: "The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives."

The AICPA supplemental guidance for CC6.1 identifies several "points of focus" — areas auditors use to evaluate whether the criterion is met. The most relevant to password controls:

• Identifies and authenticates users: The entity identifies and authenticates users before allowing access to protected information or systems
• Restricts access based on business requirements: Access is granted to authorised users in a manner that meets business objectives — least privilege
• Considers network segmentation: Access paths to sensitive systems are restricted
• Manages points of access: Points of access to the system are identified and security controls are implemented at those points
• Authenticates with the environment: Users are identified and authenticated for both local and remote access

What auditors look for

SOC 2 auditors evaluate evidence over a period — typically 6 or 12 months for a Type II report. For password controls, the evidence they want to see:

• Written policy: A documented password policy that sets minimum standards. The policy must be approved, dated, and distributed to all relevant personnel.
• Technical enforcement: Screen-shot or system configuration evidence showing that the technical controls enforce the policy — not just that the policy exists. A written policy saying "12-character minimum" that is not enforced at the system level is a finding.
• Access review logs: Evidence that user access is reviewed periodically (typically quarterly). This includes who has access to what, and how that access was granted and removed.
• MFA evidence: Configuration screenshots or access logs showing MFA is enabled for privileged accounts and, increasingly, for all accounts with access to sensitive systems.
• Terminated user procedures: Evidence showing that access is revoked promptly when employees leave — usually expected within 24 hours of departure.
• Vendor/third-party access: How external access is granted, monitored, and terminated.

Password controls that satisfy CC6.1

SOC 2 does not specify exact values for minimum length or complexity. Auditors evaluate whether controls are "reasonable and appropriate" for the sensitivity of the data being protected. Based on current audit practice and the AICPA guidance:

These represent consensus auditor expectations. A SaaS company storing sensitive customer data whose controls fall below these thresholds is likely to receive a qualified opinion or a management letter finding.

Note that SOC 2 auditors are frequently more demanding than HIPAA or ISO 27001 auditors on the privileged access side — the 16-character minimum for admin accounts is genuinely expected, not just recommended.

MFA expectations for SaaS companies

MFA has moved from "recommended" to effectively required in SOC 2 audits. The specific expectations depend on the auditor and the scope of the audit, but the industry baseline as of 2025:

• Required without exception: MFA for all production system access — cloud console, deployment pipelines, database access, secrets management
• Required without exception: MFA for all VPN and remote access
• Required for privileged users: MFA for all administrative accounts in all environments
• Expected: MFA for all employee access to internal systems (SaaS tools, communication platforms, code repositories)
• Documentation: A written MFA policy and evidence of enforcement (IdP configuration screenshots, SSO configuration logs)

The acceptable MFA methods for SOC 2 purposes follow NIST AAL2 guidance: TOTP authenticator apps (Google Authenticator, Authy, 1Password), push notifications (Duo, Okta), or hardware keys (YubiKey). SMS OTP is generally not challenged by auditors but increasingly noted as a risk in management letters.

Documentation requirements

SOC 2 is a documentation-heavy audit. For password and access controls specifically, you need:

1. Information Security Policy: Top-level policy that establishes the security program and delegates to specific sub-policies
2. Access Control Policy: Minimum password standards, MFA requirements, session management, account lockout
3. User Access Management Procedure: How access is granted, modified, and revoked — including timelines for each
4. Privileged Access Management Procedure: How admin/privileged credentials are managed, rotated, and audited
5. Access Review Evidence: Completed periodic access reviews — typically quarterly, with sign-off from the reviewer
6. Onboarding/Offboarding Logs: Evidence showing access was granted and revoked in accordance with policy timelines

All policy documents should be version-controlled with an effective date and the approver identified. Auditors look for policies that are actively maintained, not last updated two years ago.

Privileged access and admin accounts

Privileged access management is one of the most scrutinised areas in SOC 2 audits. The standard expectation:

• Admin accounts should be separate from standard user accounts — no dual-use (same account for daily email and production console access)
• Admin credentials must use unique, randomly generated passwords of 16+ characters
• Admin accounts require hardware MFA (YubiKey or equivalent), not just TOTP
• Shared admin credentials are a finding — each admin needs an individually attributed account
• Break-glass accounts (emergency access) must be documented, secured, and audited on every use
• Admin access must be reviewed at least quarterly, with role changes triggering immediate review
• Credentials in source code, configuration files, or CI/CD pipelines are findings — use secrets management (HashiCorp Vault, AWS Secrets Manager, etc.)

SOC 2 password checklist

1. Written Access Control Policy exists, is version-controlled, and was reviewed within the past 12 months
2. Minimum 12-character password length technically enforced for standard accounts
3. Minimum 16-character password length technically enforced for admin and privileged accounts
4. MFA required and enforced for all admin and production system access
5. MFA required for all VPN and remote access
6. Account lockout after 5–10 failed attempts, configured in IdP
7. Session timeout ≤ 30 minutes configured for sensitive systems
8. Quarterly access reviews completed and documented, with evidence
9. Terminated user offboarding process documented, with completion within 24 hours
10. No shared admin credentials — each admin has individually attributed account
11. No credentials in source code or configuration files — secrets management system in use
12. Break-glass accounts documented, secured, and audit-logged
13. Vendor/third-party access documented with defined scope and expiry