Password sharing policy template for small companies

This is a password sharing policy template for a company of roughly 10 to 200 people. It’s twelve clauses, each short enough that people will actually read it, written as policy text you can copy, with a note under each on why it’s worded that way and what to change. It covers what may be shared, how, with whom, how long it’s kept, when it’s changed, and how exceptions work.

It’s written to sit inside an ISO/IEC 27001 management system or alongside a Cyber Essentials certification, and the table at the end maps each clause to the controls it supports. It isn’t legal advice, and your auditor reads your policy against your risk assessment, not ours.

How to use it

1. Replace everything in square brackets: your company name, your password manager, the role that owns the policy.
2. Delete clauses that don’t apply. A company with no physical premises can drop the door and alarm codes.
3. Change the numbers to match your risk assessment, then check your tools can enforce them. A policy that says 24 hours while the tool allows 30 days is a finding waiting to happen.
4. Get it approved by whoever signs off policies, and tell people it exists. A two-minute mention at a team meeting does more than a link in the handbook.

The policy

1. Scope

This policy applies to everyone who works for [Company], including contractors and temporary staff. It covers every credential used to access company systems or premises: passwords, PINs, API keys and access tokens, private keys and certificates, recovery codes, and Wi-Fi, door, alarm and safe codes.

Listing the kinds of credential matters. People who would never email a password will happily paste an API key into a ticket or text the alarm code, because nobody told them those count.

2. Your own credentials are yours alone

Never share the credentials for your own account with anyone, including your manager and IT. IT will never ask for your password. If someone needs access to something you can reach, ask IT to grant them their own.

This is the line that makes everything else work. If “IT will never ask” is true, a phishing email pretending to be IT becomes easy to spot.

3. Shared accounts by exception

A shared account is used only where a service cannot provide named accounts. Each shared account has a named owner, is listed in the shared account register, and is stored in [password manager].

The register can be a page in your wiki: account, owner, why it can’t be individual, who has access. Auditors ask for exactly this list, and it’s the list you’ll need when someone leaves.

4. Where credentials are kept

Company credentials are stored only in [password manager]. They must not be kept in documents, spreadsheets, notes apps, email drafts, or browser password stores on personal devices. Break-glass credentials are kept sealed in [location], and every opening is recorded.

Cyber Essentials expects you to tell staff where and how they may record passwords, and whether they may use a password manager. This clause is that answer.

5. How credentials are shared

Inside [Company], credentials are shared through [password manager] and nowhere else. With anyone outside it, credentials are sent as a single-use link that opens once and expires within [24 hours], never more than [7 days]. Administrator and production credentials also need a passcode, sent by a different route from the link. Credentials are never sent by email, chat, text message, support ticket or document, and never committed to code or shown in screenshots.

One view and a day are numbers most teams can live with: long enough for a recipient in another time zone, short enough that an unopened link doesn’t linger. If you use ShareShield, organisation policies can enforce the maximum expiry and views and require a passcode, so the send form can’t break this clause. Password sharing for IT teams and MSPs shows that set up for a whole service desk.

6. Who may receive a credential

A credential is shared only with people who need it for their work, with the agreement of the credential’s owner. People outside [Company] receive credentials only when a contract is in place, and their access has an end date set when it is granted.

The end date is the part that gets forgotten. Sharing passwords outside your organisation covers contractors, vendors, auditors and clients, and how to make the end date stick.

7. Asking for credentials

When we need a credential from a client or supplier, we send them a one-time request form; we never ask them to email it. Any request for credentials, from inside or outside [Company], is confirmed through a contact we already know before anything is sent.

The second sentence is your defence against the “urgent, the CEO needs the banking login” email. It costs one phone call.

8. Retention

Credentials that are no longer needed are disabled at source and removed from [password manager]. If a credential is found in email, chat or a ticket, it is changed, and then the message is deleted.

Order matters: change first, delete second. Deleting the message removes one copy; changing the credential makes every copy worthless.

9. When credentials are changed

Credentials are not changed on a fixed schedule. They are changed:

• when someone who knew a shared credential leaves or changes role;
• when an external person’s access ends;
• when there is any reason to think a credential has been exposed;
• at first use, for temporary passwords issued to a person;
• on installation, for default passwords on any device or service.

NIST SP 800-63B advises against forced periodic changes and in favour of changing on evidence of compromise, and the NCSC says the same. Event-driven rotation is both more secure and easier to follow. Cyber Essentials expects default passwords to be changed and compromised ones to be changed promptly, both of which this covers.

10. Reporting a possible exposure

If you think a credential has been exposed, sent to the wrong person or seen by someone who shouldn’t have it, tell [IT contact] straight away. You will not be blamed for reporting it.

The promise in the second sentence has to be true. If people are told off for reporting, they stop, and you find out from the attacker instead. What IT does next is in responding to a leaked password.

11. Exceptions

Exceptions to this policy are approved in writing by [role], recorded with the reason and an end date, and reviewed at least every [six months].

There will be exceptions: a legacy system that only takes a password over email, a supplier who refuses anything else. Recording them with an end date turns a workaround into a decision someone owns.

12. Ownership and review

[Role] owns this policy. It is reviewed every year, and after any incident involving a credential.

A named owner and a review date are the first two things an auditor checks on any policy.

How the clauses map to ISO 27001 and Cyber Essentials

A.5.17 is the control that matters most here. Its title is “Authentication information”, and it asks that allocating and managing authentication information is controlled by a management process, including advising people on how to handle it. The guidance in ISO/IEC 27002:2022 adds the details this policy turns into rules: credentials delivered securely and not by unprotected email, temporary ones changed at first use, default ones changed after installation, and shared ones changed when someone who knew them leaves. If your certificate is still against the 2013 edition, the same ground was covered by A.9.2.4, A.9.3.1 and A.9.4.3.

Cyber Essentials doesn’t ask for a sharing policy by name. Its questions are about accounts and password quality, and a shared login sits awkwardly with “unique credentials for each user”, so expect your assessor to ask about any you keep. Clauses 2, 3, 4 and 9 give you the answers. For which evidence auditors ask for under each framework, see credential sharing and compliance.