Compliance Mapping for Identity Systems
Auditors will ask the same questions of your identity system every year. Build the evidence into the product, especially audit logs, access reviews, and change records, so each audit is an export instead of a scramble.
What each framework asks of authentication
| Framework | What it expects from your identity platform |
|---|---|
| SOC 2 (Trust Services Criteria) | Logical access controls, MFA for administrative access, change management, monitoring, incident response, vendor management, and evidence over a review period |
| ISO/IEC 27001 | An information security management system with controls for access management, authentication information, cryptography, logging, and secure development |
| PCI DSS 4.0 | For systems in the cardholder data environment: MFA for all access to it (8.4.2), MFA systems that resist replay and cannot be bypassed (8.5.1), and a 12-character password minimum where passwords are used (8.3.6), all mandatory since March 31, 2025 (Cloud Security Alliance) |
| HIPAA Security Rule | Unique user identification, person or entity authentication, automatic logoff, audit controls, and encryption for systems holding protected health information |
| NIST SP 800-63-4 | Identity proofing, authentication, and federation assurance levels; required for many US government integrations and a useful design reference for everyone |
| GDPR, DPDP, PIPL | Lawful basis, minimization, rights handling, breach notification, transfers (Chapter 16) |
Audit events to log from day one
Log each event with timestamp, tenant, user, actor (user, admin, system, or support agent), IP, device, result, and a correlation ID. Never log passwords, codes, tokens, or full secrets.
- Sign-in success and failure, with method and risk score
- MFA and passkey enrollment, use, and removal
- Password changes and resets
- Email and phone changes
- Session creation and revocation
- Recovery started, cancelled, and completed
- Admin actions: user changes, role changes, impersonation, policy changes
- SSO connection changes and certificate updates
- SCIM provisioning and deprovisioning
- OAuth client creation, secret rotation, and consent grants
- Key management actions
Store audit logs append-only, with integrity protection (for example hash chaining or write-once storage), and give tenant admins a filtered export or stream.
Controls to build into the admin side
- Phishing-resistant MFA required for every employee with access to production identity data
- Role-based access for admin and support tools, with least privilege
- Just-in-time access and approval for production database queries
- Support impersonation that requires a ticket, is time-limited, and is visible to the customer
- Quarterly access reviews generated from your own data
Security testing evidence
- Annual third-party penetration test of the identity platform, plus after major changes
- OpenID Connect conformance results for your authorization server
- A public bug bounty or vulnerability disclosure program with a clear scope
Warning
Common mistakes
- Audit logs that admins can edit or delete.
- Support tools that bypass the controls your users must pass.
- Treating PCI DSS rules as your consumer password policy, which conflicts with NIST guidance outside the cardholder data environment.
Key takeaways
- Build audit evidence into the product so each audit is an export, not a scramble.
- Log every security event with actor, result, and correlation ID, never with secrets.
- Hold your own staff and support tools to stricter controls than your users.
- Apply PCI DSS password rules inside the cardholder data environment only, not as your consumer policy.