Data breach reporting starts with containment and an assessment of likely serious harm to clients. If your brokerage is covered by the Notifiable Data Breaches scheme, an eligible breach requires notification to the regulator and affected individuals. Multi-factor authentication, prompt updates and tested backups reduce the chance of reaching that point.
A suspicious login needs investigation. A stolen loan file needs a response that accounts for the identity documents, payslips and bank statements it contains.
What Data Security Covers in a Brokerage
Data security protects client information from unauthorised use while keeping it available for authorised work. In a brokerage, that information sits in the CRM, on laptops and phones, in email and in lender and aggregator portals.
Map those locations before choosing controls. Include downloaded loan documents, shared folders and the accounts an outsourced assistant uses. A secure CRM cannot protect an attachment someone downloads to an unmanaged laptop.
Your Obligations Under the Privacy Act
Australian Privacy Principle 11 (APP 11) requires covered entities to take reasonable steps to protect personal information. Destroy or de-identify it when no longer needed, unless a legal retention obligation or Commonwealth-record exception applies. APP 11 includes technical and organisational measures, so software controls and staff procedures both count.
Use the Office of the Australian Information Commissioner's (OAIC) small-business checklist to establish coverage. Annual turnover above $3 million generally brings a business under the Act. Below that threshold, test exceptions such as trading in personal information, related-company coverage, Commonwealth contracts, Consumer Data Right accreditation and voluntary opt-in.
The Notifiable Data Breaches (NDB) scheme follows applicable privacy security duties. Particular information can create duties even where general APP coverage does not apply. For example, a recipient of tax file number information has NDB obligations for that information. Record your brokerage's position and obtain advice where its activities make coverage unclear. Being a mortgage broker alone does not make you a credit provider under the Act.
Put the coverage decision and retention rules into your brokerage policies and procedures. Apply secure handling to every loan file, including where a contractual duty goes beyond statutory coverage.
The Threats That Reach Brokerages
Phishing messages impersonate lenders, aggregators or clients to steal logins and redirect payments. An email about settlement funds can look plausible because it names a real transaction. Ransomware can also stop access to files and expose information.
Internal habits create openings. Reused passwords let one compromised account threaten another. Shared logins hide who accessed a file. Misdirected documents expose clients without any intrusion, while unpatched machines leave known flaws available to attackers.
The Controls That Prevent the Most Incidents
The Australian Cyber Security Centre's small-business guidance recommends multi-factor authentication, software updates and backups. Apply these to email as well as the CRM and portals.
- Give each person an individual account. Require multi-factor authentication and unique passwords, including for administrators.
- Install updates promptly. Make someone responsible for checking devices that are rarely switched on.
- Keep backups protected from the accounts used for everyday work. Test a restore and confirm that the recovered file opens.
- Enable device encryption and screen locking on laptops and phones that hold client files.
- Review access regularly and remove it when staff or contractors leave. Limit each account to the files its owner needs.
An unusual-login alert is a prompt to investigate. Check who signed in and which files they reached. A VPN does not fix a reused password. The brokerage remains responsible for configuring its tools and reviewing access.
Contain a Breach and Preserve Evidence
Use the first hour to limit further exposure and establish who leads the response. Follow the OAIC breach-response sequence while your IT provider investigates.
- Restrict the affected account, revoke exposed sharing links or isolate the affected device from the network. Ask IT to preserve evidence before rebuilding a machine.
- Name the response lead and contact IT support through a trusted channel. If business email is compromised, use another agreed channel.
- Preserve logs, suspect emails and affected files. Record what was discovered and when each containment action occurred.
- Restrict affected loan documents to the response team. Keep evidence in protected storage and use secure transfer when specialists need access.
Do not delete client records, wipe devices or overwrite logs as a containment shortcut. Preserve the original evidence and let the response lead coordinate necessary changes. Stop staff forwarding suspect attachments around the business.
Assess the Risk of Serious Harm
For NDB assessment, ask whether personal information suffered unauthorised access, disclosure or loss. Then assess whether serious harm is likely and whether remedial action removes that likelihood. Lost information requires consideration of likely unauthorised access or disclosure.
Serious harm can include identity theft, financial loss and serious psychological or reputational harm. Assess the information involved, the people affected and safeguards such as encryption. Consider who obtained it and what they could do with it.
For a suspected eligible breach, take all reasonable steps to complete assessment within 30 calendar days after becoming aware of grounds for suspicion. Notify sooner when reasonable grounds establish an eligible breach. The assessment period is not permission to delay a known notification duty.
Keep an assessment record separate from early suspicion. Identify affected data and people, the safeguards in place, remedial actions and the reason for the conclusion. A confirmed deletion by an unintended recipient needs a different assessment from identity documents copied by an unknown attacker.
Notify the OAIC and Affected Clients
Mandatory data breach reporting applies when a covered breach is likely to cause serious harm and effective remedial action has not removed that risk. Notify the OAIC and affected individuals as soon as practicable, unless an exception applies.
The OAIC's NDB guidance sets out the statement contents. Include your identity and contact details, a description of the breach, the kinds of information involved and recommended protective steps.
Where practicable, notify all affected individuals or only those at risk of serious harm. If neither is practicable, publish the statement on your website and take reasonable steps to publicise it. Use plain language and advice that fits the exposed information.
Exceptions concern another entity's compliant notification, enforcement activities, secrecy provisions and OAIC declarations. My Health Record notification has a separate exception. Some exceptions leave partial duties, so document the exact basis before relying on one.
Finsure's incident shows why provider facts matter. In its statement reported by Cyber Daily, Finsure said compromised credentials allowed access to marketing data on a third-party platform. It said most data was basic contact information already public and reported precautionary notices to a small number of brokers and customers.
Finsure also said personal IDs, passwords and financial information were not impacted. That statement does not establish the outcome for another brokerage's exposed loan files. The Finsure incident account explains the provider-side event.
A privacy breach reporting decision is separate from the Australian Securities and Investments Commission (ASIC) test for credit obligations. Assess any overlapping incident through the broker breach-reporting process. Handle subsequent complaints through your client complaints process.
Coordinate CRM, Aggregator and IT Providers
Ask each provider for facts your brokerage can use in its assessment.
- Which client records and fields were affected, and was information accessed, copied or disclosed?
- When did access begin, when was it detected and what containment has occurred?
- Which logs and other evidence are preserved, and when can your response team obtain them?
- Which individuals are at risk, who will notify them and what information will that notification contain?
- What fixes will prevent recurrence, and how will the provider confirm they work?
A provider's own notice does not automatically discharge your brokerage's duty. Where entities jointly hold the affected information, agree who conducts the assessment and notification. Confirm that their actions satisfy the applicable requirements.
Managed IT can run patching and backups, but keep a named business owner for that work. Commission penetration testing against agreed systems and use its findings to repair exposed weaknesses. Contracts must address storage location, incident cooperation and what happens to client data when the relationship ends.
Train the Team, Then Tell Clients What You Do
Run short recurring training with examples from lender and aggregator messages. Verify changed payment details through a second channel using a number you already trust. Staff must report suspicious messages promptly and use their own logins.
Rehearse an incident before one occurs. Assign who disconnects an affected machine and who calls IT. The response lead must record when grounds for suspicion arise and when the assessment period starts.
Tell clients how you will contact them and which requests you will never make. Use a secure document portal for loan files instead of email attachments. Explain that you never ask for passwords, so a request for one is a warning sign.
Keep the Incident Record and Review Controls
Keep a restricted incident record of containment, assessment, notifications and corrective actions. Link affected client and loan identifiers without copying sensitive documents into the record. Preserve supporting evidence under controlled access and record who can retrieve it.
Assign each corrective action to someone and check the result. If a shared account caused the breach, verify that individual accounts replace it. If a backup failed, restore a file successfully before relying on the replacement.
Book one hour to check your brokerage now. Confirm multi-factor authentication on the CRM, email and portals. Restore a file from backup and open it. Name the person who leads a breach response and give the team their contact details.
