APP 11.3 Technical and Organisational Measures: A Practical Implementation Guide
The part most compliance guides leave out
APP 11.3 requires organisations to take “reasonable steps” to protect personal information. That phrase does significant work in the legislation and almost none of it in practice, because most organisations interpret “reasonable” as “we have a policy and we ran the annual training.”
That interpretation will not hold under scrutiny. The OAIC’s enforcement work and published guidance makes clear it is looking at whether controls are operational, not just documented. There is a material difference between a control that exists in a framework document and a control that runs in production, gets tested, and has an owner who can account for it.
The implementation model that scales
Step 1: Map information flows
Document where personal information is collected, stored, transformed, shared, and deleted. Include systems, integrations, and third-party processors. Do not do this in a spreadsheet that nobody updates. Build it into your architecture documentation and treat it as a living record.
Step 2: Define risk tiers
Classify processing by sensitivity, volume, legal exposure, and business criticality. High-risk pathways warrant stronger safeguards and tighter assurance. Not everything needs the same treatment. Proportionality is the point of the “reasonable steps” test.
Step 3: Select and document controls
For each risk tier, define preventive, detective, and corrective controls. Typical examples include access governance and privileged access restrictions, encryption and key management standards, secure retention and deletion controls, and incident response playbooks with clear escalation triggers. Write down why you chose each control and what risk it addresses. That reasoning is what a regulator will want to follow.
Step 4: Build an evidence layer
This is where most implementations fail. A control is only defensible if there is evidence it operated. That means records of control owners and review dates, test outcomes and exceptions, remediation actions with closure evidence, and reporting extracts showing the control was visible to decision-makers.
Developers and ops teams do not naturally think like auditors. The evidence layer requires deliberate design. If your security engineers are not keeping test records, build the requirement into your pipeline or deployment process.
Step 5: Validate third-party alignment
Where vendors process personal information, align contractual controls with technical reality. Audit rights, incident notification windows, and data residency expectations need to be enforceable, not just stated. If your vendor agreement says they will notify you within 24 hours of a breach and you have never tested whether that pathway actually works, you do not have that control in any meaningful sense.
Step 6: Run assurance cycles
Annual policy reviews are not assurance. Periodic control testing tied to risk movement, incident learnings, and technology change is assurance. Build it into your schedule and treat missed cycles as exceptions requiring explanation.
The failure modes to watch for
Strong written policy with weak operating evidence is the most common. Retention rules defined but deletion workflows not implemented is close behind. Vendor obligations broad in contract but narrow in enforceability comes third. All three are predictable and avoidable.
90-day uplift checklist
- Baseline your top ten personal information processing pathways.
- Assign control owners for each high-risk pathway.
- Create a minimum evidence pack for each material control.
- Test one end-to-end incident scenario involving a key vendor.
- Refresh reporting to focus on exceptions and residual risk, not activity volume.
The bottom line
The organisations that handle APP 11.3 well built controls into their actual systems and kept records of them operating. The ones that struggle outsourced compliance to a policy team and hoped nobody would look too closely. The OAIC is looking more closely than it was two years ago, and the enforcement record reflects that.