How to write a password policy for your small business

Most small businesses do not have a password policy. They have a mix of habits, some good and some terrible, that vary by person. One employee runs everything through a password manager and uses a different login for every account. The next writes passwords on a sticky note and reuses the same one across the payroll portal and their personal email. Nobody agreed on any of this. It just accumulated. A password policy replaces that accumulation with a written baseline that everyone is expected to meet, that new hires acknowledge on day one, and that you can actually point to when something goes wrong.

This article is the template. It walks through what a small business password policy should cover, gives you the modern version of each rule (including the ones that have changed, because forced monthly rotation is no longer best practice), and ends with a sample policy you can copy, adjust, and put in front of your team this week. It is written for the person who has been handed the job of writing this document, which at a 20-to-50 person business is usually the owner, the office manager, or the one internally-designated technical person, not a dedicated security team.

A password policy is not a standalone project. It is one section of your broader cybersecurity policy, and it only works if it is backed by tooling. A policy that says “use unique passwords everywhere” without giving people a business password manager to do it is a policy that asks employees to do something no human can do by memory. Write the policy and provide the tool. One without the other fails.

Short answer

A password policy is a one-to-two page document that sets your minimum requirements for how business passwords are created, stored, protected, and retired. It should mandate a password manager, require MFA on every account that supports it, set a minimum length (aim for a passphrase of 15 or more characters, not a short complex string), ban reuse and sharing, and drop scheduled rotation in favor of rotate-on-compromise, which is what NIST now recommends. The fastest workable version fits on one page, is signed by every employee, and is enforced through your password manager and identity provider rather than the honor system. The two most common mistakes are writing rules the tooling does not actually enforce, and keeping outdated rules like forced 90-day rotation and mandatory special characters that push people toward weaker, more predictable passwords.

Password policy at a glance

Question	Short version
How long should it be?	One to two pages. If people will not read it, it will not be followed.
Who signs it?	Every employee, at onboarding and after any major revision.
Minimum password length?	15 or more characters. Favor passphrases over short complex strings.
Complexity rules?	Length beats forced special characters. Do not require them; do screen against known-weak passwords.
Scheduled rotation?	No. NIST recommends against it. Rotate on evidence of compromise, not on a calendar.
MFA?	Required on every account that supports it. Non-negotiable for email, finance, and admin.
Password manager?	Required. The policy is not enforceable by memory alone.
Browser-saved passwords?	Not allowed for business accounts. Use the password manager instead.
Shared passwords?	Eliminate where possible; where unavoidable, share through the password manager, never by chat or email.
What if someone violates it?	Defined consequences, tiered by intent and impact, communicated in advance.
How is it enforced?	Through the password manager, identity provider, and MFA settings, not the honor system.

What a password policy actually does

A password policy does four jobs. If your draft does not do all four, it is incomplete.

It sets the baseline. It states the minimum everyone must meet, so security no longer depends on each person’s individual judgment. Without it, your weakest employee’s habits are your actual security posture.

It creates accountability. You cannot hold someone responsible for a rule that was never written down or communicated. If a shared login leads to a breach, your response is very different depending on whether you had a signed policy prohibiting credential sharing or an unspoken assumption that people would know better.

It makes the tooling requirement official. “Use the password manager” carries more weight as a written, signed requirement than as a suggestion someone made in a meeting once. The policy is what turns the password manager from an optional convenience into an expectation.

It gives outside parties something to point to. Cyber insurers, client vendor questionnaires, and compliance frameworks increasingly ask whether you have documented password requirements. A one-page policy answers that question. Not having one is often what stalls an insurance application or a client security review.

The rules that have changed

Before writing the policy, it helps to know which of the “classic” password rules are now considered actively harmful. Several rules that most of us grew up with have been reversed by current guidance, most notably NIST Special Publication 800-63B, the digital identity guidelines that most modern frameworks now follow.

Forced periodic rotation is out. For years the rule was “change every password every 90 days.” NIST now recommends against scheduled rotation for user-chosen passwords. The reason is behavioral. When you force people to change a strong password on a calendar, they do not invent a brand-new strong one. They increment the old one, so Summer2024! becomes Summer2025!, or they write it down because they can no longer remember it. Rotation should be triggered by evidence: a known breach, a suspected compromise, or an employee departure, not by a date. Rotate on compromise, not on a calendar.

Composition rules are out. The old “must contain an uppercase letter, a lowercase letter, a number, and a special character” rule produces predictable passwords, because humans satisfy it in predictable ways (P@ssw0rd1 technically passes). NIST now advises against mandating specific character types. What actually helps is length and screening against known-compromised passwords, which any decent password manager or identity provider can do.

Length is the real lever. A 20-character passphrase of ordinary words is dramatically harder to crack than an 8-character string of symbols, and far easier to remember or, better, to generate and store in a manager. Set a floor of 15 or more characters and let the password manager generate long random strings for accounts nobody has to type by hand.

