- Who the policy covers
- What staff can use company systems for
- Passwords, logins and access levels
- How the business protects personal information
- Confidential information and intellectual property
- Software, hardware and technology standards
- Monitoring and surveillance
- Data breach response
- Disaster recovery and business continuity
- Enforcement, acknowledgement and review
- Clauses worth adding when the trigger appears
- How an Artificer Legal lawyer would review your IT policy
- What decides whether your policy works
Somewhere in your inbox, or in a folder your IT provider sent over, is a document called something like "IT Policy" or "Acceptable Use Policy". It may be a template you are expected to fill in, a draft your provider wants you to approve, or a policy your business wrote years ago and has not looked at since. Before you sign, tick or file it, it is worth knowing what the document actually does, because a well-drafted IT policy quietly carries a lot of legal weight, and a poorly drafted one can create exposure rather than remove it.
An IT policy is the set of rules that governs how anyone uses your business's computers, networks, data and accounts. It binds employees and, depending on how it is drafted, contractors and other users of your systems. It supplements the employment contract, the privacy policy, confidentiality obligations and work health and safety duties, and it is often the document a regulator or a court will ask about first after an incident. It does not replace those documents; it gives them an operational layer. In some cases the law effectively requires one: in New South Wales, computer surveillance of employees may only be carried out in accordance with a policy the employee has been notified of in advance.
Who the policy covers
What the policy covers is the first drafting decision, and it is easy to get wrong. The policy should say who it applies to (employees, contractors, volunteers, secondees, directors), what systems it covers (company devices, personal devices used for work, cloud accounts, email, the office Wi-Fi) and when it applies (at work, at home, on the road, after hours). Two traps sit here. First, an employee-only policy will not reach the contractor who has access to your customer database; if contractors use your systems, the policy needs to extend to them, or their engagement agreement needs to pick up the same rules. Second, recruitment information is not protected by the employee records exemption in the Privacy Act 1988 (Cth) (the Act), which covers only records about current and former employees held in relation to their employment. Data collected from unsuccessful job applicants is still personal information, so a policy that says nothing about how applicant data is handled leaves a gap.
What staff can use company systems for
Acceptable use is the clause most people picture when they think of an IT policy: what employees may and may not do with company equipment and networks. It matters beyond productivity. An employee who uses a work computer to access inappropriate material can create a hostile workplace environment, and employers now carry a positive duty under s 47C of the Sex Discrimination Act 1984 (Cth) to take reasonable and proportionate measures to eliminate, as far as possible, sexual harassment and other unlawful conduct. A clear, enforced acceptable use clause is one of those measures. The same logic runs through work health and safety law, which requires the business to eliminate or minimise psychosocial risks such as bullying and abuse directed through email and messaging systems.
Drafting minimums for an acceptable use clause:
- Personal use: whether incidental personal use is allowed, usually yes within limits, and what limits apply, such as volume, time and no cost to the business.
- Prohibited content: no accessing, storing or sending material that is unlawful, sexually explicit, harassing, discriminatory or defamatory.
- Personal devices: whether staff may connect personal devices to the network, and what happens to company data on those devices.
- Security conduct: no sharing passwords, no installing unapproved software, no disabling security controls.
The drafting choice that matters most is how the clause describes the standard. Language like "reasonable and proportionate" or "incidental" gives flexibility but needs examples; an exhaustive list reads cleanly but becomes obsolete the moment a new technology appears.
Passwords, logins and access levels
Access control clauses set out how identities, passwords and permissions work: who gets accounts, how strong passwords must be, whether multi-factor authentication is required, how access is approved and revoked, and what happens to access when someone leaves. For businesses that hold personal information and are covered by the Australian Privacy Principles (the APPs), APP 11 already requires reasonable steps to protect personal information from misuse, interference and loss, and from unauthorised access, modification or disclosure, and it expressly counts technical and organisational measures. The access clause is where that obligation becomes concrete.
Practical settings to pin down:
- Password rules: minimum length and complexity, no shared accounts, and resets where needed.
- Multi-factor authentication: required for remote access and for any account that can reach sensitive data.
- Least privilege: staff get access only to what their role needs, reviewed when roles change.
- Offboarding: accounts disabled promptly when employment ends, before the departing employee's last day where possible.
The trap here is access that outlives the person. Ex-employee logins that stay active for months are one of the most common ways breaches happen. The policy should name who owns the offboarding checklist, not just state that access will be revoked.
How the business protects personal information
Data handling clauses describe how the business treats the personal information it collects from customers, clients, staff, suppliers and website visitors. If the business is an APP entity, the APPs apply. APP 1 requires practices, procedures and systems that ensure compliance, plus an up-to-date privacy policy; APP 11 requires the security steps above; and APP 11.2 requires that personal information no longer needed be destroyed or de-identified. The IT policy should say how data is classified (for example public, internal, confidential, highly sensitive), where it may be stored (approved systems only, not personal email accounts or USB drives), who may access it, and how it is transferred, retained and destroyed.
A common misconception is that small businesses are always exempt. Under s 6D of the Act, a small business operator, broadly one with turnover of $3 million or less in the previous financial year, is generally exempt from the APPs, but the exemption falls away in a range of situations: if the business provides health services, trades in personal information, or provides services under a Commonwealth contract, among others. Even where the exemption applies, other laws still govern employee monitoring data and customer information, so the safer drafting position is to apply sensible data protection rules across the business and confirm the position with a lawyer rather than assume the exemption.
Confidential information and intellectual property
An IT policy should state who owns the work product created on company systems and how confidential information is treated. Copyright gives a default answer for employees: under s 35(6) of the Copyright Act 1968 (Cth), the employer owns copyright in literary, dramatic, artistic and musical works an employee makes in the course of employment under a contract of service, subject to any agreement to the contrary. Two gaps follow. Contractor-created material is not covered by that default and needs an assignment in the contractor agreement. And the boundary of "the course of employment" can be murky, so the policy should set expectations about personal projects and side work on company devices.
Confidential information is protected independently by the equitable action for breach of confidence, which does not require a contract, but the policy gives the obligation practical teeth. It should identify what counts as confidential, require marking and careful handling, and remind staff that the obligation survives employment. It should also say what happens to company information on personal devices and in personal cloud accounts when employment ends.
Software, hardware and technology standards
Technology standards clauses set the approved hardware, software, cloud services and communication tools the business supports, and the rules for updates, patching and backups. Standardising reduces risk: fewer tools means fewer attack surfaces, simpler support and easier visibility when something goes wrong. The clause should cover which software may be installed (and that unapproved downloads are not permitted), that updates and security patches are applied, and which communication platforms are approved for work matters. On licensing, the policy should require that only properly licensed software is used, because unlicensed software exposes the business to infringement claims. The drafting choice here is how the list of approved tools is maintained: a schedule the business can update without rewriting the whole policy, with the update process stated in the policy, works better than a fixed list that ages quickly.
Monitoring and surveillance
Many businesses want to know what their staff are doing online, and the policy is the place to say so transparently. The law restricts how this can happen. In New South Wales, the Workplace Surveillance Act 2005 (NSW) requires written notice at least 14 days before surveillance begins, and computer surveillance specifically must be carried out in accordance with a policy the employee has been notified of in advance in a way that makes it reasonable to assume they are aware of and understand it. The same Act restricts blocking emails and internet access unless a notified policy permits it. Other states have their own surveillance legislation with different details, so the monitoring clause needs to be checked against the state or states where the business operates.
The drafting choice is between "we may monitor" and "we monitor". A right to monitor that is never exercised is still a legal right, but an express statement that the business does monitor, or does not, creates expectations employees can rely on. Being candid avoids the worse outcome: covert surveillance that breaches notification requirements. Businesses should also be aware that a statutory tort for serious invasions of privacy has applied in Australia since June 2025, which is another reason to make monitoring settings deliberate rather than improvised.
Data breach response
The incident response clause is where the policy meets hard statutory deadlines. Under Part IIIC of the Act, an APP entity that becomes aware of reasonable grounds to believe there has been an eligible data breach, essentially unauthorised access, disclosure or loss of personal information where a reasonable person would conclude there is a likely risk of serious harm, must prepare a statement and give it to the Information Commissioner as soon as practicable, and notify affected individuals. The Commissioner can also direct notification. For a business that is not an APP entity, those notification obligations do not apply, but a response plan is still how the business limits damage, keeps insurers and clients informed, and protects its reputation.
A practical response clause covers:
- Who decides: the role that confirms whether a breach is eligible and has authority to notify.
- What is recorded: a log of what happened, what data was involved, who was affected and what was done.
- When to notify: statutory timelines where they apply, and the business's own commitment to notify clients or staff.
- Containment: isolating affected systems, changing passwords and preserving evidence before deleting anything.
The trap is a plan that names a person, not a role: when that person is on leave, or has left, the plan stalls. Name roles, and test the plan, because the first time it is used should not be the first time it is read.
Disaster recovery and business continuity
Disaster recovery clauses plan for the events the other clauses cannot prevent: fire, flood, ransomware, a failed server, a provider outage. The essentials are backups (what is backed up, how often, where it is stored and whether it is ever tested), recovery priorities (which systems and data must come back first), recovery responsibilities (who does what), and continuity decisions (whether the business can keep operating, and how). A policy that promises "regular backups" without saying who verifies them is a common failure: the backup that has never been restored is not a backup. The clause should also cover remote access during an incident, communication with staff and clients while systems are down, and the practical point that employee safety comes first in an actual emergency.
Enforcement, acknowledgement and review
The last clause is the one that makes the others real. It should set out the consequences of breach, which will usually be disciplinary action under the employment framework, up to and including dismissal for serious misconduct, how the policy is communicated to new staff, and the requirement that employees acknowledge in writing that they have read and understood it. It should also state who owns the policy and how often it is reviewed.
There is a drafting trap in the interaction between the policy and the employment contract. Policies that are incorporated by reference into a contract of employment can become binding contractual terms, as the Federal Court recognised in Riverwood International Australia Pty Ltd v McCormick [2000] FCA 889. That cuts both ways: it means the policy can be enforced as a contract term, but it also means the business cannot unilaterally change it if the change is detrimental. Keep the policy a policy, say in the contract that it may be varied on reasonable notice, and have changes communicated and acknowledged, rather than letting an updated policy silently overwrite a term of the contract.
Clauses worth adding when the trigger appears
Beyond the core clauses, several additions are worth considering when the situation calls for them:
- Bring your own device: include it if staff use personal phones, laptops or tablets for work, and specify what happens to company data on those devices, including remote wipe.
- Social media: include it if employees post about the business, manage brand accounts or are identifiable as employees online.
- Artificial intelligence tools: include it if staff use generative AI, and set rules about what can be pasted into those tools, since confidential or customer data fed into a public tool is effectively disclosed.
- Offboarding procedures: include it if the business has high staff turnover or staff with administrator access, and specify the device return and account revocation steps.
- Physical security and CCTV: include it if premises are monitored, noting that camera surveillance carries its own notification requirements in NSW.
How an Artificer Legal lawyer would review your IT policy
A practitioner reviewing your IT policy would start by mapping it against the obligations that actually apply to your business: whether the APPs and the notifiable data breach scheme apply, which state's surveillance laws govern your monitoring, what your work health and safety duties require, and how the policy interacts with your employment contracts and contractor agreements. We would check that the monitoring clause is drafted so that what you actually do is lawful and disclosed, that the data breach clause names roles and realistic steps rather than a person, and that the acknowledgement mechanism gives you a record you can rely on in a dispute or a regulator inquiry. We would also test the policy against your privacy policy, confidentiality agreements and any BYOD or AI arrangements, because an IT policy that contradicts those documents creates arguments rather than resolves them. If your policy is a template, we would redraft the clauses that do not fit your operations before you ask staff to sign.
What decides whether your policy works
The difference between an IT policy that protects the business and one that sits in a drawer is not the quality of any single clause. It is whether the policy is current, acknowledged and enforced. The businesses that get into trouble are rarely those with no policy; they are the ones with a policy staff have never seen, that contradicts the privacy policy, or that was written before remote work, cloud systems and AI tools became normal. Enforcement matters legally as well as practically: the employer who quietly tolerates breaches for years cannot suddenly rely on the policy after an incident, and a monitoring clause is only lawful in NSW if staff were actually notified of it. Review the policy when the business changes, when laws change, and at least once a year, and keep the acknowledgements.
In short, a working IT policy covers who is bound, what acceptable use looks like, how access and data are protected, what happens in a breach or disaster, and what the consequences of breach are. Most of those clauses are straightforward; the legal precision is in the details, the state surveillance rules, the privacy obligations, the contract interaction and the review cycle, and that is where a lawyer's review pays for itself.