Start With the Two Jobs Your Policy Must Do
A good policy only needs to do two things well: protect business accounts and make daily use simple enough that people follow it. If staff in Cape Town, Johannesburg or Durban need to check three places before they can log in, the policy is too hard. Write for the real working day, including remote staff, client portals, cloud tools and the times when load-shedding interrupts normal routines.
Begin by naming what the policy covers. Keep it to company accounts, shared team access, admin logins, approved password storage, access reviews and offboarding. If you run a small team, one page can usually cover the basics. The clearer the scope, the less likely someone is to use a personal note on a phone, a WhatsApp message, or an old spreadsheet sitting on a laptop in the boot of a car.
Set Rules Staff Can Remember
Do not overload the policy with security language. Use plain terms and direct instructions. Staff should know exactly what to do when they create a new login, reset a password or approve access for a new joiner. If a rule cannot be followed in under a minute, rewrite it.
- Use a password manager approved by the business for all work accounts.
- Do not reuse personal passwords for company systems.
- Do not share passwords over chat, message or calls.
- Use unique passwords for every service, especially banking, payroll and admin tools.
- Turn on multi-factor authentication where it is available.
- Lock screens when stepping away from a device, even in the office.
Where possible, explain the reason behind each rule in one short line. For example, say that unique passwords stop one breach from opening everything else. That helps the policy land with staff who are not technical but still need to protect access properly.
Map Access by Role, Not by Guesswork
Small businesses often give too many people too much access because it feels quicker at the time. That becomes a problem when staff change roles or someone leaves suddenly. A simple policy should say that access is based on role, location and responsibility, not on who asks the loudest. A junior staff member in Pretoria should not have the same access as the person signing off invoices in Woodstock.
List the main roles in your business and match each one to the systems they need. Keep the list practical. If a person needs access for invoicing, sales follow-ups or support calls, say so. If they do not need admin rights, say that too. This makes quarterly access reviews much easier and helps during a handover if someone is on leave, resigns or works remotely from another province.
- Owner or director access: full admin rights, banking, security settings.
- Operations access: day to day systems, reporting, approved shared folders.
- Sales or support access: CRM, communication tools, client records within limits.
- Temporary access: time-limited rights for contractors or project work.
Write Clear Steps for Joining, Moving and Leaving
The policy must cover the full staff lifecycle. If you only write about password creation, you will miss the bigger risk, which is old access left active after a person changes jobs or leaves. That is where many breaches start. Make the process short and assign each step to a person or role so nothing gets left to memory.
For onboarding, the policy should say who creates accounts, who approves access and when training happens. For role changes, it should say old access must be removed before new access is added where practical. For offboarding, it should say accounts are disabled on the final working day or sooner if needed, company devices are returned and shared credentials are changed straight after departure.
- Before day one: prepare accounts and confirm the access list.
- On day one: issue login details through the approved secure method.
- During the first week: complete user training and MFA setup.
- When roles change: review access within 2 working days.
- When someone leaves: remove access, recover devices and update shared passwords.
Keep a Simple Standard for Shared Accounts
Shared accounts are common in small teams, but they need careful handling. A policy should say when a shared account is allowed, who may use it and how the password is stored. If everyone knows the same login for one system, that is not enough on its own. You also need a record of who has access, when it was last changed and who approved it.
Use shared access only where a named account is not possible. Even then, limit it to the smallest group needed. In coastal offices where humidity and power interruptions can affect equipment, it also helps to keep critical access information in a central approved system instead of in paper files or unprotected notes. If a password is changed, the policy should require an update within the same working day so teams are not locked out at 4 pm on a Friday.
Review the Policy on a Real Schedule
A policy that never gets reviewed becomes old quickly. Set a simple review cycle and stick to it. For many small businesses, quarterly access reviews are enough, with a fuller policy review once a year or after a major change such as new software, a restructure or a security incident. Keep the review practical and short. It should check whether the rules are still in use, whether staff understand them and whether any extra steps have crept in.
When you review the policy, check for the following:
- New tools added without access rules.
- Former staff or contractors still active on systems.
- Passwords stored outside the approved process.
- MFA not enabled on important accounts.
- Role changes that were never updated in the access list.
If the review finds repeated mistakes, the issue may be training rather than the policy itself. In that case, simplify the wording and retrain the team. A policy only works when people can follow it under normal pressure, not just on a quiet day in the office.
Use This Final Check Before You Sign It Off
Before you publish the policy, read it as if you are a busy staff member in Gauteng, the Western Cape or working from home elsewhere in South Africa. Ask whether the wording is clear, whether the actions are realistic and whether every rule has an owner. A good policy should fit on one or two pages and still cover the basics without confusion.
Final sign-off checklist:
- Does it say who is responsible for account setup and removal?
- Does it cover passwords, MFA, shared access and offboarding?
- Are the rules simple enough for non-technical staff to follow?
- Is there a review date and an approval owner?
- Have managers and team leads been trained on the process?
Once the policy is in place, keep supporting it with setup, training and access reviews. That is where the policy stops being a document and starts becoming daily practice.
