Most small businesses know they should “do something” about cyber security. Fewer have actually written down what that something is. The gap between knowing and documenting is where most of the risk sits, because without a written policy, security becomes whatever each person happens to remember on a given day.
We work with small and medium businesses across Western Australia on everything from websites to infrastructure, and the pattern is familiar: a business owner has good instincts about security but nothing formalised, so when a new staff member joins or a supplier asks about data handling, there’s nothing concrete to point to. A cyber security policy fixes that. It doesn’t need to be a fifty-page compliance document. It needs to be clear, realistic, and something your team actually reads.
Here’s how to build one that holds up.
Start With What You’re Actually Protecting
Before writing any rules, take stock of what exists. This sounds obvious, but most businesses have never mapped it out properly.
A useful exercise is to walk through a normal week and list every system that touches customer data, money, or business operations. Email, accounting software, website admin, social media accounts, cloud storage, point-of-sale systems, and any third-party tools that staff log into.
For each one, ask a simple question: if this were compromised tomorrow, what would it cost us? Some answers will be obvious (the accounting platform holds banking details), and others less so (a forgotten social media account from 2019 that still has admin access to the website).
This inventory becomes the backbone of the policy. Everything else builds on it.
Set Rules for Passwords and Access That People Will Actually Follow
This is where most policies go wrong. A rule that’s technically secure but practically unworkable gets ignored within a week, and an ignored policy is worse than no policy because it creates a false sense of coverage.
A workable access policy usually includes:
Multi-factor authentication on email, banking, and any system holding customer data, non-negotiable, even for small teams
A password manager so staff aren’t reusing the same login across ten platforms
Role-based access, meaning people only get logins to systems relevant to their job
A clear process for removing access immediately when someone leaves
That last point matters more than businesses expect. Old accounts with active access are one of the quietest ways a business stays exposed long after someone has moved on.
Decide How Data Is Stored, Backed Up, and Disposed Of
Data policies tend to get treated as an IT afterthought, but they’re really a business continuity question. If your customer database, invoicing records, or project files disappeared tomorrow, what would happen?
A few things are worth nailing down in writing:
Where customer and business data lives, and who has access to it. Cloud storage with proper permission controls is generally more resilient than scattered local files on individual laptops.
How often backups run, and just as importantly, whether anyone has actually tested restoring from one. A backup that’s never been tested is a hope, not a plan.
How old data gets disposed of. Holding onto customer records indefinitely “just in case” increases what’s at risk if a breach happens, without adding much value.
None of this needs to be elaborate. Cloud platforms with built-in security controls and monitoring, run by providers who handle the infrastructure side properly, take a lot of this off a small business’s plate by default. The policy just needs to state what’s in place and who’s responsible for checking it.
Build a Simple Incident Response Plan
Every policy needs a section covering “what happens when something goes wrong,” because eventually, something will. The goal isn’t to prevent every possible incident. It’s to make sure that when one happens, the response is fast and clear rather than chaotic.
A workable incident response section answers a few questions in plain language:
Who is the first point of contact if a staff member suspects a breach, a strange email, or a compromised account?
What systems get isolated or shut down first, and who has authority to make that call?
How and when are affected customers notified, if at all?
Is there an external IT or security contact who can be brought in quickly?
This is also the section that connects most directly to day-to-day vigilance. A staff member who can recognise a suspicious email is often the difference between an incident contained in minutes and one that spreads across the network overnight. The policy should make it explicit that reporting a suspicious email is encouraged, not something staff feel embarrassed about doing.
Cover the Website and Digital Infrastructure Separately
A business’s website and hosting environment often get left out of internal security policies entirely, treated as something “the web team handles.” But a compromised website can affect customer trust, search rankings, and in some cases become an entry point into other systems if logins are shared or reused.
The policy should specify who manages updates to the website’s content management system, plugins, and themes, and how often. It should also note where the site is hosted, whether that hosting includes security monitoring, and who to contact if something looks wrong, a defaced page, unexpected redirects, or a sudden spike in traffic from unfamiliar sources.
Ongoing monitoring and support for these systems isn’t a luxury add-on anymore. Continuous oversight that catches unusual activity early is generally far less disruptive, and far cheaper, than discovering a problem after it’s already affected customers. A line in the policy stating that infrastructure is actively monitored, and by whom, closes a gap that catches a surprising number of businesses out.
Make It a Living Document, Not a Filing Cabinet Entry
A policy written once and never revisited becomes outdated within a year. New tools get adopted, staff change, and threats evolve, particularly given how quickly automated scanning and social engineering tactics shift.
Set a recurring review, even just twice a year, to walk through the policy and check it still reflects reality. Does the staff list match who actually has system access? Are the backup processes still the ones in use? Has a new tool been adopted that isn’t covered yet?
It’s also worth pairing the policy with short, regular reminders for staff. A five-minute refresher on spotting a suspicious email does more for day-to-day security than the policy document itself, because most breaches still start with someone clicking something they shouldn’t have. A policy that exists alongside that kind of awareness is far more durable than one that sits alone in a shared drive.
Putting It Into Practice
A cyber security policy doesn’t need to be perfect on the first draft. It needs to exist, be specific enough to act on, and be revisited often enough to stay relevant. Start with the inventory, build out access and data rules around it, add a clear incident response section, and don’t forget the website sits inside the policy too, not outside it.
As a digital agency that builds and manages websites, infrastructure, and security for small businesses across Australia, we’ve seen how much smoother things run once a policy like this exists, not because it prevents every incident, but because everyone knows what to do when something happens. If writing this from scratch feels daunting, starting with the asset inventory alone is often enough to reveal where the real gaps sit, and from there the rest of the policy tends to take shape on its own.
