TL;DR
A password policy written in 2015 and never revisited is probably making your security worse. Routine expiry and forced character mixes both push people toward predictable choices. Length, uniqueness, a manager and a second factor do the real work.
- Current NIST guidance moved away from routine password expiry.
- Length beats composition rules. Allow long passphrases.
- Requiring uniqueness without a manager asks for the impossible.
- Multi-factor belongs in the same document, not a separate one.
- Shared accounts exist. Name them and vault them.
- Screen locks and disk encryption are part of this, not adjacent to it.
When you do not need a long one
Four stages, and the first does not need much writing.
Under about ten people, one system. Everyone uses the same handful of tools and you can see every account. A short written standard is proportionate.
Best tools for HR Operations
Growing past the point of visibility. New tools appear without anybody approving them, and you no longer know every account that exists. Now the policy has a job.
A customer or insurer asks. Somebody wants the document, not a verbal description. This is when most teams write their first real one, and it is also when a template gets adopted without being read.
Regulated or certified. The policy has to be evidenced, reviewed and consistent with practice. Writing a rule you do not follow becomes a liability rather than a gap.
Why most password policy templates are out of date
Two rules dominate older templates: change your password every 90 days, and include an uppercase letter, a number and a symbol. Both were well intentioned and both have been reconsidered.
The reasoning on expiry is straightforward. If somebody must pick a new password four times a year, they pick a variation of the one they already use. The attacker who has last quarter’s password is not far from this quarter’s. Guidance published by the National Institute of Standards and Technology moved away from arbitrary rotation for exactly this reason, favouring change on evidence of compromise.
Composition rules fail the same way. Told to add a symbol, people add an exclamation mark at the end. Told to add a number, they add a one. The space of passwords actually chosen gets smaller rather than larger, which is the opposite of what the rule intends.
The National Cyber Security Centre reaches similar conclusions and goes further on the human side: a policy that makes secure behaviour difficult produces insecure workarounds. That is the test for every clause you write. Not whether it sounds strict, but whether a reasonable person can comply without inventing a shortcut.
The four clauses worth keeping
- Length and uniqueness. A minimum length, a generous maximum, no reuse across systems. This is the core and the rest supports it.
- A manager, provided by you. Name the tool, say it is mandatory for work accounts, and pay for it. Uniqueness is unenforceable otherwise.
- Multi-factor, scoped. List the systems where it is required and the recovery route when a device is lost. Vague coverage means inconsistent coverage.
- Screen lock and encryption. Passcode, full disk encryption, short lock timeout, and a route to report a lost device within hours rather than days.
Four clauses, each short. Everything else people usually add is either an implementation detail that belongs in a runbook, or a rule that works against itself.
Five questions before you rewrite
Can you list every system that holds company data? If not, the policy covers less than you think, and that gap is the real finding.
Do people have a manager today? If not, uniqueness is aspirational and you should fix the tool before the wording.
What happens when somebody loses their second factor? An undocumented recovery route becomes a social engineering route.
Who disables access when somebody leaves? A named role, not a shared assumption.
Are you keeping a rule you believe is wrong because an auditor expects it? That is a defensible choice, but it should be a decision rather than inertia.
Approaches, and the trade-offs
Single sign-on across everything. Best for control and for fast revocation, because one account governs many systems. It struggles on cost, since the tiers that include it are rarely cheap, and on the tools that do not support it.
A shared password manager with no single sign-on. Best for small teams and for coverage of long tail tools. It struggles on revocation, because removing somebody means changing anything they could see.
Per-person managers, no shared vault. Best for simplicity. It struggles badly on handover, since nothing is recoverable when somebody leaves abruptly.
Passkeys where supported. Best on the actual security question, because there is no shared secret to leak. It struggles on coverage, as support is uneven, so it supplements a policy rather than replacing one.
Access tied to the device lifecycle. Disclosure: RemoAsset is owned by the same people who publish this site. It handles procurement, delivery, retrieval and certified wiping across 80 or more countries, which touches this policy at the device clause: encryption and a documented wipe on return are the part a password rule cannot cover. Where it struggles: it is a hardware lifecycle service, not an identity platform, so it will not manage accounts, enforce multi-factor or run single sign-on. The narrow thing it changes is whether a lost or returned device is actually recovered and wiped rather than left in somebody’s drawer with a cached session on it.
The decision table
| Situation | Scale | Setup | Primary pain | Recommended starting point |
|---|---|---|---|---|
| Small team, few tools | Under 10 | No IT owner | Nothing written | One page plus a shared manager |
| Growing, tools appearing | 10 to 50 | Part time owner | No account inventory | List the systems, then write |
| Customer asked for the policy | Any | Any | Template adopted unread | Cut expiry and composition rules |
| Fully remote | 50 plus | One IT owner | Devices out of reach | Device clause plus retrieval route |
| Regulated or certified | 100 plus | Security owner | Policy and practice differ | Evidence what you do, then align |
| Frequent leavers | Any | Any | Access outlives employment | Name the revocation owner |
What a bad policy costs
The first cost is quiet non-compliance. A rule people cannot follow does not produce the behaviour it describes. It produces a reused password with a number on the end, and a policy document that no longer tells you anything true about your own security.
The second is the audit gap. If the written policy says 90 day rotation and your systems do not enforce it, you have documented a control you do not operate. That is worse than documenting a weaker control you do operate, because it misleads whoever reads it, including your own team.
The third sits in the device clause, and it is the one most often missing. Strong credentials do nothing for a laptop that left the company with somebody three months ago and still has active sessions on it. The account question and the hardware question are the same question, and policies that split them leave the gap in between.
So the test is not whether your policy would satisfy a reviewer reading it. It is whether somebody following it exactly would end up more secure than somebody ignoring it.
Where the policy meets the device
Most of this document is about accounts. One clause is about hardware, and it is the one that fails silently.
Three signals say the hardware side is weaker than the wording. You cannot say which laptop is with which person right now. Devices that left in the last year were not all wiped, or nobody can show that they were. And the last time somebody reported a lost machine, the response was improvised.
None of those is fixed by a better paragraph. They need an accurate record and a route that works wherever people are, because encryption plus a documented wipe is what turns a lost device from an incident into a non-event.
Worth checking before the next review cycle, since this is the clause most likely to be true on paper and false in practice. Looking at how device records and certified wiping fit together settles whether the gap is in the policy or underneath it.
See how device records and wiping are evidenced
Read our guide to the information security policy
Related reading
- Writing an information security policy
- The acceptable use policy
- BYOD, and where it breaks
- Evidencing equipment compliance
- Unreturned equipment
Frequently Asked Questions
Should passwords expire every 90 days?
Current guidance from NIST moved away from routine expiry, on the evidence that forced frequent changes push people toward predictable variations of one password. Rotate on evidence of compromise instead. If an auditor still expects an interval, the honest route is to document the reasoning rather than quietly keep a rule you think is wrong.
What length should we require?
Longer beats more complex. A long passphrase is both stronger and easier to remember than a short string stuffed with symbols. Set a minimum length, allow very long passwords, and avoid composition rules that force a specific mix of character types, which mostly produce predictable substitutions.
Do we need a password manager?
If your policy asks for unique passwords everywhere, then yes, because a manager is the only way most people can comply. Requiring uniqueness without providing a manager is asking people to do something they cannot actually do, and the result is reuse with a written note somewhere.
Where does multi-factor fit?
It belongs in the same document, because the two controls only make sense together. A second factor covers what a strong password cannot, which is a password that has already leaked. State which systems require it and what the fallback is when somebody loses their device.
What about shared accounts?
Name them, limit them and record who holds them, because pretending they do not exist does not remove them. Shared credentials for a billing portal or a social account are common. The policy should require they live in a managed vault with named holders rather than in a message thread.
Does the policy cover devices as well?
It should cover the device lock screen, because a strong account password protects nothing on an open laptop left on a train. Require a device passcode, full disk encryption and a short automatic lock timeout, and say how a device is reported lost.
How do we handle somebody leaving?
Revocation belongs in the offboarding process, not only in the password policy, and the two should point at each other. The policy says access ends on the last working day, and the process names who disables what. Without both, accounts stay live because nobody owned the task.
