How it’s built.

Why this architecture

The shape of the service is why the commitments above hold.

RebateRight runs on Azure Functions: code that starts when a request arrives, runs in milliseconds, and goes away. There’s no server we maintain, no host we patch, no virtual machine we configure. Microsoft handles the runtime; we handle the application on top.

Two consequences worth being explicit about.

The transient surface. Patient data exists in memory for the moment a request is being processed, and not after. It isn’t in a queue waiting to be picked up, a log waiting to be rotated, or a cache waiting to expire. Process ends; memory clears.

The shrunken attack surface. A serverless application has fewer places for an attacker to land than a traditional one. No SSH ports, no admin panels exposed to the internet, no long-lived processes to inject into. What’s left to defend is the application code, the authentication layer, and the keys in Azure Key Vault. That’s where our work concentrates.

Residency vs persistence

Two related commitments, often confused.

Australian data residency answers where the data lives. Microsoft Azure data centres in Australia, no transfer offshore. This is the standard regulators look for in healthcare procurement.

Zero Data Persistence answers whether patient data lives at all. For names, Medicare numbers, IHIs, and dates of birth, the answer is no. They pass through to Services Australia and back; nothing stays.

Residency alone is the weaker claim: a copy of patient data still sits somewhere, in a known jurisdiction. Persistence-plus-residency is the stronger one: there’s nothing patient-identifying to lose in the first place.

What passes through

An eligibility check is a round-trip. Patient details you submit travel through RebateRight to Services Australia and back. RebateRight is a conduit, not a destination.

Patient data passes through; it doesn’t land. Names, Medicare numbers, IHIs, dates of birth: not copied, not logged, not persisted. The response carries them out the same way they came in.

Government identifiers stay with their owners. Medicare numbers, Individual Healthcare Identifiers (IHIs), and provider numbers belong to Services Australia. We don’t reuse them to identify you or any patient.

No AI on patient data. Eligibility runs rule-by-rule against the published Medicare Benefits Schedule. Patient data never reaches an LLM or third-party AI service. Decisions trace back to a published rule, not a model. Deterministic and auditable. Full data-handling commitments live on Privacy: How we use it.

Where it runs

Microsoft Azure, Australian region. Azure Functions in an Australian data centre. Data doesn’t leave the country.

Australian access only. The service is reachable only from within Australia, per Services Australia’s integration requirements. Requests from outside Australia don’t reach the application.

IRAP PROTECTED underneath. The Azure regions we run in are IRAP-assessed for PROTECTED classification: the Australian Government’s standard for sensitive but unclassified data. We don’t hold the assessment ourselves; we run on infrastructure that does.

Encryption in transit and at rest. TLS for everything in transit. Azure Storage Service Encryption at rest. Microsoft manages keys for platform-managed services. We hold custody of the keys we issue and sign with. See Access and keys below.

Shared responsibility

A cloud service runs on a stack with 3 layers of accountability. Each layer has a clear owner.

Microsoft Azure owns the infrastructure. Physical data-centre security, host patching, hypervisor isolation, edge DDoS protection, network sovereignty controls, and platform certifications: IRAP PROTECTED for our region, ISO 27001 across the global Azure estate, SOC 2 Type II. The platform layer we rely on is the platform the Australian Government and major banks rely on.

RebateRight owns the application. Application code review before release, dependency vetting, key custody in Azure Key Vault, customer authentication, and monitoring. Anything that touches the data flow, access boundary, or a third-party call passes review before it ships.

You own access on your side. Keep your API keys safe; rotate them on suspicion. Apply your own access policy to app.rebateright.com.au: who in your organisation can sign in, from where, with what factor. Email security@rebateright.com.au if you suspect a key has been compromised, and we’ll revoke it.

Access and keys

Your API keys are yours. You generate them; we never see the original. We store only a hash: irreversible, salted, suitable only for verifying that the key presented matches the one issued. A full database compromise can’t reveal what we don’t hold. You can rotate at any time, on your initiation.

Our PRODA signing key lives in Azure Key Vault. The RSA key that signs our requests to Services Australia is generated inside Key Vault and stays there. We send the public half to Services Australia; the private half never leaves the vault. Every signature happens against the vault, not in application memory.

No anonymous access. Customer API requests authenticate per call against the key hash. Internal admin endpoints are separately gated. Anonymous requests don’t reach the application.

Least privilege internally. No account has standing access to customer data stores, regardless of role. Access to production infrastructure is granted on a need-to-have basis and audited.

Monitoring and response

Telemetry. Each request emits time, endpoint, status, latency, and exception details through Microsoft Application Insights, running in the same Australian Azure region as the service. Request and response bodies aren’t logged. Zero Data Persistence covers telemetry too.

What we watch. Error rates, anomalous traffic patterns, failed authentication attempts, exception spikes. Outside business hours, alerts page on-call.

Incident response. If something breaks or is breached, the sequence is: contain (revoke keys, isolate the affected component), assess (what was reachable, what was actually reached), notify (you, and the OAIC under the Notifiable Data Breaches scheme if the threshold is met, within 72 hours of becoming aware, per Australian law). Plain-English account of what happened, what data was affected, and what to do next.

Assurance posture

What we hold. Services Australia Certified for integration with their PRODA gateway: the gate that lets a Medicare-integrated product into the Australian healthcare market. This is the certification our specific service exists to operate behind.

What we lean on. Platform-layer certifications belong to Microsoft Azure: IRAP PROTECTED for our region, ISO 27001 across the global Azure estate, SOC 2 Type II. We rely on these for the infrastructure layer and document them rather than re-deriving them.

What informs our practices. The ACSC Essential Eight, the Australian Government’s Information Security Manual, and OWASP ASVS for application security review. We say informed by, not compliant with. The work to reach an assessed maturity level for each control is underway.

What we don’t hold yet. Independent IRAP assessment, ISO 27001 of our own, SOC 2 of our own. None are required for our category today; we’ll pursue them when customer use cases require, or when we move into adjacent ones.

Reporting a vulnerability

Found a security concern, a suspected breach, or a vulnerability in our service? Email security@rebateright.com.au.

We acknowledge within 1 business day. We tell you what we know, what we’re doing about it, and when to expect the next update.

For data deletion, access, or correction, see Privacy: Your rights. For breach notification under the Notifiable Data Breaches scheme, see Privacy: If something goes wrong.