Information Security Policies Your Business Needs
Most Australian businesses of 10 to 100 people need eight information security policies: information security, acceptable use, access control, patch and vulnerability management, backup and recovery, incident response and breach notification, supplier security, and a privacy policy covering personal information. Every other policy you see on a list of fifteen or twenty is usually a section inside one of those eight. Each needs an owner, a version number and a review date, because those three things are what an auditor checks first.
This guide sets out what each policy covers, which framework asks for it, who signs it, and how to keep the set current without an annual scramble.
Which information security policies does a business actually need?
A business needs the policies that its obligations, its customers and its own risks actually call for, which for most Australian SMBs comes to eight documents. Adding more does not make the business safer. It makes each one less likely to be read, reviewed or followed.
- Information security policy. The top level statement: what the business is protecting, who owns security, and what everyone is expected to do.
- Acceptable use. What staff may and may not do with company devices, accounts, data and AI tools.
- Access control. How accounts are created, how privileged access is granted and removed, and how often access is reviewed.
- Patch and vulnerability management. What gets patched, how quickly, and what happens when a patch cannot be applied.
- Backup and recovery. What is backed up, how often, where copies live, and how restores are tested.
- Incident response and breach notification. Who is called, who decides, and the steps for assessing whether a breach is notifiable.
- Supplier and third party security. How you assess suppliers before signing and what you check afterwards.
- Privacy policy. How the business handles personal information, written for the public rather than for staff.
A common mistake is writing a separate policy for every topic an auditor might mention. Remote work, mobile devices, passwords, encryption and clear desk are all sections that belong inside acceptable use or access control. They do not need covers of their own. The incident response policy is the one exception worth keeping standalone, because people need to find it in a hurry. Our post on why an incident response plan matters covers what belongs in it.
Which policies are required by ISO 27001, the Essential Eight and the Privacy Act?
ISO 27001 names the most policies, SOC 2 expects much the same set expressed as controls, the Essential Eight focuses on technical mitigations rather than documents, and the Privacy Act requires exactly one policy by name. Knowing which obligation drives which document stops you writing for an auditor who was never going to ask.
The Privacy Act obligation is the clearest of the four. Australian Privacy Principle 1 requires an APP entity to have a clearly expressed and up to date privacy policy, and APP 11 requires reasonable steps to protect personal information. Both are set out in the OAIC quick reference to the Australian Privacy Principles. Whether the Act applies to your business depends on turnover and the kind of information you handle, and those rules have been under active reform, so check your current position against OAIC guidance rather than a blog post.
The Essential Eight is different in kind. It is a set of eight technical mitigation strategies, not a documentation standard, but the maturity model expects the processes behind patching, application control, administrative privileges and backups to be repeatable rather than ad hoc, which in practice means written down. See the ASD Essential 8 requirements for what each strategy asks for.
ISO 27001 is the most explicit. Annex A names acceptable use (A.5.10), access control (A.5.15), supplier security (A.5.19 to A.5.22) and secure development (A.8.25), and clause 5.2 requires the top level information security policy itself. Our guide to Annex A without checkbox compliance covers the difference between naming a control and operating one.
What should an information security policy include?
An information security policy should include six things: a scope, an owner, the rules themselves, the consequences of breaking them, the review date and the version. Anything longer than about four pages tends to be read once and never again.
| Element | What good looks like | What fails an audit |
|---|---|---|
| Scope | Names who and what it applies to, including contractors | Silent on contractors and personal devices |
| Owner | A named role, such as the Operations Manager | Signed by the business generally |
| Rules | Specific and testable, with numbers where relevant | Aspirational language such as appropriate measures |
| Consequences | States what happens after a breach of the policy | Nothing, so the policy is unenforceable |
| Approval | Dated approval by management | No approval evidence at all |
| Review | A date within the last twelve months | A review date that has passed |
Testability is the difference between a policy that changes behaviour and one that decorates an intranet. Critical patches applied within 48 hours is testable. The organisation will apply patches promptly is not, and an auditor cannot sample against it.
What is the difference between a policy, a standard and a procedure?
A policy states what the business has decided and why. A standard states the specific setting or threshold that must be met. A procedure states the steps someone follows to meet it. Keeping the three separate is what allows you to change a password length without reapproving a board level document.
| Document type | Answers | Example | Changes |
|---|---|---|---|
| Policy | What and why | Access to systems is granted on least privilege | Rarely, with management approval |
| Standard | What specifically | Administrator accounts require phishing resistant MFA | When technology changes |
| Procedure | How, step by step | How to onboard a new starter in the identity platform | Often, by the team that owns it |
| Record | Did it happen | The completed onboarding ticket | Never. Records are evidence |
Who writes and who signs the information security policy?
Someone inside the business writes the policy, usually with help, and a member of senior management signs it. In a small Australian business that is typically the managing director or the head of operations. The signature is not a formality: ISO 27001 clause 5.2 requires the policy to be established by top management, and auditors check who approved it.
Policies written entirely by an outside consultant and never adapted are easy to spot and hard to defend. They describe a business that does not exist, reference tools you do not use, and fail at the first evidence request. The workable model is an adviser supplying structure and a draft, and the business rewriting the parts that describe how it actually works.
Responsibility for keeping the set current usually sits with whoever owns security day to day. Where there is no such person, a virtual CISO arrangement is a common way for Australian SMBs to get the ownership without the headcount.
How often should information security policies be reviewed?
Review every policy at least once a year, and immediately after any event that makes it wrong. Record the review even when nothing changes. A policy with no changes, a current review date and a named owner passes an audit. A well written policy last reviewed three years ago does not.
- Annually at minimum. Spread the set across the year rather than reviewing all eight in one week.
- After an incident. Incidents almost always reveal a step the incident response policy did not cover.
- After a technology change. A new identity provider, a move to a different cloud platform, or the adoption of AI tools all date the acceptable use and access control policies immediately.
- After a headcount or structure change. Policies that name roles need updating when the roles change.
- Before an audit or a customer review. Check dates and approvals first, because that is what gets checked first.
Acceptable use is the policy most likely to be out of date right now, because generative AI tools arrived faster than most policy cycles. If yours does not say what staff may paste into an AI assistant, it is describing a business from a few years ago. Pair the update with a refresh of your security awareness training, since a policy nobody has been told about changes nothing.
Common questions
What should an information security policy include?
Scope, a named owner, the rules themselves, the consequences of breaching them, evidence of management approval and a review date. Rules should be specific enough to test, such as a stated patching timeframe, rather than aspirational wording. Four pages is usually enough for a small business.
How many information security policies should a small business have?
Around eight for a business of 10 to 100 people. Information security, acceptable use, access control, patch and vulnerability management, backup and recovery, incident response, supplier security, and a privacy policy. Most published lists of fifteen or twenty policies are describing sections that can live inside those eight.
Who writes security policies?
Someone within the business, usually with outside help for structure and wording. The content has to describe how your business actually operates, so a policy written entirely externally and never adapted tends to fail at the first request for evidence. Senior management approves and signs the final version.
How often should information security policies be reviewed?
At least annually, plus immediately after an incident, a significant technology change or a change in structure. The review must be recorded even when nothing changes, because the evidence an auditor looks for is the dated review, not the edit history.
What is the difference between an information security policy and a privacy policy?
An information security policy is internal and tells staff how to protect company and customer information. A privacy policy is external and tells the public how the business collects, uses, stores and discloses personal information. Australian Privacy Principle 1 requires the privacy policy. The information security policy is driven by frameworks and customers rather than by the Privacy Act.
Why is an information security policy important?
It is the document that turns intentions into an obligation staff can be held to, and it is the first thing a customer, insurer or auditor asks for. Without it, security decisions are made case by case, inconsistently, and there is nothing to point to when someone asks why an exception was allowed.
Getting your policy set in order
If you already have a folder of policies, the useful first step is not writing more. It is checking whether each one has an owner, a version, an approval date and a review date inside the last twelve months, then deleting the ones that duplicate another.
If certification is the destination, the policy set is only part of the job. Our guide to ISO 27001 for small business in Australia covers how the documentation fits into the wider management system.
Siege Cyber helps Australian businesses build a policy set that matches how they actually work and stands up in an audit or a customer security review. Learn more about our virtual CISO and advisory services or get in touch for a look at what you have now.