A useful password policy can fit in a few pages, but it must answer practical questions: which access rights matter most, who may use them, where are secrets stored, and how quickly can access be removed?
This guide offers a starting point to adapt to your business, contracts, and risk assessment. It is not a substitute for an audit or legal advice.
1. Start with access that can stop the business
Do not begin by asking everyone to memorise new rules. First list the accounts that can reach:
- email and account-recovery tools;
- accounting, banking, and payroll;
- hosting, DNS, backups, and administration tools;
- customer data, HR records, and business applications;
- supplier or provider accounts that can act on behalf of the company.
For each access, record the owner, authorised users, privilege level, available second factor, and expected maximum revocation time.
2. Write short, usable rules
An SMB policy can start with these rules:
- One service, one unique password. Reuse creates a domino effect when one account is compromised.
- Use a passphrase or randomly generated secret that is long enough and unrelated to the person.
- Turn on MFA whenever it is available, prioritising email, administrator accounts, remote access, and sensitive data.
- Never send a password by email, instant message, or an unapproved shared document.
- Separate administrator accounts from everyday accounts.
- Replace or disable an exposed secret, orphaned account, or access with no current owner immediately.
- Keep recovery codes and emergency access in a protected location, with an owner and backup owner.
The minimum length can vary by service and additional controls. A uniform rule that pushes users toward predictable variations is less useful than a risk-based policy built around uniqueness, MFA, and secure storage.
3. Assign responsibility
The document should say who decides and who acts:
- Management approves the policy, accepts exceptions, and provides the necessary resources.
- Security lead or provider maintains the inventory, helps configure protections, and organises reviews.
- Service owner approves users, privilege levels, and the next review date.
- User reports loss, accidental sharing, or suspected compromise immediately.
Add onboarding, role-change, and offboarding procedures. Specify who starts the request, who approves it, which access is removed, and what evidence is kept.
4. Apply the policy every day
An encrypted local vault such as Soclyde can turn these rules into habits: generate unique secrets, keep them on the organisation’s devices, and share them only with authorised people. This avoids spreadsheets, sticky notes, and copy-pasting into unsuitable channels.
The vault does not configure external accounts by itself. After creating a secret, check MFA in the relevant service, review the granted permissions, and confirm the recovery method. Soclyde does not replace endpoint management, patching, backups, or monitoring.
5. Manage exceptions without creating a back door
An exception may be necessary for legacy equipment, a service account, or a provider. Keep it temporary and documented:
- reason and accepted risk;
- owner and authorised users;
- compensating measures, such as network restrictions or time-limited access;
- expiry date and review owner.
Avoid a permanent exception because “the tool cannot do better”. If the risk cannot be reduced, escalate it to management for an explicit decision.
6. Check with simple evidence
Every quarter, or more often for critical access, review:
- the account and owner list;
- administrator rights and shared accounts;
- MFA activation;
- inactive accounts and former employees’ access;
- last rotation date for high-risk secrets;
- whether the vault and recovery codes can be restored;
- the result of a revocation test.
Keep the date, scope, reviewer, gaps, and corrective actions. Short, regular evidence is more useful than a one-off review nobody can reproduce.
Sample policy to adapt
Business access is named whenever the service allows it. Each service uses a unique secret stored in the company-approved vault. MFA is required for email, administrator accounts, remote access, and every service that offers it for sensitive data. An access request is approved by the service owner. Rights are removed after offboarding or a role change and reviewed at least quarterly. Any suspected compromise is reported immediately; the affected secret is revoked or replaced without waiting for the next review. Exceptions are documented, time-limited, and approved by management.
A 30-day implementation checklist
- [ ] Name the management owner and operational security contact.
- [ ] Inventory services, critical accounts, owners, and providers.
- [ ] Remove orphaned accounts and separate administrator use.
- [ ] Enable MFA for email, administration, and remote access.
- [ ] Replace reused secrets or secrets stored in unprotected files.
- [ ] Define onboarding, role-change, and offboarding procedures.
- [ ] Document exceptions with an expiry date.
- [ ] Test one revocation, one recovery, and one unavailability scenario.
- [ ] Schedule the first quarterly review and keep its evidence.
A policy succeeds when people understand it, apply it, and review it. Measure less by the number of written rules than by the number of critical accesses with an owner, MFA where possible, a unique secret, and a tested revocation path.
