One SA Health employee has been reprimanded over inappropriate access to Tony Modra's medical records. Two others remain under investigation. Six people previously being investigated are no longer under investigation.
That is the position in ABC News's report of 14 September 2026, quoting an SA Health statement. It matters to keep those outcomes separate. Nine people being investigated or assessed earlier does not mean nine people were found to have done something wrong.
The technical lesson here is easy to miss if we think about security only in terms of stolen passwords. A person can have a legitimate account and still open information they have no work-related reason to see.
A valid login does not automatically mean valid access.
Three Questions Hiding Behind One Login
Authentication answers: who are you?
Authorisation answers: what are you allowed to see or do?
Logging answers: what did you actually access?
Those jobs overlap in a working system, but they answer different questions. An employee might use their own account, pass MFA and sign in from an approved device. That establishes useful facts about the sign-in. It does not establish a legitimate reason to open a particular person's record.
This is a general example, not a description of the authentication controls used in the Modra case. The current reporting does not establish those details.
The distinction also exists between what software permits and what an organisation authorises. A system may technically allow a record to be opened while workplace rules prohibit looking at it without a care-related or business reason. Good access design brings those boundaries closer together, with monitoring and accountable exceptions where necessary.
ASD's system-access guidance supports restricting access according to duties and removing it when there is no longer a legitimate requirement. For a small business, least privilege means giving someone enough access to do their work, without routinely exposing everything else.
The useful question is specific. Should this person be able to access this particular record?
What the Earlier Cases Add
There is documented history behind the current SA Health story. In February 2016, ABC reported that 13 hospital staff had been sanctioned for accessing Cy Walsh's records. The report said an audit discovered unauthorised privacy breaches across the state hospital system.
In December 2024, ABC reported findings involving 18 staff in the investigation concerning a patient understood to be Charlie Stevens. SA Health distinguished eight employees found to have inappropriately accessed clinical information from ten found to have engaged in misconduct. Those are not interchangeable findings.
That report also contains a useful qualification from Health Minister Chris Picton. He described an example involving an unattended computer where investigators could not establish who had accessed it. He said regular audits checked whether access was appropriate.
That is a practical limit on accountability. A record attached to an account does not always conclusively identify the person at the keyboard. Individual accounts, locked screens and careful investigation matter alongside the logs.
The September Modra report says SA Health has previously described regular access audits. It does not publish the investigation's log fields, detection method or complete evidence. We should not invent those details. The historical reporting does establish that auditing has helped identify inappropriate access.
Logs Need to Survive Until Someone Needs Them
An access log is a record of activity. An audit is the work of examining records and other evidence to assess what happened and whether it was appropriate.
For sensitive information, I would want to know whether available records can answer these questions:
- Which account accessed it, and when?
- Which system, file or record was involved?
- Was it viewed, changed, exported or shared?
- Was the activity unusual for that person's duties, and what related actions occurred?
Not every service records every action. A successful sign-in event cannot, by itself, show which customer files were opened afterwards. Check the application logs as well as the identity system's records, and establish what the provider actually makes available under your subscription.
Logging does not prevent someone reading a file. It can support detection, investigation and evidence about the access. Someone still needs to review useful signals and follow up. An archive nobody can retrieve is a fairly expensive way to remain uncertain.
ASD's event-logging guidance recommends retention based on system risk and investigative needs, warning that defaults and storage limits can leave records unavailable. It also recommends protecting logs against unauthorised modification and deletion.
I would check this with a harmless test file. Open it using an ordinary account, then ask the administrator to find the event. Establish how long that record survives and who can export it. If the action is not recorded, document the gap while there is still an opportunity to change the arrangement.
My Mathspace article looked at historical logs used to identify access before a security patch. Here the question concerns access by legitimate users. In both situations, the evidence available later depends partly on decisions made earlier.
Logs can contain sensitive information themselves. Limit who can read them, preserve relevant records during an investigation and avoid treating an unusual event as proof of misconduct without checking its context.
Try This in a Five-Person Business
Imagine a small consultancy with an owner, two consultants, a receptionist and a bookkeeper. They share a cloud document library because that was the simplest arrangement when the business started.
The receptionist needs appointments and customer contact details. The bookkeeper needs invoices and finance records. Neither role automatically needs every confidential client document. Yet one inherited folder permission may give all five people the same view.
Start with that folder. Put payroll and other restricted material somewhere with appropriate permissions, check inherited access and sharing links, then test the result using an ordinary staff account. Looking at the folder as the administrator will not tell you what the receptionist can see.
The same approach applies to a CRM. Decide whether staff need all customers or only assigned work, and whether exporting the full database should be a separate permission. Use role-based settings where the product supports them. A role should describe the work somebody does, rather than how long they have been with the company.
Administration deserves its own review. Someone who occasionally changes Microsoft 365 settings should use a separate, protected administrator account for that work. Giving everyone permanent admin rights because one person once needed help with a setting is an unnecessarily generous response.
Then review the people who are no longer part of the daily business. A contractor's project ends. An accountant's responsibilities change. A supplier is replaced. Access should be removed or adjusted when that happens, with recurring checks to catch anything missed.
These are manageable tasks without buying an enterprise identity platform. My small-business cyber security checklist includes stale accounts, shared administrators and documenting who has access. Choose one sensitive system and work through it properly before turning the exercise into a large spreadsheet nobody maintains.
Trust Still Needs Boundaries at Home
In a family-office-style environment, the permissions may have accumulated through years of perfectly reasonable requests. An assistant needed calendar access. A property manager needed maintenance records. An IT provider needed remote access during a repair.
Each request had a purpose. Whether that purpose still justifies the current access is a separate question.
An assistant can be trusted without needing banking documents. A property manager can manage a property without reading private correspondence. An IT provider's device access should have an agreed scope and duration, with unrelated cloud storage kept outside that arrangement where possible.
Make account ownership clear too. A family should know who can recover an important account and withdraw delegated access when a professional relationship ends. Sharing the owner's password tends to make both permissions and later attribution harder to manage.
Solway Web Consulting's personalised cybersecurity consulting for Sydney private clients can include reviewing those account relationships, permissions and available audit records. Device security is part of the work; understanding who can reach the information is another.
For a useful first exercise, choose a sensitive folder and ask its owner to name everyone who can open it. Then compare that answer with the actual permissions.
The differences give you somewhere concrete to start.
Tags: security, small-business, private-client, australia