Your Supplier Lost the Data. The Notification Is Still Yours.

Quest Apartment Hotels has confirmed unauthorised access to a database containing customer information. The access arose from a vulnerability involving a third-party service provider.

Quest says it identified the incident on Monday 17 August 2026, contained it and completed remediation work. The information involved relates to records from before June 2025 and primarily includes names, email addresses and other contact details. A small number of records also include dates of birth.

The supplier has not been named. The number of people affected has not been disclosed.

Those facts matter. But the most useful part of this incident is not the identity of the supplier or the eventual size of the breach.

It is the reminder that giving customer data to a supplier does not give away responsibility for it.

The first question is why the data was still there

When an older database is breached, the immediate questions tend to be technical.

How did the attacker get in? Was a vulnerability left unpatched? Was the database exposed to the internet? Did the provider have adequate monitoring?

All reasonable questions. They are not the first question I would ask in an audit.

I would start with this:

Why did the organisation still need the information?

Quest says the affected records were from before June 2025. That does not prove the information should have been deleted. There may be operational, contractual or legal reasons for retaining some records.

It does mean the retention decision should be explainable.

Australian Privacy Principle 11.2 requires an organisation to take reasonable steps to destroy or de-identify personal information when it is no longer needed for a permitted purpose, unless an exception applies.

The test is not whether the database is old. The test is whether each category of information still has a justified purpose.

A customer’s name may need to be retained for one period. Transaction records may need to be retained for another. A date of birth collected for a particular service may have no continuing purpose at all.

A proper retention schedule separates those categories. “We keep the whole record because the system keeps the whole record” is not a retention decision.

This is why data minimisation is a security control, not a housekeeping exercise. You cannot expose information you no longer hold.

Outsourcing the database does not outsource the consequence

Quest says the unauthorised access arose through a vulnerability involving a third-party service provider.

That description will sound familiar to anyone who reads breach notices. The data was ours, the system was theirs, and the vulnerability sat somewhere in between.

From the customer’s perspective, that distinction changes very little. They gave their information to Quest. Quest is the organisation they recognise and the organisation they expect to hear from.

The legal position has some nuance. Where more than one entity holds information involved in an eligible data breach, all affected entities may have obligations under the Notifiable Data Breaches scheme. Only one entity needs to notify the OAIC and affected individuals, and the entities can decide who will do it. The OAIC generally suggests the organisation with the most direct relationship with the affected people.

The practical point is simpler.

You cannot assume the supplier will take care of it.

Before an incident, the contract should establish:

• how quickly the supplier must tell you about a suspected incident
• what information the supplier must provide
• who conducts the assessment
• who decides whether serious harm is likely
• who communicates with affected people
• who notifies regulators
• how evidence is preserved
• who pays for investigation, notification and support

If those questions are being negotiated after the breach, the supplier arrangement was never properly finished.

A second example, and a much smaller business. On 28 August 2026 Sharp Motor Group, a car dealership at Tweed Heads, confirmed to Cyber Daily that its third-party IT provider had been involved in a cyber incident, and that it had “notified the OAIC in line with our regulatory obligations”. A ransomware group had listed the dealership several days earlier. What that group claims to have taken has not been confirmed by the company and is not repeated here.

Two things make it worth sitting alongside the example above. It is a small regional business rather than a national brand, so this is not a big-company problem. And the incident arrived through the IT provider rather than a booking platform, which is the relationship most businesses never examine and the reason to ask your provider the question directly. Under the controller and processor split proposed in the privacy exposure draft released on 31 August 2026, the dealership would be the controller and the provider the processor, and the notification would still sit with the dealership. It did here.

A contract is not third-party risk management

Supplier controls are some of the most confidently overstated controls I see in information security systems.

The Statement of Applicability says they are implemented. The evidence is a standard services agreement signed several years ago. Nobody can say when the supplier was last reviewed, what evidence was examined or whether anything has changed since onboarding.

That is not third-party risk management. It is contract storage.

ISO/IEC 27001:2022 deals with supplier relationships through a connected group of Annex A controls:

• A.5.19 addresses the information security risks associated with suppliers.
• A.5.20 covers agreeing relevant information security requirements with suppliers.
• A.5.21 addresses risks in the information and communications technology supply chain.
• A.5.22 requires supplier services to be monitored, reviewed and managed as they change.

The sequence matters.

Identify the risk. Put the requirement into the agreement. Consider the wider supply chain. Then keep checking whether the arrangement still works.

Most organisations do the middle step once and call the control complete.

The same problem appeared in the recent N-able N-central security alert. That incident presented a technical question for managed service providers: is the current hotfix installed, has the environment been checked for compromise, and can the provider produce evidence?

The Quest breach presents the other side of the same supplier relationship. If the provider actually loses the data, do you know what happens next?

One is a vulnerability-management question. This is an accountability question.

The same structure turns up well outside information security. In work health and safety, engaging a contractor does not move the duty either, and a service company was fined $230,000 over someone else’s worker on someone else’s plant. Different regulator, different Act, identical reasoning: the obligation follows the organisation that had the relationship, not the one that happened to hold the asset.

