How to Write a Password Policy — Flassword guide

How to Write a Password Policy for Your Business

By the Flassword Team · ⏱️ Reading time: 7 min · 🟡 Intermediate · Last updated July 13, 2026

Most organizational password policies were written years ago, copied from a template that was outdated even then, and never revisited. Meanwhile, the actual public guidance on what makes a good policy has changed substantially. Here's a practical framework for writing — or rewriting — one that reflects current thinking rather than habits from a decade ago.

Why a written policy matters

Without an explicit standard, password practices default to whatever each employee individually decides is good enough, which in practice means enormous variation — some strong, most not. A written policy replaces that inconsistency with a clear, defensible baseline everyone in the organization is working from, and it gives IT and security teams something concrete to enforce, audit against, and point to during a compliance review.

It also matters for a less obvious reason: a policy communicates what the organization actually expects. Employees who've never been told otherwise often assume an eight-character password with a capital letter and a number is "secure," because that's what every login form since 2005 has trained them to believe. A policy is the mechanism that updates that assumption organization-wide, rather than hoping individual employees stumble onto better habits on their own.

What NIST changed, and why

The U.S. National Institute of Standards and Technology publishes some of the most widely referenced public password guidance, and its current recommendations (SP 800-63B) look noticeably different from what most people still assume is "best practice":

  • Length now matters more than complexity. A long passphrase is treated as stronger than a short, symbol-heavy password — see our length vs. complexity guide for the math behind why.
  • Forced periodic rotation is discouraged for accounts without evidence of compromise, since it tends to produce predictable variations rather than genuinely new passwords.
  • Arbitrary composition rules are discouraged — mandatory symbols and forced capitalization patterns push people toward predictable substitutions that cracking tools already account for.
  • Screening against known-breached passwords is recommended, checking new passwords against exposed-password lists rather than just enforcing character rules.

This is a meaningful shift from policies written even five or six years ago, and it's worth explicitly updating older documents rather than assuming they're still aligned with current thinking.

Core policy components

Component Modern recommendation
Minimum length At least 8 characters, ideally 12 or more encouraged
Composition rules Optional rather than mandatory; length matters more
Rotation On evidence of compromise, not a fixed calendar schedule
Breach screening Reject passwords found on known-exposed lists
Lockout Temporary lock after a defined number of failed attempts
MFA Required, especially for privileged and remote-access accounts

Our Password Policy Generator turns this exact table into a ready-to-edit document, with presets that lean toward NIST-style, PCI DSS-style, or HIPAA-style defaults depending on your starting point.

Common mistakes in real policies

A few patterns show up constantly in policies that look thorough on paper but fail in practice, often because they were written to look rigorous during an audit rather than to actually change day-to-day behavior:

  • Rules so strict employees write them down. A policy that's technically secure but practically unusable pushes people toward sticky notes and shared spreadsheets — see our guide on common password mistakes for how this backfires.
  • No mention of a password manager. A policy that demands unique, complex passwords across dozens of systems without providing a tool to manage them is setting employees up to fail quietly.
  • MFA treated as optional. A strong password policy without mandatory multi-factor authentication is missing the single highest-leverage control available — our 2FA guide covers why.
  • Never revisited. Guidance changes; a policy frozen in 2015 is actively recommending practices that current research argues against.

Rolling out a policy people actually follow

A policy only works if people follow it, and adoption depends heavily on how it's introduced. Pair the written rules with the tools that make compliance easy — provide a company password manager rather than assuming employees will find their own, and make MFA enrollment part of onboarding rather than an optional afterthought. Explain the "why" briefly rather than issuing rules with no context; people follow security guidance more consistently when they understand the reasoning behind it, not just the requirement.

Give employees a grace period to migrate existing passwords rather than forcing an overnight cutover, and make sure whoever handles IT support is prepared for a temporary spike in password-reset requests right after rollout — that spike is normal, not a sign the policy is failing.

Tip: Roll out the policy alongside a company-wide password manager rollout, not before it. Asking employees to meet a new, stricter standard with no tool to help them do it easily is the single most common reason password policies fail to stick.

Frequently asked questions

Do small businesses really need a formal password policy?

Yes, even a short one. Without any written standard, password habits default to whatever each employee happens to do individually, which usually means weak, reused, and undocumented passwords protecting shared business systems. A one-page policy is far better than none.

Should our policy still force password changes every 90 days?

Current NIST guidance recommends against mandatory periodic rotation for this exact reason: it tends to produce small, predictable variations of the same password rather than genuinely new ones. Rotate on evidence of compromise instead, and let a long, unique password stand as long as it hasn't been exposed.

Is a password policy alone enough to secure our accounts?

No — a policy sets the rules, but adoption is what actually protects anything. Pair the policy with a company-wide password manager and mandatory multi-factor authentication, and treat the written policy as the framework those tools operationalize, not a standalone control.

How often should we review and update our password policy?

Once a year at minimum, and immediately after any relevant security incident. Guidance from bodies like NIST does shift over time, as it did significantly around composition rules and forced rotation, so a policy written five years ago may already be recommending outdated practices.

What's the fastest way to draft a first version of our policy?

Start from a preset rather than a blank page. Our Password Policy Generator produces a complete, editable draft aligned with common NIST, PCI DSS, or HIPAA-style practice in under a minute, which you can then adjust to your organization's specific needs.

Conclusion

A good password policy is short enough to actually read, current with modern guidance rather than a decade-old template, and paired with tools that make following it genuinely easy — a password manager and mandatory MFA, not just a page of rules. Start from a solid draft, adjust it to your organization's real constraints, and put a date on the calendar to revisit it within the year.

Related articles

Free tools for this guide