Know the decision. Keep the record.
A practical guide to the December 2026 privacy-policy changes and the customer intelligence your team needs to understand.
What changes in December
From 10 December 2026, organisations covered by the new duty must add information to their privacy policies about certain automated decisions. The requirement concerns decisions that use personal information and could significantly affect an individual’s rights or interests.
That creates an immediate piece of work: find the relevant decisions, understand what information they use and make sure the policy accurately describes them. It does not require a new customer data platform or a particular hosting arrangement.
There is a wider operating question worth asking at the same time. Can the people responsible for an important customer decision inspect the rules, retrieve useful records and correct the system when it gets something wrong?
This guide separates the legal requirement from NTWRK’s recommendations for doing that work. The first is a disclosure duty. The second is about running a system your business can understand and maintain.
New privacy-policy information
- Relevant kinds of automated decisions
- Kinds of personal information used
Assess which decisions are in scope
1. Keep the customer model understandable
A warehouse-native approach puts customer profiles and shared definitions close to the data your business already controls. Separate tools can then use that foundation for analysis, messaging or decision-making.
Scott Brinker’s March 2026 article describes this as a composable canvas, with a governed data foundation and a changing set of applications and agents around it. That is a useful architectural direction. It is not a universal buying instruction.
The right design depends on the systems you already have, the work your team needs to do and the people available to maintain it. A packaged platform can be a sound choice. A custom system can become an expensive dependency if only its builder understands it.
Start with the decision and the people responsible for it. Then work out which data, definitions and records they need to control.
2. What the privacy policy must say
The new provisions apply when an APP entity arranges for a computer program to make a decision, or perform work substantially and directly related to it, using the individual’s personal information, and the decision could reasonably be expected to significantly affect their rights or interests.
The privacy policy must describe the kinds of personal information used, the kinds of relevant decisions made solely by computer programs, and the kinds where programs perform that substantial and direct role.
Start by establishing which decisions meet those conditions. Do not assume that every score, recommendation or marketing offer is covered simply because software is involved. Some marketing uses are named, though. The OAIC’s fact sheet lists differential or personalised pricing by online retailers selling significant goods, and programmatic advertising for significant goods or services, among the decisions it would generally consider in scope. Equally, a person approving an output does not automatically remove the decision from scope. Buying or configuring a vendor’s software can still count as arranging for the program, and the OAIC generally expects the obligation to stay with the business that uses it.
Keep legal scope and operating practice distinct. The new provisions do not prescribe an architecture. The recommendation is to keep a working inventory of important decisions, their owners and the records needed to investigate an outcome.
3. Check what your team can actually access
A customer’s data can sit in a system your business controls while the definitions and logic that make it useful remain difficult to retrieve. The opposite is possible too: a managed service can provide clear records, useful export rights and a well-tested handover.
Check the actual arrangement. Can your team retrieve the relevant records? Can it identify the version of a rule or model used? Can another operator reproduce the workflow? What changes when the contract ends?
Put the important rights and responsibilities in writing. Agree who maintains the records, how long they are retained and how they can be transferred. Test the process while the supplier is still involved.
Where can your team get the record?
- Supplier-managed records
- Access, retention and export rights agreed in the contract
- Business-controlled records
- Access, retention and maintenance assigned to your team
Test both: can another team retrieve and use them?
Building in the client’s environment can make control and handover easier to establish, which is why NTWRK builds there. The environment is only part of the work. Documentation, access and a team able to use them still matter.
4. Four parts of an understandable decision system
You do not need to rebuild your whole customer operation. Start with the pieces behind one important decision. These four are a useful design checklist. They are NTWRK’s recommendations, not a list of technologies required by the December reforms.
Q: What is a semantic layer and who should own it?
A semantic layer holds the agreed definitions and rules that turn raw data into terms the business can use: what counts as an active customer, how customer value is calculated and how churn is measured. It gives reports, models and workflows a consistent reference. Your team should be able to read, change and retrieve those definitions. If they live in a vendor’s tool, check that you can export them and what work would be needed to use them elsewhere when the contract ends.
1. The decision logic.
What it is: the rules, model or agent that turns information into an output. Use the simplest approach that can do the job reliably.
Why keep control: your team needs to know what the system is intended to do, how it was tested and who can change it.
What to check: access to the configuration and test results, clear version history, and a practical way to correct or replace the system.
2. The semantic layer.
What it is: the one agreed definition of the terms your decisions turn on, as above.
Why keep control: it’s a small piece to own and an expensive one to get wrong, because a quiet difference in how “high-value customer” is defined changes who gets offered what. Where a decision built on these definitions is in scope from 10 December 2026, the privacy policy has to describe that kind of decision and the kinds of personal information it uses.
What to check: whether the definitions are written down once, in a place your team can read. If they drift between tools, nobody can say which definition is authoritative, and a list of what feeds each decision depends on which system you ask.
3. Useful decision records.
What they are: records that connect an outcome to the relevant inputs, rule or model version and any human approval or exception. The detail needed depends on the decision and the risks involved.
Why keep control: these records help a team investigate errors, test changes and answer questions about the system’s operation. A record shows what fed an outcome. It does not, by itself, show how a model weighed those inputs.
What to check: whether the records are accessible, understandable and retained appropriately. Agree those requirements with the people responsible for privacy, risk and operation of the system.
4. Data consolidation.
What it is: one place where customer records are matched to one identity, wherever your business already stores data.
Why keep control: every decision downstream reads from it, so a fault here repeats in each one.
What to check: who controls the identity rules, and whether they would survive a change of platform. Some platforms can now leave your data in your warehouse, which is good. The identity rules may still live in theirs.
Together, these pieces make a decision easier to inspect and maintain. Their value depends on whether your people can use them in the work.
5. What real-time actually asks of you
Q: What is a real-time owned customer loop?
It’s a closed loop that runs on your own definitions and rules, wherever the data sits: a fresh signal arrives, a decision is made on it against those definitions, an action follows, and the result becomes the next signal, all in the moment, not in last night’s batch. “Real-time” is not a faster export. It’s the decision logic reading live data, acting on what is true right now and keeping a record of each decision as it goes.
Here’s what that looks like on the ground, told generically. Take a retailer with a loyalty program and live inventory across stores and a warehouse. A member opens the app. The useful decision is to offer them something they actually want, that’s actually in stock near them, at a margin that makes sense, right now. To do that well, the loop has to read live inventory, the member’s history and value tier, and the current margin position, decide in the moment, act, and then learn from whether the member took it.
Faster decisions make faults spread faster too. Agree what needs to be recorded, who reviews exceptions and when a person must intervene before expanding the loop. Test the accuracy of the inputs as carefully as the speed of the response.
The retail example is illustrative. Whether a particular offer, tier or exclusion falls within the December duty depends on the legal conditions, including its significance for the individual. The practical design task is to make the important decisions traceable and correctable, wherever the system runs.
6. Start with the decisions already being made
The disclosure work starts with your current operation. List the decisions that use personal information, the systems involved and the people responsible. Have the relevant privacy and legal advisers assess which fall within the new duty and what the policy needs to say.
Run the technical assessment alongside that work. For each important decision, establish which records exist, who can retrieve them and where the gaps are. Some gaps will be contractual or procedural. Others will need changes to a system.
If a build is warranted, choose one decision for a focused proof. Agree the baseline, the result that would justify continuing and who will operate the work. Run the test in your environment or an agreed, controlled NTWRK workspace. Document what would need to change for production and what your team receives at the end.
A proof can establish a useful pattern. It cannot certify an organisation’s compliance or replace the review of its other decisions.
7. How NTWRK approaches the work
An Australian consultancy that builds customer and operating intelligence, NTWRK starts with the decision or task your team needs to improve, establishes the evidence for a build and agrees what your business should keep.
A focused 30-day proof tests one priority against an agreed measure. It can run in your environment or an agreed, controlled NTWRK workspace. The scope sets out the hosting arrangement, access and what will be handed over. The result informs the next decision: continue, change the approach or stop.
Client work spans CRM, data governance, personalisation and lead nurture for Isuzu; customer journeys, email and cloud migration for Mecca; the connection between search, CRM and sales for REMONDIS; and web, personalisation and enquiry work for Colliers. These are different engagements with different scopes.
See the work for the context behind each relationship. If one customer decision needs a clearer technical foundation, bring that decision and the gap your team needs to close.
A checklist for the work before December
Privacy-policy review
- Have we established whether the organisation and relevant activities are covered?
- Have we identified decisions that need assessment under the new automated-decision provisions?
- Has the responsible adviser reviewed which decisions are in scope and what the privacy policy needs to include?
- Is someone named to approve, publish and maintain the policy update?
Operating review
- Can we identify the data, systems and suppliers involved in our important decisions?
- Can the responsible team retrieve the records needed to investigate an outcome?
- Are access, retention, maintenance and supplier responsibilities documented?
- Can the team correct a fault, review an exception and keep the system running?
The first four questions organise the disclosure work. The next four reflect NTWRK’s operating recommendations. Completing the checklist is not a legal finding of compliance.
Sources and review date
The legal summary refers to the Privacy and Other Legislation Amendment Act 2024, Schedule 1, Part 15, the OAIC’s APP 1 Guidelines (Version 2.0, September 2026) and the OAIC’s fact sheet and flowchart on the APP 1.7 to 1.9 transparency obligation, published with the OAIC’s announcement of 30 September 2026. The architecture discussion refers to Scott Brinker’s March 2026 article on the composable martech stack.
Sources checked 8 October 2026. Confirm the current guidance and the application to your business with your legal advisers. General information, not legal advice.
Take the guide into the meeting.
Get the PDF and the one-page checklist for the people reviewing your customer decisions.
Done. Your links are ready. They expire in fifteen minutes.
The field guide, PDF The one-page checklist
Newsletter delivery is stopped for this address, so no confirmation email has been sent. To check the delivery status, email hello@ntwrk.com.au from this address.
This download records your email, the company domain from it, the page, any campaign details in the link, how far you scrolled and whether you ticked Build to Keep. How we handle your details.
Choose one decision to improve.
Bring the decision, the systems behind it and the gap your team needs to close. The first call works through whether a focused proof is the right next step.