Password Policy Example: The Rules a Small Business Can Adopt

A good password policy example fits on one page, and it holds seven plain rules. The National Institute of Standards and Technology’s authentication guideline asks for long passwords. It also says systems shouldn’t force a mix of character types, and shouldn’t make users reset on a schedule. A small business can borrow those rules as a benchmark.

Without rules in writing, staff may keep choosing short passwords that only satisfy a symbol requirement, and an owner can’t tell an insurer, a customer or a new IT provider what the company’s rule is. So the task is straightforward. Adopt the seven lines below, then ask your IT provider which of them your systems can enforce.

What Does a Good Password Policy Example Look Like?

A one-page document is enough. Seven short lines can cover it, and they don’t need legal language. Each line follows something NIST’s authentication guideline says about passwords, and each one is short enough for your IT provider to hold against a single system and answer yes or no. The lines below are written as policy statements.

• A password used on its own is at least fifteen characters long.
• Where a second sign-in step is also required, a password may be shorter, but never under eight characters.
• Passwords of up to at least sixty-four characters are accepted, spaces included, so staff can use a phrase.
• Nobody is required to mix character types.
• Nobody is forced to change a password on a schedule, but a password is changed at once when there’s evidence it has been compromised.
• A new password is checked against a list of known weak and breached passwords, and it’s rejected if it’s on the list.
• Staff may use a password manager and paste passwords into sign-in boxes.

Treat those lines as a starting point you can adapt. They aren’t a finished policy for every office, and the wording can change to match how your business talks. What matters is that each one points at something your IT provider can check on a real system.

How Long Should a Business Password Be?

NIST’s authentication guideline says a password used on its own, with no second sign-in step behind it, should be at least fifteen characters long. That’s the number to write into your policy. It is a length rule, plain and simple. A short password with a symbol dropped into it can still be easy to guess.

That figure comes from NIST’s authentication guideline, which is written for government digital systems. It isn’t a rule or a legal duty for a private business, and following it doesn’t make a company secure or compliant. Treat it as a benchmark you can borrow. Then ask your IT provider which of these rules your own systems can enforce.

There’s one exception in the guideline. Where a second sign-in step is also required, a password may be shorter, but never under eight characters. If that second step is unfamiliar in your office, a companion post explains how a second sign-in step works.

At the other end, the guideline says the system that checks the password should accept at least sixty-four characters, and that users should be able to include spaces so they can use phrases. That’s room for a real sentence. A phrase of several ordinary words can be easier to remember than a short jumble of symbols, and it clears fifteen characters without much effort.

Do Staff Still Need Symbols and Scheduled Changes?

NIST’s authentication guideline says the system that checks the password should not impose rules about which characters a password must contain, such as requiring a mix of character types. It also says users shouldn’t be required to change passwords on a schedule. Two familiar office habits drop out of the policy: the symbol requirement and the calendar reset.

The guideline keeps one kind of change. If there’s evidence that a password has been compromised, it says the system should force a change. That belongs in your policy, with a name beside it. Who in your company would call the IT provider if someone suspected a password had been compromised?

Ask your IT provider what each system forces. Some systems may still carry old defaults that demand a symbol or expire a password on a cycle, and those settings can sometimes be switched off. Ask whether yours can. If a system can’t be changed, write down what it does allow, and leave the rest of the policy as written.

How Do You Keep Weak and Reused Passwords Out?

NIST’s authentication guideline says the system that checks the password should compare each proposed password against a list of known weak or compromised passwords, and refuse it if it’s on the list. The check runs when a password is set or changed, before anyone relies on it. That can keep known weak ones out without anyone policing it.

The guideline gives examples of what such a list can hold: passwords taken from earlier breaches, dictionary words, and words tied to the service or the user’s own name. Some systems may not be able to run that check. It’s worth asking your IT provider whether yours can, and what a user sees when a password is refused.

The guideline also says the system that checks the password should allow password managers and autofill. Your policy can say the same in one line. If you’re weighing whether to adopt a manager at all, a separate post covers what a business password manager does.

Pasting matters as well. The guideline says systems should permit pasting into a password box, which helps a manager work. Staff may assume that pasting a password breaks the rules. Your policy can say plainly that it doesn’t.

Who Should Own the Policy?

As a general rule, one named person on the business side can own the one-page policy. That person doesn’t have to be technical. The job is to hold the document and to ask the IT provider to confirm in writing which of the seven rules each system can enforce. A policy nobody owns can quietly go stale.

O&O Systems’ Cybersecurity and Compliance page says its team helps draft and maintain IT security policies.

Four questions are enough to take to your provider.

• Which of the seven rules can each system enforce?
• Which systems still force a mix of character types or a scheduled change, and can that be switched off?
• Does each system check a new password against a list of known weak ones?
• Who gets told if a password may have been compromised?

Keep the written answers with the policy. When an insurer or a customer asks what your password rule is, you’ll have one page and a short record of what each system can hold to. The same pair helps when you bring in a different IT provider.

Frequently Asked Questions About a Password Policy Example

Does NIST’s authentication guideline apply to a private business?

It’s written for government digital systems, so it isn’t a rule or a legal duty for a private business. A company can still borrow it as a benchmark, which is what the seven lines do. What your own systems can enforce is a separate question, and your IT provider is the one who can answer it system by system.

Is fifteen characters too long for staff to remember?

It doesn’t have to be. The guideline asks for fifteen where a password stands alone, and it also says users should be able to include spaces so they can use a phrase. Four ordinary words with spaces between them can clear fifteen characters easily, and a phrase may be easier to recall than a short jumble of symbols. A password manager, if your office uses one, removes the question altogether.

What if our systems still force symbols or monthly changes?

The guideline says systems should not require either one. Older settings can linger, though. Ask your IT provider whether those settings can be switched off on each system, and what the system allows if they can’t. Write the answer beside the rule it affects, so the gap is visible when someone asks what your rule is.

Does a password policy replace a second sign-in step?

No. The policy covers passwords, and that’s all it covers. The guideline’s shorter minimum of eight characters applies only where a second sign-in step is also required, so the two are tied together. Ask your IT provider about both: which password rules each system can enforce, and whether a second step is available on the systems your staff sign into.

When should we review the policy?

As a general rule, two moments are worth a look: when a system is added or replaced, and when your IT provider changes. Both can change what your systems enforce. The guideline speaks to password rules rather than review calendars, so the timing is a business call. A short check at those two points can be enough, and it doesn’t need to be a formal review.

Put the Seven Rules in Writing

Write the seven lines down. Name one person to keep them. Then keep your IT provider’s written answers beside the page, so the rule and what each system can enforce sit together. As general advice, that’s the whole job: a page, an owner and a short record of what’s enforceable.

If you want a password policy example turned into rules for your own office, contact O&O Systems about your password policy and start with the systems your staff sign into every day.