Password hints and knowledge-based questions are out. “What was your first pet’s name” is answerable from social media. Do not use security questions as a recovery mechanism where you can avoid it, and never require them in your own systems.

Building the policy around current guidance instead of 2010-era rules is the single biggest quality difference between a policy that improves security and one that quietly makes it worse.

What the policy should cover

Here are the sections a small business password policy needs. Keep each one to a few sentences. This is a policy, not a manual.

Scope

State who and what the policy applies to: all employees, contractors, and anyone with access to business systems, and all business accounts and credentials. Make clear it covers personal devices used for work, not just company-owned machines.

Password manager requirement

State plainly that all business passwords must be stored in the company-provided password manager, and that storing business passwords in browsers, spreadsheets, documents, notebooks, or personal password managers is prohibited. This is the load-bearing rule. Almost every other rule in the policy depends on people actually using the manager, so name it first and name it clearly. If you have not chosen one yet, how to choose a password manager covers the selection, and how to deploy a password manager across your business covers the rollout.

Password strength

Set a minimum length of 15 or more characters for anything a human types, and require the password manager to generate long random passwords for everything else. Do not mandate specific character types. Prohibit reuse of any password across two or more accounts, and prohibit reuse of personal passwords for business accounts. State that passwords must be screened against known-compromised password lists, which the password manager or identity provider handles automatically.

Multi-factor authentication

Require MFA on every account that supports it, with no exceptions for email, financial systems, or any administrative account. Specify acceptable methods and rank them: authenticator apps and hardware security keys are preferred, SMS codes are a last resort because they are the weakest common method. State that MFA recovery codes must be stored in the password manager, not printed and left in a drawer. For the full reasoning on why passwords and MFA are both required and neither is sufficient alone, see MFA and passwords: how they work together and why MFA is not enough on its own.

No sharing, and how to share when you must

State that sharing individual login credentials is prohibited. Then acknowledge reality: some accounts genuinely need to be used by more than one person. For those, require that the credential be shared through the password manager’s shared-vault feature, where people can use the login without seeing the password, and never through chat, email, or a document. The full treatment of this is in the problem with shared passwords and how to fix it; the policy just needs the one-line rule and the pointer to the approved method.

Browser-saved passwords

Prohibit saving business passwords in browser password managers. Browser storage has no admin visibility, syncs to personal accounts by default, and is a well-known target for malware that scrapes saved credentials. Require that browser password saving be turned off for business use and that existing browser-saved passwords be migrated into the company password manager.

Rotation and offboarding

State the rotation rule in modern terms: passwords are rotated when there is evidence of compromise, a suspected breach, or a departure, not on a fixed schedule. Then connect it to offboarding: when an employee leaves, their access is revoked and any shared credentials they had access to are rotated. This is where the policy meets your leavers process; what happens to your passwords when an employee leaves covers the full offboarding-from-a-credential-angle, and the policy should reference your offboarding checklist rather than repeat it.

Reporting

Require that any suspected credential compromise, phishing attempt that captured a password, or lost device with saved credentials be reported to IT immediately, with no fear of punishment for honest reporting. The person who reports clicking a phishing link an hour ago is doing you a favor. The person who hides it because they are afraid of getting in trouble is handing the attacker more time.

Consequences

State the consequences of violating the policy, tiered by intent and impact. An honest mistake that gets reported is handled differently from repeated, deliberate circumvention. Publishing the ladder in advance is what makes enforcement fair and defensible. A policy with no stated consequences is a suggestion.

Ownership and review

Name who owns the policy and state that it is reviewed at least annually and after any significant incident or change in tooling. Include a version and date so people can tell whether they are looking at the current one.

Sample password policy you can adapt

Below is a working draft. It is deliberately short. Replace the bracketed placeholders, adjust anything that does not fit your environment, and have every employee sign it. This is roughly the real length of a workable small business password policy. If yours is much longer, it is probably drifting into manual territory and people will stop reading it.

[Company name] password policy
Version 1.0  |  Effective [date]  |  Owner: [name or role]

1. Purpose
This policy sets the minimum requirements for creating, storing, and
protecting passwords used to access [Company name] systems and data. It
exists to reduce the risk of account compromise, which remains the most
common cause of business security incidents.

2. Scope
This policy applies to all employees, contractors, and anyone with access
to [Company name] systems, and to all business accounts and credentials,
including those accessed from personal devices.

3. Password manager
All business passwords must be stored in [Company password manager].
Storing business passwords in web browsers, spreadsheets, documents,
notebooks, personal password managers, or shared notes is not permitted.

4. Password strength
- Passwords you type must be at least 15 characters. A passphrase of
  several unrelated words is preferred over a short complex string.
- The password manager must generate long random passwords for all other
  accounts.
- Passwords must be unique. No password may be reused across accounts, and
  personal passwords must not be used for business accounts.
- Passwords are screened against known-compromised password lists.

5. Multi-factor authentication (MFA)
- MFA must be enabled on every account that supports it.
- Email, financial systems, and administrative accounts require MFA with
  no exceptions.
