SOC 2 Evidence Collection
How do I collect MFA evidence for SOC 2?
October 30, 20252 min read
What Auditors Check for MFA
The distinction that matters: MFA must be enforced, not just enabled. If MFA is optional and three team members haven't set it up, that's a finding.
Auditors check two things:
- The system is configured to require MFA (configuration evidence)
- All users have MFA active (population evidence)
Where to Collect MFA Evidence
| System | What to Screenshot | Why It Matters |
|---|---|---|
| Google Workspace / Okta | Admin settings showing "Enforce MFA for all users" | Primary identity provider |
| AWS Console | IAM policy requiring MFA for console access | Cloud infrastructure |
| GitHub | Organization settings showing "Require 2FA" | Code repository |
| Application admin panel | MFA settings if your app has admin login | Application access |
| VPN (if used) | VPN configuration requiring MFA | Network access |
Step-by-Step Evidence Collection
1. Configuration Evidence
Screenshot your identity provider's MFA enforcement setting. Show the admin page where MFA is marked as required, not just "recommended" or "available."
2. User Enrollment Evidence
Export or screenshot the user list showing MFA status for each account. Every active user should show MFA as enrolled/active.
3. MFA Method Documentation
Document which MFA methods are accepted (hardware keys, TOTP app, SMS). Note: auditors prefer hardware keys or TOTP apps over SMS, which is vulnerable to SIM swapping.
Common Issues
- MFA available but not enforced: Change the setting from "optional" to "required" before the audit.
- Service accounts without MFA: If you have service accounts or API keys, document these as exceptions with compensating controls (IP restrictions, short-lived tokens).
- New employee gap: Ensure your onboarding process includes MFA setup on day one. Auditors may check onboarding records.
- Personal devices: If employees use personal phones for TOTP, that's fine, auditors care about the factor existing, not the device type.