Use individual logins when the tool supports them. Sharing one password makes it harder to remove one person’s access and work out who changed something.
For SOC 2, a shared login needs more thought than “the password is in our vault.” You still need to control who can use it and understand what the available records can prove.
A shared mailbox is not the same as a shared password
Several people can work from a support mailbox while signing in through their own accounts. That can preserve individual access controls. Giving everyone the same mailbox password is a different setup.
Check how your tool actually works before deciding that a team needs a shared login. Sometimes delegated access or separate user seats solve the problem.
Start with three questions
- Can we remove one person’s access without disrupting everyone else?
- Can we tell who performed an important action?
- Does each person need everything this account can do?
If one shared account lets every employee export customer records and change security settings, cheaper licensing may be buying a much larger access problem.
What if the tool only supports one account?
Consider replacing the tool or limiting what you use it for. If you keep it, document the reason and have the responsible owner approve the arrangement. Follow any stricter company policy or contractual restriction.
Limit access to the people who need it. Protect the credentials with an approved method. Use the tool’s available security features and review important activity.
A password-vault record may show who retrieved a secret. It does not necessarily prove who used the application afterward. Be clear about that gap rather than treating the vault as a complete audit trail.
When someone leaves, removing their vault access may not be enough. They may know the password or have an active session. Check the tool’s options for changing credentials and ending sessions. Verify that the person can no longer use the account.
Explain the real arrangement to the auditor
Show how access is approved and removed. Explain what the activity records identify and what they cannot. Do not describe individual user accounts if the team actually shares one.
SOC 2 evaluates the relevant controls in context. A written exception does not automatically make an arrangement adequate. If you cannot control access or establish accountability for sensitive actions, fix the design rather than adding more paperwork.
Sources
- AICPA Trust Services Criteria: CC6.1–CC6.3 address access protection, authorization and removal.
- NIST SP 800-53 Revision 5: AC-2(9) discusses the accountability risk of shared accounts. This is supporting security guidance, not a separate SOC 2 requirement.