Secure Software Development for High-Risk Data Systems
I'm Matt Ratcliffe, a software developer and architect who builds and reviews systems holding data that matters — health records, personal information, payment data, and the material that regulators and attackers are both interested in. Most of my work sits in healthcare and financial services, where getting access control wrong is not a bug report, it is a notifiable breach.
The failure that keeps happening
Almost every serious data exposure I have looked at comes back to the same root cause, and it is not a clever exploit. It is a system that correctly established who somebody was and then never properly established what they were allowed to do. Authentication is a solved problem that teams buy off the shelf. Authorisation is bespoke to every application, is usually written under time pressure, and is almost never tested with the same rigour as the features it protects.
The specific patterns recur with depressing consistency: a missing role treated as full access rather than no access; a single code path serving two different levels of trust; security checks enforced in the front end and assumed in the API; a tenant identifier taken from the request instead of the session. None of these require sophistication to exploit. Several of them can be found in minutes.
Compliance frameworks, and what they actually ask of a developer
Most compliance conversations happen between lawyers and executives and arrive at engineering as a spreadsheet. The translation step — what a given obligation means for the schema, the audit log and the access model — is where projects stall. These are the frameworks I most often build and review against:
GDPR — General Data Protection Regulation (EU/UK)
Applies to personal data of people in the EU and UK regardless of where your business sits, so Australian software with European users is in scope. Built around lawful basis for processing, data subject rights, and breach notification within 72 hours.
What it means in the build: Data subject access and erasure requests have to be answerable from the schema — which means knowing every table personal data lands in, including logs, backups and analytics. Retention has to be enforced by something, not documented as an intention.
HIPAA — Health Insurance Portability and Accountability Act (US)
Governs protected health information in the United States. Relevant to Australian health software with US customers, and frequently cited in procurement even where it does not strictly apply. Its Security Rule sets administrative, physical and technical safeguards.
What it means in the build: Audit controls and access logging are explicit requirements, not good practice. Every access to a health record needs to be attributable to a person and reconstructable afterwards. Encryption in transit and at rest is effectively assumed.
Australian Privacy Principles (APPs) — Privacy Act 1988
The thirteen principles governing how Australian organisations collect, use, store, disclose and secure personal information, with additional obligations for health and other sensitive information. The Notifiable Data Breaches scheme sits alongside them.
What it means in the build: APP 11 (security of personal information) and APP 6 (use and disclosure) are the ones that shape architecture: collect only what you need, keep it only while you need it, and be able to demonstrate that only the people with a legitimate purpose could reach it. Cross-border disclosure under APP 8 makes cloud region choice a compliance decision, not just a latency one.
Essential Eight — ACSC maturity model
The Australian Cyber Security Centre's baseline of eight mitigation strategies, assessed at maturity levels zero to three. Increasingly a procurement gate for government and government-adjacent work.
What it means in the build: Mostly operational rather than application-level, but three land squarely on developers: restricting administrative privileges (which is an authorisation model question), patching applications and their dependencies on a defined cadence, and application control. Multi-factor authentication is usually the easiest to evidence and the most commonly half-done.
Defence ISM — Information Security Manual
The prescriptive control set for Australian government systems, organised by classification level. Considerably more detailed than the Essential Eight, and where the Essential Eight is a floor, the ISM is the full specification.
What it means in the build: Control-by-control evidence is the defining characteristic: it is not enough that a system is secure, each applicable control needs a demonstrable implementation. Practically this means designing for auditability from the start — logging, cryptographic standards, segregation and system hardening decided up front, because retrofitting ISM compliance is close to a rebuild.
These overlap more than they differ. A system with a defensible authorisation model, real audit logging, sane data retention and tested backups satisfies most of what all of them are reaching for. The frameworks differ in emphasis and evidence, not in fundamentals — which is why designing for the strictest one you are subject to is usually cheaper than retrofitting each in turn.
What I do
Authorisation model design
Getting the access model right before it is spread across a hundred endpoints — roles, tenancy, delegation, and what a missing permission means.
Security review
Reading a system as an attacker would, with the source in front of me: access control, tenant isolation, API surface, and the paths nobody meant to leave open.
Multi-tenant isolation testing
Deliberately attempting cross-tenant access from an authenticated session, at every endpoint, and building that into the test suite so it stays true.
Compliance translation
Turning a framework or an audit finding into concrete engineering work — schema, logging, retention and access changes, with an honest view of effort.
Secure build & remediation
Building systems that hold sensitive data properly in the first place, or fixing one after an assessment has told you what is wrong but not what to do.
Pre-launch assessment
The review before a platform goes live or onboards its first significant customer, when changes are still cheap and nobody is depending on the answer yet.
Multi-tenant systems deserve special mention
If one customer can reach another customer's data, nothing else about your security posture matters. Multi-tenant isolation is the highest-consequence, least-visible property a SaaS platform has: it fails silently, it fails in the code paths nobody reviews, and the first person to notice is usually not on your team. Testing it properly means deliberately attempting cross-tenant access from an authenticated session, at every endpoint, as part of the build — not once a year in a report.
AI systems raise the stakes, not the standard
Adding a language model to a system that holds sensitive data does not introduce a new category of security problem so much as it removes the friction that used to hide the old ones. Retrieval that ignores the requesting user's permissions will cheerfully summarise records they were never entitled to see. I have written about this in building AI products for sensitive data, and it is a large part of why I work at the intersection of AI and regulated environments.
How I engage
Short reviews are usually the best place to start: an authorisation model review, a pre-launch security assessment, or a second opinion on a design before it is built. Longer engagements involve building the thing properly in the first place, or remediating a system after an assessment has told you what is wrong without telling you what to do about it. Details of engagement models are on the freelance engagements page.
One thing I will not do is provide a compliance certification or sign off as a legal assessor — that is a different profession, and anyone offering both should be treated with suspicion. What I provide is the engineering: the design, the implementation, and an honest account of where you actually stand.
Writing on security and high-risk data
- The Access Control Mistake That Exposes Entire Organisations
The failure patterns behind most serious data exposure, and how to test for what should not be possible.
- Authentication vs Authorisation: What Each One Actually Does
Why the two run at different moments, are enforced in different places, and are built from different material.
- The Danger of Treating a Missing Role as Full Access
Defaulting to permissive when a permission is absent, and the breach it eventually produces.
- One Code Path Can't Hold Two Levels Of Trust
Why sharing a handler between privileged and unprivileged callers ends badly.
- Why Front-End Security Checks Do Not Protect Your API
The check that is enforced in the browser and merely assumed on the server.
- How to Pen-Test a Multi-Tenant SaaS Application
A practical approach to testing the isolation property that matters most.
- Security Lessons from Building Software for Sensitive Information
What years of building for clinical and financial data actually teaches.
- Device Authentication vs User Authentication in Enterprise Mobile Apps
Two different questions that enterprise mobile deployments routinely conflate.
- Claude Found a Path to God Mode in Five Minutes
What it means for your threat model when finding privilege escalation gets this cheap.
- The Cost Of The Attack Just Collapsed
Why the economics of attacking your system changed, and what follows from that.
Common questions
Can you certify our system as GDPR or HIPAA compliant?
No, and be wary of any developer who says they can. Certification and legal assessment are a separate profession. What I do is the engineering half: designing and building so that the obligations are actually met, translating audit findings into concrete work, and telling you honestly where you stand before an assessor does.
We have had a penetration test and a list of findings. Can you fix them?
Yes, and this is a common starting point. Penetration test reports are generally good at describing what is wrong and poor at explaining what to change, particularly where several findings share one root cause in the authorisation model. Remediating the underlying design usually closes more findings than addressing them individually.
What is the difference between the Essential Eight and the ISM?
The Essential Eight is a baseline of eight mitigation strategies with maturity levels, intended to be achievable and widely applicable. The Information Security Manual is the full, prescriptive control set for Australian government systems, organised by classification. The Essential Eight is a floor; the ISM is the specification. If you are pursuing government work, expect the Essential Eight in procurement questionnaires and the ISM once you are handling classified or sensitive government data.
Do the Australian Privacy Principles apply to a small business?
Not automatically — the Privacy Act has a small business exemption based on turnover — but the exemption is narrower than people assume. It does not apply to health service providers, to businesses trading in personal information, or to contractors delivering Australian Government contracts. In practice, most software businesses handling health data are in scope regardless of size, and customers increasingly require compliance by contract even where the law does not.
How long does a security review take?
A focused authorisation model review is typically a few days. A broader review of a substantial codebase is one to three weeks depending on size and how much of the design is documented. I would rather do a narrow review properly than a broad one superficially, so it is usually worth starting with whichever part of the system would hurt most if it were wrong.
Is this different from hiring a penetration testing firm?
It complements them rather than replacing them. A penetration testing firm works from the outside, usually time-boxed and without the source. I work from the inside with the code and the design, which finds different things — particularly logic and access-control flaws that only make sense once you can see how the system is meant to work. Most organisations holding serious data want both.
Holding data you cannot afford to lose? Tell me what you are building — or read about healthcare integration, where most of this work happens in practice.