What an auditor should ask about a critical supplier

A supplier assessment does not need to begin with a hundred-question spreadsheet.

Start with the information and the consequence.

What information does the supplier hold or access? Why does it need that information? How long is it retained? Where is it stored? Who can access it? Which subcontractors are involved? How will you know if something changes?

Then ask for evidence proportionate to the risk.

For a supplier holding customer names, contact details and dates of birth, reasonable evidence might include:

• an independent security certification or assurance report
• the scope and currency of that assurance
• recent vulnerability and penetration-testing results
• incident response and notification arrangements
• access-control and logging practices
• backup, restoration and deletion processes
• subcontractor controls
• records from your own periodic supplier review

The certificate alone is not enough. Its scope may exclude the service you use, the location where your data is processed or a subcontractor that performs part of the work.

Read the scope. Read the exclusions. Check the dates.

If the only evidence in your supplier file is the provider’s marketing page, you have not assessed the provider. You have repeated its claims.

Retention requirements need to reach the supplier

Data retention policies often describe what the organisation will do inside its own systems and say very little about hosted platforms.

That misses where much of the data now lives.

If a supplier holds information on your behalf, your retention rules need to operate there too. The agreement and operating process should address deletion from live systems, archives, exports and backups. It should also establish what happens when the contract ends.

The OAIC’s guidance specifically recognises that an organisation may continue to “hold” information stored by a third party when it retains the right or power to deal with that information. Sending the records to a cloud provider does not necessarily remove them from your information holdings.

An auditor should therefore be able to follow one record through its lifecycle:

1. Why was it collected?
2. Where was it sent?
3. Who can access it?
4. How long will it be kept?
5. What event triggers deletion?
6. How is deletion verified?
7. What evidence is retained?

If the trail stops at “stored in the vendor’s system”, the control stops at exactly the point where the risk becomes difficult.

What I would check this week

You do not need to wait for your own breach notice to test this.

Pick the three suppliers that hold the most valuable or sensitive information for you. Your CRM, payroll provider, cloud platform, booking system or outsourced IT provider are usually good places to start.

For each one:

1. List the information it holds and the reason it holds it.
2. Check whether your retention period is implemented in the supplier’s system.
3. Read the breach-notification clause in the agreement.
4. Confirm the notification timeframe is measured in hours or days, not “as soon as practicable”.
5. Identify who at your organisation receives the notification.
6. Confirm who assesses likely serious harm and who communicates with affected people.
7. Find the most recent record showing the supplier’s security was reviewed after onboarding.

If you cannot find item seven, do not create a document saying the review happened. Schedule the review and do it.

Where this sits in an ISO 27001 system

Supplier management should connect to the rest of the information security management system.

The supplier register identifies the relationship. The information asset register identifies the data involved. The risk assessment records what could go wrong. The Statement of Applicability selects the controls. The contract sets requirements. Monitoring produces evidence. Internal audit checks whether the pieces still agree.

When these are built separately, contradictions appear quickly.

A supplier may be marked low risk while holding the complete customer database. A.5.22 may be marked implemented while no supplier review has occurred. The retention policy may say records are deleted after a set period while the hosted platform keeps them indefinitely.

This is the same reconciliation problem that appears when a risk assessment and Statement of Applicability are prepared as separate compliance documents. A good ISO 27001 gap analysis follows the links between them and tests whether the evidence supports the claim.

An independent ISO internal audit should go further. It should sample actual suppliers, actual contracts and actual review records. “We have a supplier policy” is the beginning of the audit trail, not the end.

The question the breach leaves behind

The Quest investigation is continuing. The provider has not been identified publicly, and the number of affected customers has not been disclosed. It would be wrong to fill those gaps with figures circulating through secondary sources.

What is confirmed is enough to make the management-system point.

Customer information was held in a database. A third-party vulnerability led to unauthorised access. Some of the records pre-dated June 2025. Quest contained the incident and contacted affected people.

For every other organisation using suppliers to hold customer information, there are two questions worth answering now:

Why is the supplier still holding the data?

And if it loses the data tomorrow, who does what by when?

If the answers are sitting in different policies, contracts and inboxes, they are not answers yet.

Speak with an experienced ISO 27001 auditor

Streamline builds practical ISO 27001 information security management systems that connect supplier risk, information assets, retention, contracts and incident response.

If your team is building the system internally, ISO mentoring gives you experienced guidance and the independent review needed before certification.

You will deal directly with an experienced ISO Lead Auditor, not a salesperson.

Email hello@streamline.business or call Brisbane 07 3667 8280, Sydney 02 8315 7780 or Melbourne 03 9034 3990.

Sources: Quest Apartment Hotels, “Data Breach” update, ABC News, The Register, OAIC guidance on APP 11, and OAIC guidance on multi-entity data breaches.

This article is general information from an auditing and management system perspective. It is not legal advice. The investigation is continuing, and details were current as at 21 August 2026.