← Articles
RIPOSTE research · 2026

Is Your Client Data Actually Confidential on the Tools You Use Every Day?

Every professional who handles confidential material makes the same promise, explicitly or not: what is said here stays here. Clinicians, lawyers, advisers, accountants — the promise is the foundation of the relationship. And the standard toolkit most practices now run on — a big-name suite for documents, a mainstream platform for video, a cloud system for practice management — was never designed to keep it. It was designed to move your data into someone else's cloud. That is not a scandal; it is the architecture working exactly as intended, which is precisely why it cannot be fixed with settings or vigilance.

The question underneath the promise

There is a single test that cuts through the marketing: can you answer your client's simplest question — “who can read my file?” — with the only answer that honours the promise: “only this practice”? On the standard toolkit, the honest answer is longer. It names the vendor, the vendor's subprocessors, and any authority that can lawfully compel any of them, in any jurisdiction that reaches them. If the true answer is a list of other parties, the promise has already been qualified — usually without the client, or the practice, ever deciding to qualify it.

The problem is structural: who holds the keys?

The common thread across the whole toolkit is simple and decisive: each platform holds the keys to the data it handles. Once that is true, your confidentiality no longer depends on anything within your control — it depends on the provider's policies, its personnel, its security posture and its legal obligations. You can run your practice impeccably and still be unable to guarantee who can read a file, because the ability to make that guarantee was given away at the architecture, before the first client was ever entered. A professional can only assure what they control.

A promise in the terms of service is not a system

Vendors make genuine commitments in their terms, and many honour them. But a policy commitment is made by people and can change with an update, whereas architecture does not have good days and bad days. The public record of one mainstream platform makes the point. In 2020 the US Federal Trade Commission found that Zoom had marketed “end-to-end, 256-bit encryption” while in fact holding the encryption keys itself, and settled the matter with a mandated security program and a twenty-year prohibition on misrepresenting its security — the regulator noting the false sense of security this gave users discussing sensitive health and financial matters. Then in 2023 Zoom revised its terms in a way widely read as permitting the use of customer content to train AI, reversing course only after public backlash. Set intent aside in both cases; the lesson is the mechanism. If the platform holds your data and can restate the terms, your recourse is outrage after the fact, not control before it — and a promise you cannot enforce is not the same as a system in which the promise cannot be broken.

Your video calls are probably not end-to-end encrypted

This one is checkable from your own meeting link. On the mainstream video platforms the default is not end-to-end encryption: traffic is encrypted between each participant and the provider's servers, but the provider generates and holds the keys — which means the provider can, in principle, access the content. True end-to-end encryption usually exists as an option, but it is off by default and, when switched on, disables the very features practices rely on, such as cloud recording and dial-in. If clients join your telehealth or client meetings from a browser link, then by the vendor's own documentation you are not running end-to-end encryption. And none of the encryption modes cover the metadata — who met whom, when and how often — which, for something like a mental-health practice, is sensitive in its own right.

“But we chose a certified vendor”

Diligence is worth doing, and the best vendors deserve credit for it — but diligence cannot convert this architecture into an assurance of confidentiality. You can select the best-certified provider on the market, configure everything correctly, and still be unable to answer the who-can-read-my-file question with “only this practice.” It is worth knowing, too, what a certification actually certifies: an ISO 27001 badge is only as strong as its scope statement, which the vendor defines itself and rarely publishes. Ask to see the scope, not just the badge — a certificate over a narrow slice of a business tells you far less than it appears to.

The Australian angle

For an Australian practice this is not only an ethical matter but a compliance one. Under the Privacy Act 1988, Australian Privacy Principle 11 requires reasonable steps to protect personal and health information, and APP 8 keeps your practice accountable when information is disclosed overseas. Health information is consistently the most-reported category in the OAIC's notifiable-data-breach statistics. And data residency is not the safeguard it is often assumed to be: under the US CLOUD Act, a US-based provider can be compelled to produce data in its possession or control wherever in the world it is stored — so “hosted in Australia” does not mean “reachable only under Australian law.” None of this is legal advice, and where it matters to you it is worth getting some — but it is the terrain your obligations sit on.

What to actually do about it

The first step is not to panic, or to rip out every tool overnight — it is to see the problem clearly, because you cannot manage an exposure you have not named. Map where your confidential data actually lives, who can reach it, and which of your promises the current architecture genuinely lets you keep. Some of it you will accept as a considered, documented risk; some of it you will want to change, and for the most sensitive material there are architectures in which the provider genuinely cannot read the content. The point is to make those decisions deliberately, with the real picture in front of you, rather than to discover them after a breach or a client's pointed question.

Where RIPOSTE fits

This is the kind of exposure we help organisations see and take control of: an honest, intelligence-led assessment of where your confidential data really sits, and where the promise you make your clients quietly breaks — mapped to your obligations, set out in plain language, and turned into a prioritised plan you can act on. We do not hand you a verdict and leave; we work through it with you. If “who can read my file?” is a question you would rather be able to answer with confidence, that is exactly where the conversation starts.

Sources

  1. FTC requires Zoom to enhance its security practices (2020 settlement)
  2. Zoom's terms-of-service change and AI use — CBS News (August 2023)
  3. Zoom — end-to-end encryption (E2EE) limitations (support documentation)
  4. Australian Privacy Principles (incl. APP 8 and APP 11) — OAIC
  5. OAIC Notifiable Data Breaches publications (breach statistics)
  6. CLOUD Act resources — US Department of Justice
  7. ISO/IEC 27001 — Information security management (scope of certification)
About the author

Cameron McCollum — Director & Founder, RIPOSTE. He spent two decades in Australian Army intelligence — serving as Head of Intelligence on operations across the Asia-Pacific and Afghanistan — before building and leading the cyber-risk program at Lexon Insurance. He holds Master's degrees in Cyber Security Operations and Business (UNSW) and is an ISO/IEC 27001 Lead Implementer.

RIPOSTE helps organisations turn analysis like this into action.

Talk to us