This is not a story about carelessness. It happens in well-run organisations because software is now easy to adopt and hard to see. A worker does not need budget approval or IT involvement to sign up to a web app with a credit card or a free tier, and the tool works well enough that nobody questions it again. The result is what security people call shadow IT: systems running inside your organisation that sit outside the visibility and control of whoever is meant to be responsible for your data. This article sets out a practical way to catch new tools before they become part of that pile, and a lightweight way to review the ones you already depend on.
Shadow IT rarely arrives as one bad decision. It accumulates through a series of individually reasonable ones. A support coordinator is frustrated with a clunky process and finds a slicker app that solves their specific problem. A team lead trials three options to compare features and only remembers to cancel one of them. A finance person signs up to an invoicing add-on to handle an edge case the main system does not cover. Each choice is made by someone trying to do their job better, usually without any intention of creating risk.
The problem is what happens next: nothing. There is often no step where someone asks what data the tool touches, where it is hosted, or who else has access to it. The tool just keeps running, sometimes for years, quietly holding participant notes, rosters, contact details or financial information, invisible to whoever is meant to be managing your organisation's data footprint. When an incident review or an audit eventually asks "what systems hold participant data," the honest answer is often "we are not entirely sure."
The fix is not to ban new tools. Frontline staff finding better ways to work is a good thing, and locking that down too hard just pushes the behaviour underground. The fix is a lightweight gate: before a tool that will touch participant, staff or financial data goes into regular use, someone runs it through a short set of checks.
You do not need a formal procurement department to do this well. You need a habit and a short list of questions that get asked every time, before a tool becomes part of how your team works day to day.
| Question to ask | Why it matters |
|---|---|
| Where is our data hosted, and in which country? | Affects which privacy laws apply, how quickly you can retrieve data, and whether the arrangement fits your funding body's expectations |
| Does the tool support SSO and multi-factor authentication? | Without it, you are relying on individual passwords, which is a weak and hard-to-audit form of access control |
| Can we set role-based access, or does everyone see everything? | A tool where every user sees all records widens your exposure well beyond what any single person actually needs |
| What happens to our data if we cancel? | Determines whether you can retrieve records in a usable format, and whether old data is actually deleted or just abandoned on someone's servers |
| Does the vendor publish a security page or trust centre? | A vendor with nothing public to say about security has usually not thought about it much either |
| Have they had any public security incidents? | Past incidents are not automatically disqualifying, but how they were handled and disclosed tells you a lot |
| Will it connect to our other systems via an integration or API? | Every connection is a new path into your data, and needs its own access review, not just a one-off approval |
| Will they sign a data processing agreement or similar terms? | Sets out obligations in writing rather than relying on a sales conversation or a marketing page |
Ask this question of every new tool, not just the obvious ones. A scheduling app or a forms tool can feel too small to matter, but if it stores participant names, addresses, support needs or incident details, it is holding the same category of information as your core system.
Offshore hosting is not an automatic dealbreaker. Plenty of reputable software is hosted overseas, and for some tools the risk is genuinely low. The point is to know the answer and weigh it deliberately, rather than never asking and finding out only when it becomes a problem.
A tool's data protections are only as strong as its access controls. Ask whether the vendor supports single sign-on (SSO) so accounts can be centrally managed and removed the moment someone leaves, and whether multi-factor authentication is available, ideally required, on every account. Ask whether you can set role-based access so a rostering coordinator does not automatically see clinical notes, and a casual worker does not see the full participant list. If the answer to any of these is "everyone just shares one login" or "there's only one level of access for all users," treat that as a real limitation, not a minor inconvenience.
One shared login, set up years ago, still used by half the team, with nobody sure who originally created it or what happens if that password leaks. This is one of the most common findings when providers finally audit their software list, and it is entirely preventable by asking about access control before a tool is adopted, not after.
Exit terms rarely get attention during a sales conversation, because nobody is thinking about leaving before they have even started. But they matter enormously once you actually need them, whether because the vendor's pricing changes, the product stops meeting your needs, or the company itself is acquired or shuts down. Before committing, understand:
A vendor that cannot give you clear answers to these questions before you sign up is unlikely to make them easier after you have handed over live participant data.
A useful shortcut is to judge a vendor the way you would judge any organisation handling sensitive information: by whether they appear to take their own security seriously. A dedicated security or trust page, clear statements about encryption and access controls, and support for MFA are all reasonable baseline signals. Their absence does not automatically mean the vendor is unsafe, but it does mean you are trusting them on faith rather than evidence.
Past incidents deserve a similar, measured read. A vendor that has never had a public incident may simply be small enough that nobody has looked hard, while a vendor that has had one and handled it with clear, timely disclosure and a documented fix may be a more mature choice than it first appears. What should concern you is not the existence of a past incident but a pattern of silence, vague answers, or no visible process for telling customers when something goes wrong.
Connecting a new tool to your existing systems, rostering, payroll, your core care management platform, often feels like a pure win: less double entry, fewer manual exports, smoother workflows. It is also a new door into your data. Every integration and every API key is a connection that can be misused, misconfigured or forgotten about long after the person who set it up has moved on.
Before enabling an integration, ask what data actually flows across it, whether the connection can be scoped down to least privilege, and who is responsible for reviewing it later. An integration that quietly grants a third-party tool full read access to your core system, when it only ever needed rostering data, is a wider attack surface than most teams realise they have created.
You do not need a legal background to ask for the right paperwork, and you should not skip this step just because the software feels low-stakes. At minimum, look for:
If a vendor cannot produce anything resembling this, particularly for a tool that will hold participant information, that gap is itself useful information about how seriously they treat the responsibility they are asking you to hand them.
No checklist will catch every risk, and a tool can pass every question above and still turn out to be a poor fit. The bigger risk, by far, is that nobody asks these questions at all before a team starts relying on a tool day to day. A lightweight, consistently applied review beats a comprehensive one that only gets used occasionally.
The goal is not to slow your team down or make every free trial feel like a procurement project. It is to make sure that before something holds real participant, staff or financial data, at least one person with the authority to say "not like this" has actually looked at it. In most small and mid-sized providers, that can be a single person applying a short checklist in twenty minutes, not a formal committee. The habit matters more than the sophistication.
It is also worth applying this same lens backwards, not just to new tools. Most providers have never listed every piece of software currently holding their data. An annual pass through your active subscriptions, asking the same questions you would ask of something new, tends to surface a handful of things nobody remembered signing up to, and at least one that should have been cancelled a long time ago.
Yes. Free and low-cost tools are exactly how most shadow IT starts, and they hold participant data just as readily as anything you paid for. The size of the invoice has nothing to do with the size of the risk. If a tool will touch participant, staff or financial information, it deserves the same basic checks as a major system, even if the check only takes twenty minutes.
Not automatically, but it changes what you need to check. Offshore hosting can affect which privacy laws apply, how quickly you can get data back, and whether the arrangement satisfies specific funding or regulatory expectations. It is a question to ask and understand, not an automatic disqualifier, and requirements do shift, so confirm current expectations for your funding context before relying on general guidance.
At minimum, it should state what data the vendor can access and for what purpose, where that data is stored and processed, how and when they will notify you of a security incident affecting your data, what happens to your data on termination, and any subcontractors or sub-processors they use. If a vendor cannot produce this kind of document at all, treat that as a signal in itself.
An annual pass across your active software list is a reasonable baseline for most small and mid-sized providers, with a trigger review whenever a tool's ownership, pricing model or terms change significantly. The point is not perfection, it is making sure nothing sits unreviewed indefinitely simply because nobody remembered it was there.
Someone specific, even if they wear several hats. It does not need to be a dedicated IT role. It can be an operations manager or practice lead who applies a short checklist and has the authority to say no or ask a vendor more questions. The failure mode to avoid is a process that technically exists on paper but that nobody is actually accountable for running.
This kind of review is exactly the gap CareIQ IT's strategic IT planning and support is built to close for care providers. Rather than leaving software due diligence to whoever happens to sign up next, our team helps you put a lightweight, repeatable review process in place, run the checks in this article against new and existing tools, and assess the vendors and integrations already sitting inside your organisation. It is practical, ongoing IT partnership, not a one-off audit that gathers dust. Learn more about CareIQ's managed IT services for the NDIS and aged care sector.
As a smaller aside, this is also the kind of standard we hold the CareIQ platform itself to: Australian-hosted, with role-based access and MFA support, built specifically so participant data has a proper home rather than spreading across disconnected tools. If you are curious how it compares to what your team currently uses, you can see a demo, but that is a separate conversation to the vendor review process above.
CareIQ IT helps care providers review the software they already use, vet new tools before they go live, and build a lightweight process so nothing gets adopted unchecked again.
Talk to CareIQ ITGeneral information only, not legal or IT security advice. Recheck current Australian privacy, NDIS and aged care requirements and seek qualified specialist advice before acting.