- Authenticator apps or hardware security keys are required where
  available. SMS codes are used only where nothing else is supported.
- MFA recovery codes are stored in the password manager.

6. Sharing credentials
- Sharing individual login credentials is not permitted.
- Where an account must be used by more than one person, the credential is
  shared through [Company password manager]'s shared vault, never by chat,
  email, or document.

7. Browser-saved passwords
- Saving business passwords in a web browser is not permitted.
- Browser password saving must be disabled for business use, and any
  existing browser-saved business passwords migrated to the password
  manager.

8. Rotation and departures
- Passwords are rotated on evidence of compromise, a suspected breach, or
  an employee departure. Scheduled calendar-based rotation is not used.
- When someone leaves, their access is revoked and any shared credentials
  they could access are rotated, per the offboarding checklist.

9. Reporting
Any suspected password compromise, phishing attempt that captured a
password, or lost device with saved credentials must be reported to
[IT contact] immediately. Honest and prompt reporting will not be
penalized.

10. Consequences
Violations are addressed based on intent and impact, ranging from
retraining for honest mistakes to disciplinary action for repeated or
deliberate circumvention.

11. Review
This policy is owned by [name or role] and reviewed at least annually and
after any significant incident or change in tooling.

Acknowledgement
I have read and understood the [Company name] password policy and agree to
follow it.

Name: ______________________   Signature: ______________________
Date: ______________________

How to communicate and enforce it

A signed policy that nobody follows is worse than no policy, because it creates a false sense of coverage. Two things make a password policy stick.

Communicate it once, clearly, and tie it to the tool. Do not email the PDF and hope. Walk through it in a single short meeting, at the same time you roll out or reinforce the password manager, so the policy and the means to follow it arrive together. Lead with what is now easier (one login to remember, autofill everywhere, no more resetting forgotten passwords) rather than with the list of prohibitions.

Enforce it through settings, not reminders. The rules that can be enforced technically should be. Minimum length, MFA requirement, and compromised-password screening can be configured in the password manager and your identity provider so they are simply true, rather than requested. Browser password saving can be disabled through group policy or your device management tool. Every rule you can move from “please do this” to “the system does this” is a rule you no longer have to police. The honor system is the fallback for what you genuinely cannot configure, not the primary mechanism.

How it connects to your broader policy

The password policy is one member of a small family of related documents. It sits inside your cybersecurity policy, which references it rather than duplicating it. It depends on the password manager decisions in how to choose and how to deploy one. It hands off to your offboarding process for what happens when an employee leaves, and it overlaps with your MFA stance from MFA and passwords. Write it so it points to those documents instead of re-litigating them. A policy that tries to contain everything becomes the 40-page document nobody reads.

Common password policy mistakes

1. Keeping forced 90-day rotation. It pushes people toward predictable, incremented passwords and is no longer recommended. Rotate on compromise instead.
2. Mandating special characters. It produces P@ssw0rd1 and a false sense of strength. Require length, not composition.
3. Writing rules the tooling does not enforce. If the policy says “unique passwords everywhere” but people have no password manager, you have asked for the impossible.
4. Making it too long. A 20-page password policy is a password manual, and it will not be read. Keep it to one or two pages.
5. Skipping the sign-off. Without a signature, you cannot show the rule was communicated, which is the whole point of a written policy.
6. Banning sharing without providing an approved way to share. People will share anyway, just insecurely. Give them the shared-vault method.
7. Ignoring browser-saved passwords. They are the quiet exception that undermines the whole policy, and they need an explicit rule.
8. Requiring security questions. “Mother’s maiden name” is public information. Do not build recovery around it.
9. No stated consequences. A policy with no consequences is a suggestion, and it will be treated as one.
10. Writing it once and never revisiting it. Tooling and threats change. An unreviewed policy slowly stops describing reality.

How long it takes to write

For a 20-to-50 person business, expect this to be a week of light effort, not a project.

Phase	What happens	Rough time
Draft	Adapt the sample above to your environment and tooling	1 to 2 hours
Review	Owner or IT contact checks it against how you actually work	1 hour
Configure enforcement	Set length, MFA, and screening in the password manager and identity provider	2 to 4 hours
Communicate	One short all-hands or team meeting alongside the password manager	30 minutes
Collect sign-off	Every employee reads and signs	Ongoing over a few days
Schedule review	Put the annual review on the calendar	5 minutes

The writing is the fast part. The enforcement configuration and the sign-off collection are where the real value is, because a policy that is technically enforced and formally acknowledged is a policy that changes behavior.

What is next in this series

With a policy written and enforced, the natural next step is to check the passwords you already have against it. A later article in this series covers how to audit your business passwords and find the weak, reused, and exposed ones so you can bring your real environment up to the standard the policy sets.

How Sequentur can help

If you want help writing a password policy that fits your business, or configuring your password manager and identity provider so the policy actually enforces itself, schedule a call.