Trust was designed in
before the first deployment.
Minimise trust. Constrain authority. Preserve evidence.
SECUVA™ sits at the boundary between healthcare data and the AI services that use it. That position has a consequence, and it was modelled before anything was built: require as little access as governing actually needs, hold every trust relationship to what its role demands, and leave evidence behind. The discipline SECUVA gives you over your AI providers is the discipline it applies to itself.
Three cyber security practitioners built this product. The threat model came first.
The strongest control is the access the platform never requires.
What SECUVA™ needs to know.
What it does not need to own.
Most security pages open with a list of controls. This one opens with the architectural separation that decides how much those controls have to carry.
01
Governing a relationship does not require holding its contents
Governance needs to know what was authorised, what was permitted, and what occurred. It does not need custody of the material that moved. So the control plane carries decisions and evidence, and that is a deliberately different thing from carrying healthcare data.
02
Sensitive processing stays bounded to your environment
What the platform must be trusted with is narrower than what it governs. That gap is the security property: compromise of one layer should not automatically become compromise of the healthcare data it governs.
03
Identity is governed, not assumed away
Where an authorised purpose does not require patient identity, identity stays on your side of the relationship. Where it legitimately does, the relationship is governed rather than anonymised. Governance is the product; minimised identity is one of its consequences.
A platform you have to trust completely
is a platform you cannot constrain.
Controls can fail.
Architecture determines
what failure can reach.
We approach our own platform the way a red team would: assume compromise, reduce blast radius, eliminate implicit trust. What follows is what that produced - four properties the architecture holds, rather than a list of settings that have to keep holding it.
Bound the trust surface
Sensitive processing and governance responsibility are deliberately separated, so no single component has to be trusted with both. The separation is structural, which is what makes it hold when a control does not.
Verify every relationship
Identities, channels and authorised interactions are established explicitly. Nothing is trusted because of where it sits on a network, and nothing inherits trust from something that was verified once.
Minimise privilege
Every component holds the authority its role requires and no more. Standing, broad or permanent access is treated as a design failure rather than a convenience to be documented.
Preserve evidence
Governed activity leaves evidence that supports assurance, investigation and accountability - including when the question is asked months later by somebody who was not there.
Security is not a department at SECUVA™. It is what the founders do.
Most healthcare data platforms meet security as a procurement requirement - a questionnaire, and a test once a year. The architecture above is what happens when defensive design begins with adversarial thinking.
Offensive practice
Adversarial simulation and red team experience, applied to clinical network environments rather than to a generic threat list.
Defensive architecture
Segmentation, privilege minimisation and cryptographic control designed by people who have operated them in production, not specified by one party and built by another.
Australian healthcare context
The privacy, records and governance obligations Australian healthcare organisations are actually assessed against, as the engineering brief rather than a later adaptation.
What runs in your environment
is attributable to what we released.
Supply chain compromise is among the highest-impact, lowest-visibility routes into a sensitive environment. SECUVA deploys software into yours, so it is treated as a standing operational concern rather than a procurement answer.
Signed releases
Releases are cryptographically signed, and what ends up installed is verified against that signature before it is trusted.
Dependency visibility
A software bill of materials accompanies each release, so the dependency tree can be reviewed independently rather than taken on assurance.
Automated security gates
Security findings are gates in the release path, not reports produced after it. Findings are triaged by an engineer rather than dismissed by a severity score.
Controlled update trust
Updates are accepted on the strength of the signature, not on the strength of the channel they arrived on.
Software bills of materials and supply-chain assurance material form part of the evidence package provided to enterprise security teams.
Security is an operating condition.
Not an annual event.
A vulnerability scan is not evidence of security; it is one input into a programme. A penetration test is evidence, not a strategy. The architecture and the operating model come first, and testing is how we show they continue to behave the way they were designed to.
The on-call security engineer is a practitioner, not a service desk.
Monitoring
Platform and governance activity is monitored continuously, with anomalies surfaced to the security team rather than batched into a report nobody reads.
Vulnerability management
Findings are triaged, prioritised and tracked to closure by people who can assess them technically.
Security testing
Independent testing, alongside internal adversarial exercises run by the people who designed the architecture and know where they would attack it.
Evidence on request
Testing outcomes, control evidence and an immutable audit trail of governed activity are made available to enterprise security teams under evaluation, rather than summarised into a badge.
Response is defined in advance.
Blast radius is bounded by design.
The architecture bounds what an incident at SECUVA can reach. Sensitive healthcare processing sits on your side of the boundary, so an event in our environment does not become an event in your patient data. What follows is how we respond to the events that are ours.
01
Detect
Monitoring surfaces the event to the security team, and it is classified before anyone acts on it.
02
Contain
Affected components are isolated, with forensic state preserved before anything is remediated.
03
Investigate
Root cause is established and evidence is preserved for the customer as well as for us.
04
Communicate
Affected customers are notified under defined commitments, and regulatory assessment is part of response rather than something that follows it.
05
Improve
The control gap is identified and the change is tracked to closure.
The regime you answer to
is the one this was built against.
SECUVA™ was engineered against Australian healthcare’s privacy, records, security and ethics environment - the obligations your organisation is actually assessed on - rather than built for another jurisdiction and translated afterwards.
Detailed regulatory mappings and control evidence form part of the security documentation provided during evaluation.
Australian privacy context
The obligations that actually apply to healthcare information here, as the design constraint.
Healthcare data governance
Records, consent and secondary-use expectations treated as architecture rather than paperwork.
Security assurance
Independent testing and control evidence, produced for the people who have to sign off. SOC 2 readiness program underway.
Responsible disclosure
A published route for external researchers, handled by practitioners.
Enterprise evidence
Threat model, architecture material and supply-chain assurance, supplied under evaluation.
Your security team
can go deeper.
Threat model, architecture material, supply-chain assurance, independent testing outcomes and control evidence are made available to enterprise security teams during evaluation. This page is the argument; that is the evidence behind it.
Found something? Tell us.
We have been on your side of this conversation. Reports reach the security team directly rather than a queue that ranks them by score, good-faith research is welcomed, and legitimate findings are credited.