Cyber Security for Mortgage Brokers: What Your ACL and Privacy Obligations Actually Require

Mortgage brokers occupy an unusual position in the financial services landscape. You hold a significant volume of sensitive client data, you access multiple lender portals on behalf of clients, and you operate — in most cases — as a small or sole-operator business without the IT infrastructure of a major institution. That combination makes you an attractive target.

Business email compromise attacks targeting mortgage transactions are among the most financially damaging cyber incidents affecting Australian small businesses. A fraudulent email that redirects a client's settlement funds looks exactly like a legitimate instruction — and once funds leave the trust account, recovery is extremely difficult. But financial loss is only part of the exposure. A data breach affecting client files also triggers Privacy Act obligations, potential licence implications, and, depending on your aggregator arrangements, consequences for your ACL or authorised representative status.

What Data You Actually Hold — and Why It Matters

The starting point for any analysis of a mortgage broker's cyber obligations is the data itself. In the course of a standard loan application, a broker typically collects and stores:

• Full personal identity documents — passports, driver's licences, Medicare cards
• Bank statements (often 3–6 months, sometimes 12 months for self-employed clients)
• Payslips, employment contracts, and tax returns
• Notice of Assessments from the ATO
• Credit reports and credit file information
• Superannuation balances and statements
• Details of existing debts, living expenses, and financial commitments
• Property valuations and contract details

This data is not just sensitive from a privacy perspective — it is the raw material for identity fraud and financial crime. A compromised client file gives an attacker everything needed to open credit accounts, apply for loans, and impersonate a client across multiple institutions. For clients at or approaching settlement, the exposure is even more direct: funds that exist only as a balance waiting to be disbursed.

Most mortgage brokers retain this data long after a loan settles, either because of aggregator record-keeping requirements, potential refinancing activity, or simple lack of a documented data retention and deletion policy. The longer sensitive data is retained without adequate controls, the longer the window of exposure.

Your Regulatory Obligations

The Settlement Fraud Risk — Why It's Different for Brokers

The most acute cyber risk for many mortgage brokers isn't ransomware — it's business email compromise targeting property transactions. The attack typically works like this: an attacker monitors email communications between a broker, their client, a conveyancer, and a lender. At or near settlement, the attacker sends an email that appears to come from a legitimate party — often the conveyancer or another professional involved in the transaction — redirecting the client's funds to the attacker's account.

This same fraud pattern targets the full property transaction chain. Real estate agents and conveyancers face identical BEC risks — and with AML/CTF obligations commencing 1 July 2026 for real estate professionals, the regulatory pressure to address it is increasing across the sector.

The broker's position in this chain is significant. Clients may receive instructions claiming to be from or endorsed by the broker. If the broker's email account has been compromised, or if a lookalike domain has been used to impersonate the broker, the broker may not realise there's an attack underway until a client contacts them after funds fail to appear.

Protecting your email is therefore the single highest-priority security control for most brokers. A compromised email account doesn't just expose your communications — it gives an attacker a platform to impersonate you to your clients, your aggregator, and the lenders on your panel.

The Aggregator Portal Risk — Access You Carry With You

Most mortgage brokers operate under an aggregator arrangement and access multiple lender portals through that aggregator's systems. The access credentials you use to submit applications, retrieve client data, and track loan progress represent a significant attack surface — one that extends well beyond your own firm's systems into multiple lender environments.

A compromised broker credential doesn't just expose your client files. Depending on the aggregator platform, it may allow an attacker to access application data across multiple clients, modify lodged applications, or access information from other brokers on the same platform. Aggregators set their own minimum security requirements — many now mandate MFA for portal access — but individual broker practices around password management, shared logins, and device security determine how effective those controls actually are.

Risk Area	How It Manifests	Key Control
Email compromise	Attacker intercepts client communications; redirects settlement funds	MFA on email; out-of-band payment verification
Aggregator portal access	Stolen credentials expose client applications across panel lenders	MFA on portal access; unique strong passwords; no shared logins
Client file storage	Unprotected client documents accessible if device or cloud storage is compromised	Encrypted storage; access controls; documented retention/deletion policy
Phishing	Staff click malicious links; credentials or systems compromised	Staff awareness training; email filtering; MFA
Device loss or theft	Laptop or phone with unencrypted client files lost or stolen	Device encryption; remote wipe capability; strong device PINs

What the Privacy Act Now Requires

Since the Privacy and Other Legislation Amendment Act 2024 took effect in December 2024, the requirement to take "reasonable steps" to protect personal information under APP 11 has been clarified to explicitly include both technical and organisational measures. For a mortgage broker, the data profile — identity documents, bank statements, tax records, credit files — places you in a relatively high-sensitivity category even compared to other small businesses.

Reasonable steps for a broker practice of any size would typically include:

• MFA on all systems that store or access client information — email, CRM, aggregator portals, cloud storage
• Encrypted file storage — client documents stored in encrypted form, whether in the cloud or on local drives
• Access controls — support staff, parabrokers, or business partners should access only the files they need; all access should be role-based
• Documented data retention policy — how long client files are kept after loan settlement, and a process for securely deleting them when no longer required
• Secure document collection — using encrypted portals or secure file transfer rather than email attachments for collecting sensitive client documents
• Incident response plan — a documented process for what to do if you suspect a breach, including who to notify and in what timeframe

What Happens When Things Go Wrong

If you experience a cyber incident that results in unauthorised access to client personal information, you have concurrent obligations that must be managed quickly:

1. Notify your aggregator — your agreement with your aggregator almost certainly requires notification of cyber incidents affecting client data
2. Assess the breach — determine whether it constitutes an eligible data breach under the Privacy Act (unauthorised access to personal information that is likely to cause serious harm)
3. Notify the OAIC and affected clients — if it's a notifiable data breach, this must happen as soon as practicable
4. Report ransomware payments — if you have made a payment in response to extortion, report to the ASD within 72 hours (from 30 May 2025)
5. Notify your PI insurer — cyber incidents may affect both your professional indemnity and any standalone cyber insurance you hold
6. Engage legal and forensic support — particularly if client funds have been misdirected or significant data has been exposed

The common failure in breach response is delay — specifically, spending too long trying to understand the scope of the incident before notifying anyone. The regulatory expectation is that you notify promptly based on reasonable grounds to believe a breach has occurred, not after you have completed a full investigation.