A Small-Business Password Policy: Template and Rollout Checklist

A useful password policy answers everyday questions: where employees keep passwords, who turns on multi-factor authentication (MFA), how someone recovers an account and what happens when a colleague leaves. A length setting alone cannot answer those questions.

Use this guide to draft a short policy with the password policy generator, then add the decisions that depend on your company. The example below is a starting point for review. Check any contractual or sector-specific requirements before adopting it.

1. List the accounts and the people responsible

Start with email, payroll, banking, cloud storage, remote access and administrator accounts. Record which system controls sign-in for each service. A Windows setting does not automatically change the rules in every cloud application.

• Policy owner: approves the document, exceptions and review date.
• IT owner: configures controls, tests recovery and keeps deployment records.
• Employees and contractors: follow the policy and report unexpected sign-in prompts or suspected exposure.

For example, a 12-person design studio might use one identity provider for email and storage, separate banking accounts and a local Windows domain. Its checklist needs an owner and verification step for each of those systems.

2. Choose a reference and document your decisions

NIST SP 800-63B-4, section 3.1.1.2 requires at least 15 characters for password-only authentication, or eight when the password is always part of MFA. It recommends permitting at least 64 characters. It requires screening new passwords against common or compromised values and prohibits composition rules and scheduled password changes; a change is required when compromise is evident.

Our NIST password guidelines guide explains the distinction between requirements and recommendations. Select the reference appropriate to your environment, then record how your actual services support it. The generator's comparison covers selected settings; it is not a complete compliance assessment.

3. Adapt this short policy example

The clauses below are an example of company decisions. Replace the bracketed fields and confirm that every named control can actually be enforced. Keeping a single 15-character baseline can simplify communication across accounts with different sign-in methods.

Password and account access policy — [Company]
Owner: [role and contact]. Applies to: [employees, contractors and systems]. Effective date: [date]. Next review: [date].

1. Use an individual account for work. Keep administrator accounts separate from everyday accounts.
2. Use a unique password for each service and store it in the company-approved password manager. Do not send passwords through email or team chat.
3. Our baseline is a minimum of 15 characters. IT records services that cannot support this baseline and the approved exception.
4. Enable MFA on work accounts where supported. IT records the method, enrollment owner and any remaining gaps.
5. Do not share recovery codes. Keep them in the approved recovery location. Contact [verified support route] if you lose access.
6. Report suspected exposure or an unexpected MFA request to [contact]. IT investigates, resets affected credentials and revokes sessions where needed.
7. When someone leaves or changes roles, [owner] reviews access and removes permissions that are no longer needed.
8. Exceptions require [approver], a reason, compensating controls and a review date. Review this policy after a material incident or system change.

Add a short IT implementation appendix covering the chosen authentication controls, password screening, failed-attempt protections and recovery procedures. Keep passwords and recovery codes out of the policy document itself.

4. Generate the document and inspect each export

1. Open the policy generator, select a reference preset and enter the organization name.
2. Adjust the settings to match your approved decisions. Review the Policy tab, then download the Markdown document (.md).
3. Add the named owners, support contacts, service inventory, exceptions and approval date to your copy.
4. If relevant, select the Windows, Active Directory or Linux tab and download that script separately. The Windows and AD files use .ps1; the Linux file uses .sh.

Selecting MFA or a blocklist in the document does not deploy those services. Read the generated comments and check which settings the chosen script implements. MFA enrollment, cloud application settings and password screening may need separate configuration.

5. Test Windows and Active Directory changes on a pilot

For AD, Microsoft's fine-grained password policy documentation explains how policies apply to users and global security groups, and how to inspect a user's resultant policy. Creating a policy object is only part of deployment: verify that the intended accounts receive it.

A banned-password control is a separate implementation question. Microsoft Entra Password Protection, for example, adds global and custom banned-password checks to an on-premises AD environment when its required components are deployed. Do not assume a fine-grained policy alone provides this check.

• Read the script, record current settings and prepare a rollback route before running it with administrative rights.
• Use a test machine or pilot group. Check a new password, a rejected password and account recovery.
• Verify the effective settings for a pilot account. Confirm the separate MFA and password-screening controls where applicable.
• Check legacy applications and service accounts before extending the change to more users.

6. Roll out with evidence your team can use

Send employees a short explanation with the effective date, password manager instructions and a verified support contact. Test recovery with the people who will handle it. Record which services have been configured, who checked them and what remains open.

A completed rollout has an approved document, working controls, a tested recovery route and a dated exception list. Review that evidence when services or staff roles change. For individual secrets, use the random password generator or a random passphrase; for visitors, prepare a separate Wi-Fi guest card.