AI and cyber security
The biggest AI security risk for a small business is sitting in a browser tab
The AI security conversation usually starts with attackers. For a typical Australian small business the more immediate exposure is a trusted employee, doing their job properly, moving information into a service nobody assessed.
None of your existing controls sees it happen. Endpoint protection does not object to a browser. Backup does not help. The information has already left.
General information about Australian obligations, not legal advice.
What is the biggest AI security risk for a small business?
Legitimate staff putting business information into AI services the organisation has not assessed, on accounts it does not control. The ASD's Australian Cyber Security Centre lists data leaks and privacy breaches first among AI risks for small business, ahead of unreliable output and supply chain dependency.
The ACSC records an Australian case from early 2025 in which a contractor uploaded names, contact details and health records of people involved in a government programme into an AI system. It was treated as a notifiable data breach. No attacker was involved.
That guidance, Artificial intelligence for small business, was published on 14 January 2026 by the ACSC with New Zealand's National Cyber Security Centre and the Council of Small Business Organisations Australia. It is short, free and specifically written for businesses without a security team. If you read one government document on this, read that one.
Source: Artificial intelligence for small business (ASD's ACSC, NCSC-NZ and COSBOA, 14 January 2026).
Where the exposure actually comes from
Not a threat list. These are the things that turn out to be true when a business looks properly, and each one is fixable with a decision rather than a purchase.
Uploads, not prompts
A typed question exposes a paragraph. An uploaded document exposes everything in it, including the parts nobody read. File upload is where the volume is, and it is the least noticed.
Retention and training settings
Whether inputs are retained, and whether they are used to improve models, depends on the product, the tier and the settings. The ACSC's advice is to review the configuration, terms and privacy policy of any AI platform you engage with. Almost nobody does.
Meeting transcription
A note-taker in a client meeting captures a conversation involving people who never agreed to it, then stores and processes it somewhere the business has not assessed. It usually arrives without any procurement decision at all.
Personal subscriptions used for work
Outside your identity system, outside your MFA policy, outside offboarding. When that person leaves, the chat history containing your client information leaves with them, on an account you cannot reach.
Weak account security
AI accounts hold a searchable archive of everything anyone has ever pasted in. They deserve the same MFA and access discipline as your email, and they rarely get it because nobody thinks of them as a data store.
Nothing happens at offboarding
Your leaver checklist covers email, the file share and the CRM. It almost never covers the AI account, the browser extension, the transcription tool or the integration that person authorised.
Extensions and integrations
A browser extension that summarises pages can read those pages. An assistant connected to your mailbox can read the mailbox. The permission was granted once, by one person, and never reviewed.
Authorisations nobody tracks
Sign-in with your work account grants a third party standing access under your identity. Reviewing what has been authorised in your tenant is a short exercise that regularly produces surprises.
Secrets pasted for debugging
API keys, connection strings and credentials go into AI tools during troubleshooting more often than anyone admits. Treat any secret that has been pasted anywhere as needing rotation.
Confident technical advice that is wrong
Configuration guidance that sounds authoritative and weakens a control. The failure is silent, because the change appears to work.
Generated code with vulnerabilities
The OAIC notes that programs produced by coding assistants often carry security vulnerabilities and that the assistants themselves can be attacked. Generated code needs the same review as any other code.
Prompt injection
Instructions hidden in content the AI reads, designed to make it do something it should not. A tool that can read your email and act on it is a tool that can be instructed by whoever emails you.
And yes, attackers use it too
Generative tools have removed the tells that used to make phishing obvious: the odd phrasing, the wrong idiom, the mistimed reference. Pretexts are better researched and better written, and voice cloning makes an urgent call from a known voice a reasonable thing to plan for.
The defence has not changed. Verify payment and account changes through a channel you already had, not one supplied in the message. What has changed is that "it looked wrong" is no longer a reliable filter, so the process has to carry the weight instead of the instinct. Threat identification and reporting.
The ACSC's AI cyber security checklist for small business
Nine statements. The value is in noticing which ones you cannot honestly tick, and each of them is a question about your organisation rather than your technology.
- I understand the benefits and risks of integrating AI into my business.
- I know what business information can be safely shared with the AI tool.
- I have verified what data the AI tool collects and where it is stored.
- I know who owns the data: my business or the AI vendor.
- I have confirmed whether my business's data will be used to train AI models.
- I know where and how to fact-check the AI system's outputs.
- I have provided AI security-related training and advice to my staff.
- I have verified that the AI vendor is committed to security, for example by using a recognised cyber security compliance framework.
- I know the process for handling a cyber security incident related to the AI application or tool.
Reproduced from the ACSC's Artificial intelligence for small business, 14 January 2026. Note what the list is made of: eight of the nine are about knowing, deciding and telling people. One is about the vendor.
Questions worth asking before you approve an AI provider
Most of these are answerable from published documentation in under half an hour. The point is not the difficulty. It is that somebody does it before the tool is in use, and writes down what they found.
-
What information will the service receive?
Prompts, uploaded files, connected mailboxes and document stores, meeting audio. Be specific, because the answer for the same product differs depending on which features are switched on.
-
Where is it processed and stored?
Including whether that is outside Australia. Data residency commitments often differ by region, and some providers publish that non-EU traffic may be processed in several jurisdictions.
-
How long is it retained, and can we control that?
Retention behaviour, whether an administrator can set or shorten it, and whether users can delete their own history.
-
Is our data used to train or improve models?
The answer commonly differs between the consumer product and the business tier, and sometimes depends on a setting. Get it from the provider's own current documentation and record where you found it.
-
Which subprocessors receive it?
Model providers, hosting, analytics, search. A published subprocessor list is a good sign in itself. Silence here is worth weighing.
-
What protects the account and the data?
Multi-factor authentication, single sign-on, role-based access, encryption, and whether the provider holds a recognised certification such as ISO 27001.
-
What can administrators actually control?
Whether you can turn off training use, restrict features, manage retention, see who has access and remove someone. A product with no admin surface is a product you cannot govern.
-
What happens when the account is terminated?
What is deleted, when, and whether you can export first. This is the question that matters most and is asked least.
-
How will incidents be reported to us?
The ACSC's advice is to understand the vendor's incident notification process and response mechanisms before you need them. If they have a breach, you may have a notification obligation, and you cannot assess what you are not told about.
Asking the questions is not the same as due diligence
The OAIC is direct about this: due diligence for AI products should not be a set-and-forget exercise, and reviews of the product's performance, staff training and monitoring should continue across its lifecycle. A questionnaire answered once and filed is a snapshot of a service that changes. Give it a review date and an owner, in the same register as your other suppliers.
Most of the fix is extending controls you already run
This does not need a new security programme. It needs the programme you have to acknowledge that AI services exist.
| Control you already have | What it needs to cover now |
|---|---|
| Multi-factor authentication | Every AI account used for work, including any approved personal-tier account, because that account holds an archive of your information. |
| Joiner, mover, leaver process | AI accounts, browser extensions, transcription tools and authorised integrations at every stage, not just email and the file share. |
| Access review | Which third-party applications have standing access to your tenant under someone's identity, and whether that is still wanted. |
| Supplier and vendor register | AI providers listed as what they are: third parties receiving your information, with an owner and a review date. |
| Incident response | An explicit path for data going somewhere it should not have, and an assessment against the notifiable data breach criteria when it does. |
| Security awareness training | The AI-specific things people get wrong, which are not the same as the phishing content they already sit through. |
| Acceptable use policy | Named services and named information categories, in the document staff have already acknowledged. |
| Change and procurement | An AI feature switched on inside existing software is a change to your data handling, even though nobody bought anything. |
Wrong output becomes your problem, not the model's
Because the consequence lands on the business that acted on it. The ACSC cites a 2025 case in which a lawyer used AI to prepare a court document, the tool generated false cases, the lawyer did not verify them before filing, and after the court discovered it the lawyer was barred from operating and owning a law practice.
The ACSC's advice on this is plain: train staff to verify outputs, keep a human in the decision-making process for high-stakes or sensitive operations, use trusted and regularly updated models, watch for unusual behaviour, and review AI-integrated processes regularly.
For a small business the workable version is a rule about where verification is mandatory rather than encouraged. Anything going to a client, a court, a regulator or an insurer. Anything contributing to a decision about a person. Anything changing a system configuration. Anything being published. In each case a named person read it and can stand behind it.
What this looks like on a well-run business
A thirty-person professional services firm with a good IT provider
MFA is enforced, endpoints are managed, backups are tested, patching runs on a cycle and the tenant is configured properly. By any technical measure this business is above average for its size.
What the controls cover
- Identity and access across the tenant
- Endpoint protection and device management
- Backup with restore testing
- Patching and unsupported system tracking
What they do not reach
- Two personal AI subscriptions used daily for client work
- A transcription tool one team started using in March
- A browser extension with read access to everything on screen
- An integration authorised last year that nobody has reviewed
- No record of which client material has gone into any of them
If this firm has an incident, the technical work will hold up well. The question it will struggle with is the scope one: what information had been placed outside our systems, and where. That answer does not come from a security tool. It comes from having decided which services are approved and having written it down. Six of the ACSC's nine checklist items are things this firm cannot currently tick, and none of them are technical.
The technical half has a home. The other half usually does not.
Your IT provider or internal team runs the controls. What tends to have no owner is the record: which services were approved, on what basis, who assessed them, who was trained, what happened when something went wrong, and when any of it was last reviewed.
Providers, with the answers attached
The vendor register records data types received, purpose, sensitive and health information flags, storage country, offshore disclosure, subprocessor visibility, contract status, an owner and a review date. The supplier questions above have somewhere to land.
Incidents assessed, not just noticed
An incident register with assignment and status, and a structured notifiable data breach assessment for the cases where information went somewhere it should not have.
Control checks with dates
Recurring verification tasks against controls such as multi-factor authentication and the joiner, mover, leaver process, where a passed check writes dated evidence and a failed one raises a gap with an owner.
Cleverer does not scan networks, monitor AI traffic or connect to client systems. It is the compliance record around the controls, not a security tool. How the evidence system works.
Start with the list you do not have
If you cannot name the AI services your business uses, that is the first job, and it takes about a week of replies to one email. The Readiness Check covers the rest of the position around it.
Questions about AI and security
Is putting company data into an AI tool a data breach?
Not automatically. It is a disclosure to the provider, and whether that is a breach depends on what the information was, whether the disclosure was authorised, and whether it is likely to result in serious harm. Where personal information is involved and the use was not authorised, it should be assessed against the notifiable data breach criteria. The ACSC records an Australian case where exactly this was treated as a notifiable breach.
Does using a paid business tier make it safe?
It removes a specific and important risk, which is the provider using your inputs to train models. Microsoft states that prompts, responses and data accessed through Microsoft Graph are not used to train foundation models for Microsoft Copilot. That is a real commitment and worth having. It does not tell you which staff may use it, what they may put in, where processing occurs, or whether the output was checked, and those are the remaining risks.
Should we block AI tools on the network?
Blocking has a role, particularly for services you have specifically refused. As a whole strategy it fails, because staff move to phones and personal accounts and you lose visibility as well as control. The stronger position is a small number of approved, assessed services that people can actually use, plus rules about what goes into them.
What should we do if someone has already put client data into an AI tool?
Find out what, when, into which service and on which account. Check whether the provider retains it and whether it can be deleted. Assess whether it is an eligible data breach if personal information was involved. Record what you found and what you decided. Then fix the reason it happened, which is usually that nobody had said what was allowed.
Do AI accounts need multi-factor authentication?
Yes. An AI account accumulates a searchable archive of everything anyone has pasted into it, which makes it a data store even though it does not look like one. It should carry the same authentication and offboarding discipline as your email.
How do we handle AI features appearing in software we already use?
Treat it as a change to your data handling, because it is one, even though nothing was purchased. Someone should decide whether it stays on, on what basis, and whether it changes what the vendor receives. Reviewing default settings after a vendor update is worth adding to whatever review cycle you already run.
