Credential sharing and compliance: ISO 27001, SOC 2, GDPR
How controlled credential handover maps to ISO/IEC 27001:2022 Annex A, SOC 2 CC6, Cyber Essentials and UK GDPR Article 32, and the evidence auditors ask for.
On this page
No framework tells you to use one-time links. What ISO/IEC 27001, SOC 2, Cyber Essentials and UK GDPR do expect is that credentials are issued through a controlled process, travel over a protected channel, and stop working when the person no longer needs them, and that you can prove all three. A password sent by email or chat fails on the first two and makes the third hard to show, because copies sit in mailboxes and message history you don’t control.
This page maps credential handover to the clauses that cover it, then lists what an auditor will actually ask to see. It’s written for the person who has to answer those questions, not a substitute for your auditor’s reading of your scope.
Clause by clause
| Framework and clause | What it expects | Where credential handover fits |
|---|---|---|
| ISO/IEC 27001:2022 A.5.17 Authentication information | Allocation and management of authentication information is controlled by a management process. | The core control. ISO/IEC 27002's guidance says credentials, including temporary ones, should reach users over a protected channel and not by unprotected email. |
| A.5.15 Access control | Rules for physical and logical access, based on business and security requirements. | Your access control policy should say how credentials are handed over, not only who gets them. |
| A.5.18 Access rights | Access is provided, reviewed, adjusted and removed according to policy. | When someone leaves, shared credentials they knew are changed. A link that has already been deleted is one less copy to chase. |
| A.5.14 Information transfer | Rules, procedures or agreements for transferring information, internally and to other parties. | Sending credentials to clients, contractors and suppliers is information transfer. Name the approved method. |
| A.8.15 Logging | Logs recording activities, exceptions, faults and other relevant events are produced, stored, protected and analysed. | A record of when a credential was sent, opened, failed or destroyed, without the credential in it. |
| SOC 2 CC6.1, CC6.2, CC6.3 | Logical access is restricted; users are registered and authorised before credentials are issued; access is changed and removed as roles change. | Evidence that credentials were issued after approval, to the right person, and withdrawn at the end. |
| SOC 2 CC6.7 | Transmission, movement and removal of information is restricted to authorised users and protected in transit. | Credentials sent outside the organisation go by an approved, protected route. |
| Cyber Essentials: user access control | An approval process for creating accounts, unique credentials for each user, MFA where available (always for cloud services), and accounts removed or disabled when no longer needed. | Mostly about accounts rather than handover. Shared logins sit badly with "unique credentials", so expect questions about any you keep. |
| UK GDPR Article 32 | Appropriate technical and organisational measures to secure personal data, including encryption and the ongoing confidentiality of processing systems. | A credential to a system holding personal data is a key to that data. A leaked one can become a breach you have to assess, and report to the ICO within 72 hours if it is notifiable (Article 33). |
Two notes on reading the table. The ISO control numbers are from Annex A of ISO/IEC 27001:2022, which takes its control titles from ISO/IEC 27002:2022. If your certificate is still against the 2013 edition, A.5.17 was split across A.9.2.4, A.9.3.1 and A.9.4.3. And SOC 2 criteria are written as outcomes, so your auditor tests your own controls against them; the wording above is a paraphrase of the AICPA Trust Services Criteria, not a quotation.
If you’re also in scope for PCI DSS, requirement 8.2.2 of version 4.0.1 deals with shared and generic accounts directly: they’re allowed only by exception, for a limited time, with documented justification, management approval and every action attributable to an individual.
What auditors actually ask for
Auditors rarely ask “how do you share passwords?” in those words. The question arrives as a request for evidence, usually one of these:
- The written procedure. Your access control policy or joiner process, showing how initial credentials are issued, how they reach the person, and that temporary passwords must be changed at first sign-in.
- A sample of joiners. For each person in the sample: the approval, the date access was granted, and how the credentials were delivered. “I sent it on Teams” is an answer you’ll have to defend.
- A sample of leavers. The date access was removed, and evidence that shared credentials the person knew were changed. This is where most findings come from, because shared accounts are easy to forget.
- A list of shared and privileged accounts. Each with an owner, a reason it can’t be individual, and how it’s protected.
- Configuration evidence. Screenshots or exports showing the setting that enforces the rule: MFA required, password policy, link expiry limits.
- Logs, and proof someone looks at them. That logging is on, who can read the log, how long it’s kept, and a record of review.
Notice that most of this is about your process, not a tool. A tool helps when it turns a step people might skip into the default, and when it produces the evidence as a side effect.
Where a secret-sharing tool helps, and where it doesn’t
A controlled handover tool can cover the delivery channel (A.5.17, CC6.7) and some of the evidence. In ShareShield’s case:
- The channel. Credentials go as one-time links that are deleted once opened or at expiry. For people outside your organisation, secret requests cover the reverse direction, when a client or supplier needs to send something to you.
- Configuration evidence. Organisation policies set maximum expiry and views, require passcodes and restrict which email domains secrets can go to. The policy screen is the screenshot your auditor wants.
- Logs. The audit log records secrets created, opened, failed and burned, along with member, sign-in, 2FA and SSO events. Professional and Enterprise organisations can export it as CSV for an evidence pack.
- Sign-in controls. Organisations can require 2FA for members and enforce SSO on verified domains, which supports A.8.5 (secure authentication) and CC6.1.
What it doesn’t do: replace a password manager for credentials people use every day, run your access reviews, or change the password when someone leaves. No tool makes you compliant. And any tool you adopt for this becomes a supplier you should assess under the supplier controls, A.5.19 to A.5.22. Start with how it encrypts, which for us is set out in server-side vs end-to-end encryption for secret links.
A procedure you can adapt
If your policy says nothing specific about credential handover yet, this wording is a reasonable starting point:
Authentication information is never sent in email, chat, tickets or documents. Credentials for people outside the password manager are sent as single-use links that expire within 24 hours, with any passcode sent by a different channel. Temporary credentials must be changed at first use. Shared credentials have a named owner and are changed when anyone who knew them leaves or changes role. Credential handovers are logged, and the log is reviewed quarterly.
Adjust the numbers to your own risk assessment, then make sure the tool settings match what the policy says. An auditor will check both. For what that log should contain, see what an audit trail for shared secrets should record.
Send the next one as a link that expires.
ShareShield turns a password, key or file into a link that opens once and is then deleted. You can send a text secret without an account.