What a password policy is for
A password policy is a short written set of rules telling everyone in the organization how sign-ins are expected to work. Its purpose is to reduce the chance that a stolen or guessed password gives an attacker access to business systems. A policy that people understand and can follow will protect you more than a strict one they work around, such as by writing passwords on sticky notes or adding a “1” to the old one each time.
Treat the policy as general good practice rather than a guarantee. Even strong sign-in rules cannot stop every attack, but they close off some of the easiest routes.
Start with length and uniqueness
Current guidance from many standards bodies has moved away from forcing complicated character mixes. Long passwords are generally harder to guess and easier to remember than short, complicated ones. A reasonable policy therefore:
- asks for passwords or passphrases of a decent length (many organizations choose at least twelve to sixteen characters, though the right number depends on your systems);
- requires a different password for every account, because password reuse lets one leaked password open many doors;
- bans obviously weak choices, such as the company name, the word “password”, keyboard patterns and anything that has appeared in a known leak, where your systems can check this;
- encourages memorable passphrases built from several unrelated words.
Avoid rules that are hard to follow, such as demanding special characters in a particular position. They tend to produce predictable patterns.
Be careful with forced changes
Many older policies forced everyone to change passwords every 60 or 90 days. Frequent forced changes often lead people to choose slight variations on the same password. Many current recommendations favor changing a password when there is a reason, such as a suspected compromise, a breach notification involving that service, or a departing staff member who knew a shared credential. Whatever you decide, state it plainly in the policy.
Make multi-factor sign-in the centerpiece
A password alone is a single point of failure. Requiring a second step adds a layer that stolen passwords cannot defeat by themselves. Your policy should say where two-factor authentication is mandatory. A sensible order of priority is:
- email accounts, since they are often used to reset other passwords;
- banking and payment systems;
- administrator accounts and cloud services;
- any system holding customer or staff data.
Not all second factors are equal. Codes sent by text message are better than nothing, but app-based codes or hardware keys are generally considered more resistant to certain attacks. Newer options such as passkey login can remove the password from the process altogether where they are supported. State which methods are acceptable and what staff should do if they lose the device that holds their second factor.
Provide a password manager
It is unrealistic to ask people to memorize dozens of unique, long passwords. A password manager stores them securely and fills them in, so the policy becomes much easier to follow. If you provide one, say so in the policy and explain how to set a strong master passphrase. Explain also that the manager should be protected with multi-factor sign-in.
Shared accounts and administrators
Shared logins make it hard to know who did what and are awkward to secure when someone leaves. Where possible, give each person their own account. If a shared credential is unavoidable, such as for a single social media profile, store it in the manager, limit who can see it, and change it when team members leave. Keep administrator accounts separate from day-to-day accounts, and grant the minimum access each role needs.
Tie the policy to your staff offboarding routine so that access is removed promptly when someone departs.
Recovery and lockouts
Include what happens when someone forgets a password or loses a device. Recovery routes are an attractive target for attackers, so the policy should require identity checks before resetting access, and warn staff not to share codes with anyone, even someone claiming to be IT support. Setting up account recovery options carefully is part of the same discipline.
Writing the policy itself
Keep it to a page or two in plain language. A useful structure is:
- Purpose and scope: who and which systems it covers.
- Password rules: length, uniqueness, banned choices.
- Multi-factor requirements: where it is required and which methods are allowed.
- Tools: the approved password manager and how to use it.
- Shared and admin accounts: rules and exceptions.
- Reporting: whom to tell if a password may be exposed or a prompt seems wrong.
- Review date: when the policy will be revisited.
Train people and review regularly
A policy nobody has read protects nothing. Walk new and existing staff through it in a short session, show them how to set up the manager and second factor, and explain the reasons behind each rule. People follow rules more readily when they understand them. This fits naturally with broader security awareness training. Finally, review the policy at least yearly, as guidance and tools change, and check that the rules still match how your team works. Where exceptions are needed, record them rather than allowing them to creep in unnoticed.