Key takeaway
Assign an owner and purpose to every access path. Grant permissions through approved roles, review them regularly and revoke them when no longer needed.
Define the identity lifecycle
Define how employee, contractor, service and emergency accounts are created, who approves them and which system is the source of record. Grant only approved role access at onboarding; revisit existing permissions when a person changes teams or duties. When employment or a contract ends, assign an owner and target time to disable accounts, revoke tokens and rotate keys. Lifecycle automation does not replace ownership and exception review. After disablement and token revocation, verify effective loss of access in each connected application; record residual session expiry where immediate revocation is unsupported.
Strengthen sign-in and limit permissions
Require MFA for email, remote access, admin consoles and systems holding sensitive data. Prefer phishing-resistant methods for administrators and critical systems; do not treat weaker MFA as complete protection. Grant role-based access through RBAC or suitable attribute rules, and avoid broad groups and shared user accounts. Limit service-to-service permissions as carefully as human access, and manage stored secrets.
Review access and keep an audit trail
For each sensitive system, record the business owner, data class, approver and access-review interval. Periodically review unused permissions, temporary exceptions, role combinations and conflicting duties. Send changes, approvals, sign-ins and revocations to a centralized tamper-resistant log. Collection alone is not enough: define who investigates alerts, how long records are kept and how issues are escalated.
Retain approvals and audit evidence
Keep a traceable link between the requester, resource owner and approved role. For sensitive data, record purpose, approval date, last review and expiry; after a change, verify that group and application permissions actually updated. Logs and reports can support an audit, but they do not replace organizational obligations, control testing or legal review. Assign an owner and expiry to every exception.
Store passwords and secrets correctly
A password verifier and a secret that must later be retrieved need different storage. Match the storage and operational checks to each use. Do not store user passwords in plaintext or with reversible encryption; use a deliberately slow password-hashing algorithm and tune its work factor for the environment.
| Credential use | Storage approach | Operational check |
|---|---|---|
| User-password verification | Unique salt and suitable password hash | Algorithm and work factor |
| Retrievable service/API secret | Encrypted managed secret store | Least-privilege retrieval, audit and rotation |
| Employee passwords | Approved managed password manager | Unique passwords, strong vault access and recovery |