When the news broke that GoTo Health, a provider supporting veteran and Department of Veterans Affairs related care coordination, had suffered a data breach, the industry response was familiar. A statement was issued. Affected individuals were notified. Credit monitoring was offered. The regulator was informed. The cycle moved on.
For the veterans whose information was exposed, the cycle does not move on. It never does.
I am writing this as the Chief Technology Officer of Keytech Intelligence, and as someone who spent twelve years in the Royal Australian Air Force before serving as a Queensland Ambulance paramedic. I have carried a service number. I have filled out the forms. I have sat across from clinicians who asked about injuries, mental health, medication, family, deployments, and the parts of a service history that do not appear on a discharge certificate. Veteran data is not test data. It is not a marketing list. It is a mirror of the most consequential years of a person life, and in many cases it is the paper trail that determines whether they receive care, compensation, housing, or the benefit of the doubt when things go wrong.
That is the lens through which this breach has to be read.
The GoTo Health incident is not remarkable because it happened. It is remarkable because the sector keeps treating events like it as an IT problem. It is not an IT problem. It is a governance failure, a sovereignty failure, and a duty of care failure, and each of those failures compounds the next.
Start with what veteran data actually contains. A veteran health record is not a single blood pressure reading. It is a longitudinal file that can include service history, deployment locations, exposure records, mental health assessments, substance use history, family violence disclosures, sexual trauma disclosures, protected identity markers for those who served in sensitive roles, next of kin details, and the pattern of appointments that reveals when a person is unwell and when they are stable. Aggregate that across a population and you have something that adversaries, insurers, employers, and opportunists all have reasons to want. Aggregate it and lose control of it and you have handed a hostile actor a targeting package.
The second thing that gets lost in the coverage is sovereignty. Health platforms in Australia routinely rely on offshore infrastructure, offshore support desks, offshore analytics tooling, and offshore subprocessors that the primary vendor may not name in a plain English data flow diagram. The contract might say the data is hosted in Australia. The reality is that copies, backups, telemetry, error logs, and support session recordings can traverse jurisdictions the customer never approved and never audited. When a breach happens, the incident response conversation stops being about a single database and becomes an archaeology dig across half a dozen platforms operated by companies that owe no duty to the veteran whose data is in them.
Keytech Intelligence exists because that model is not acceptable for the workloads that matter most. We are not an IT services company that resells someone else stack with a local badge on it. We engineer intelligent systems with sovereign governance built into the architecture, not bolted on after a procurement checklist demands it. That distinction is not marketing. It shows up in how we design data residency, in how we scope access, in how we log and prove what a system did with a record, in how we build the ability to answer the question that boards and ministers eventually ask, which is who touched this data, when, and under what authority.
Sovereign governance means the answer to that question is knowable, defensible, and auditable without begging an offshore vendor for a log extract. It means the identity layer is under Australian control. It means the key material is under Australian control. It means the AI models that touch sensitive text are chosen and deployed with knowledge of where inference happens and what is retained. It means the support model does not require handing a screen share to a technician in a jurisdiction with different legal obligations. None of this is exotic. It is engineering discipline applied to problems that have too often been treated as procurement problems.
The GoTo Health breach also exposes a quieter failure, which is the belief that governance can be delegated to a compliance team after the fact. Compliance is a floor, not a ceiling. A system can be compliant with the Privacy Act, aligned to the Essential Eight, mapped to ISO 27001, and still be badly designed. Compliance frameworks are not architectures. They are checklists that assume the architecture underneath them is sound. When the architecture is not sound, the checklist becomes a shield behind which real risk continues to accumulate.
For veterans, the accumulation has a cost that is not theoretical. A compromised record can influence an insurance decision that a person will never see the reasoning for. It can surface in a phishing campaign that is tailored with information only a treating clinician should know. It can be used to socially engineer a family member into confirming a location or a routine. It can end up in a data broker aggregation that is later sold to a screening service that quietly downgrades a job application. The person on the other end of these outcomes is not a record ID. They are someone who served, who trusted a system to hold their story with care, and who has now been failed by that system in a way that no credit monitoring subscription repairs.
Three things need to change, and none of them are technically difficult. They are governance choices.
The first is that health platforms handling veteran data should be architected on the assumption that they are a target. Not a low probability target. A named, funded, patient, capable target. That assumption changes segmentation, key management, logging, backup design, and incident readiness. It changes who is allowed to hold administrative credentials and how those credentials are protected. It removes the polite fiction that a small vendor can defend a high value dataset with the same posture as a suburban dental clinic.
The second is that sovereignty needs to be verifiable, not asserted. If a contract claims Australian data residency, the customer should be able to prove it with independent evidence, not with a vendor assurance letter. If a subprocessor list exists, it should be current, named, and reviewable. If AI is used anywhere in the pipeline, the customer should know which models, where they run, and what they retain. Sovereignty that cannot be audited is not sovereignty. It is branding.
The third is that veteran data needs its own duty of care standard. General health privacy law is a baseline. It is not enough. The population is small, identifiable, often reachable through predictable channels, and includes people whose safety depends on their information not circulating. A specific standard, co designed with the veteran community and enforced by a regulator with the resources to actually enforce it, would move the sector from apology cycles to accountability.
At Keytech Intelligence we build for the version of this problem that is coming, not the version that already happened. Sovereign AI, sovereign identity, sovereign key control, sovereign logging, sovereign incident response. Not slogans. Engineering decisions with names, owners, and evidence. That is what I mean when I say we are not just an IT company. IT companies deliver tools. We deliver systems that can be trusted with information that carries a human weight, and we design them to be answerable when the day comes that trust is tested.
The veterans affected by the GoTo Health breach did their part decades before any of this software existed. The least the sector can do is stop pretending that their data is ordinary. It is not ordinary. It is a record of service, and it deserves an architecture built with that in mind.