In early July 2026, one of the best known names in customer relationship management gave every business owner a small, useful fright. HubSpot changed how it handled customer data, then changed it back almost as quickly. The episode lasted about a week. It ended without drama. And yet it is worth sitting with, because it exposed an assumption most of us make without thinking: that the customer data inside our tools is simply ours, to hold and use however the software allows.
It is not, quite. And the fastest way to understand why is to look at what happened, fairly and precisely, and then to turn the lens back on your own stack.
What HubSpot did, and undid
The Australian marketing trade publication Mi3 reported on 5 July 2026 that HubSpot had, about a week earlier, changed its rules to move beyond permission marketing and toward what it described as shared data enrichment, with a default opt-in. The framing question, as reported, was a pointed one: would customers approve of a software vendor using customer-derived data to improve the records held by other companies, potentially including competitors? Within roughly a week, HubSpot reversed course and withdrew the change (Mi3).
Two things are worth saying plainly. First, HubSpot retreated quickly, which is to its credit rather than the opposite. A company that listens to its customers and reverses a decision inside a week is behaving well, not badly. There is no villain in this story. Second, because this moved fast, you should not treat any single report, including this one, as the last word. Confirm HubSpot's current policy on its own pages before you draw conclusions about the product you use.
So why dwell on a change that was undone? Because the speed of the backlash is the interesting part. Customers reacted strongly and immediately to the idea of their contact data being pooled to enrich records held elsewhere. That reaction tells you something true about the value and the sensitivity of the data sitting in your own systems right now.
Why the reversal matters more than the policy
Most policy changes from software vendors pass without comment. Terms are updated, a notice lands in an inbox, and life goes on. What made this one different is that it touched a nerve almost nobody talks about until it is prodded: the difference between data you are permitted to hold and data you are permitted to trade.
A customer gives you their email address so you can send them an order confirmation, or a quote, or a newsletter they asked for. That is a fairly narrow permission. It is not the same as permission for that email address, and the behavioural signals attached to it, to be pooled with data from thousands of other businesses so that everyone's records get a little richer. The person never agreed to the second thing. They may not even know it is possible.
The HubSpot episode is a concrete, recent prompt to ask the uncomfortable question. If a vendor you rely on quietly changed a default tomorrow, would you know? Would you have agreed if asked? And could you explain the change to the customer whose data it affects?
Your customer list is not really yours to trade
This is the heart of it. You are the custodian of your customer list, not its outright owner in the way you own a desk or a van. The people on that list handed over their details for a purpose, and that purpose sets the boundary of what you can fairly do with the data. Holding it to serve them is one thing. Using it as an input to enrich records held by others, including businesses you compete with, is a different thing entirely, and it is the thing customers rejected the moment it was put to them.
You do not have to take a hard line on this to act on it. You only have to notice that the boundary exists, and that your tools sit right on top of it. Most business owners have never read the data processing terms of the software they run their whole operation through. That is understandable. It is also the gap the HubSpot moment shone a light into.
The Australian backdrop is shifting under you
None of this sits still. Privacy, cyber, artificial intelligence and data reform continue to move in Australia, and the direction of travel is toward more responsibility for how businesses handle personal information, not less. For a readable quarterly snapshot of where things stand, the law firm Johnson Winter Slattery publishes a Digital Bytes update covering privacy, cyber, AI and data developments (JWS Digital Bytes).
There is an opportunity in this, not only a compliance chore. Consent, done well, is worth money. Consumer Data Right reforms were modelled as potentially adding around AUD 1.2 billion in value through easier consent and wider, safer data access (CFOtech). Businesses that make consent clear and keep good records are not just avoiding a problem. They are building the kind of trust that lets data flow to good use.
A necessary caution before you go further: everything here is general information to help you ask better questions. It is not legal advice, and it does not account for your specific circumstances. Whether the Privacy Act applies to you, and how, depends on facts particular to your business, so get advice about your own obligations rather than assuming you are covered or exempt.
A practical data audit for your CRM stack
Here is the constructive part. You do not need a legal team to do a first pass on this. You need an afternoon and a willingness to actually open the settings you have been clicking past for years. Work through the following.
-
1
List every tool that holds customer contact data
Not just the CRM. Your email platform, chat widget, form builder, analytics, booking system and advertising pixels all touch contact data. Write the full list down first, because you cannot govern what you have not named.
-
2
Find each tool's data processing terms
For every tool on the list, locate its data processing terms and read what is shared, enriched or used to train models by default. This is the paragraph nobody reads, and it is exactly the one that matters.
-
3
Check whether new features arrive opted in or opted out
A default matters more than a policy. If a vendor ships new data features switched on unless you switch them off, you need to know that, because the HubSpot episode shows defaults are exactly where the friction lives.
-
4
Record your lawful basis for each field, and whether you need it
For each piece of data you hold, note why you are holding it and whether you genuinely use it. Fields you collect out of habit are pure risk with no return. If you do not need it, do not keep it.
-
5
Check your privacy policy still describes reality
Policies drift out of date as your tools change. Read yours against what your stack actually does today. A privacy policy that describes a business you no longer run is worse than none, because it promises things you are not doing.
-
6
Capture and log consent at the point of collection
Consent should be gathered and recorded when the data comes in, not assumed after the fact. A dated, specific record of what someone agreed to is the single most useful thing you can have if a question ever arises.
-
7
Have a plan for when a vendor changes the terms
Decide now who reads the change notices and who makes the call when a default shifts. Without a named owner, vendor updates slide past unread, which is precisely how defaults change underneath a business without anyone deciding to allow it.
When a vendor changes the terms under you
The last checklist item deserves a little more weight, because it is the one that turns a one-off audit into an ongoing safeguard. Software as a service tools update constantly. Terms are revised, features are added, and the emails announcing it are easy to lose. If nobody owns the job of reading those notices, your position on customer data is effectively set by whichever default a vendor picks, not by any decision you made.
The fix is small and boring, which is why it works. Nominate a person. Keep a one page record of what each tool is allowed to do with your data. When a change notice arrives, that person reads it, checks it against the record, and either accepts it or acts. This is also where sensible AI automation earns its place: routing vendor notices to the right owner and flagging anything that mentions data sharing, enrichment or training is exactly the kind of dull, important task automation handles well.
Where we fit
You can run this audit yourself with nothing more than the checklist above, and plenty of businesses should. Where we tend to help is with the plumbing underneath it. Our CRM automation and integration work maps where your customer data actually lives, how it moves between tools, and where consent is captured and stored, so the answers to the questions above are documented rather than guessed. From there, we wire up consistent consent capture and connect it to your analytics so you can see what you hold and why. As an Australian AI-focused agency, we build these systems to make good data practice the path of least resistance, not an extra chore. For more plain-English guides on running a modern business well, see the rest of our blog.
In short
What can businesses learn from HubSpot's data enrichment backflip?
Key takeaways
- Mi3 reported that HubSpot briefly moved toward shared data enrichment with a default opt-in, then reversed the change within about a week. HubSpot acted fairly; the speed of the customer backlash is the real story.
- Your customer list is not really yours to trade. People hand over data for a purpose, and that purpose sets the boundary of fair use.
- Vendor defaults can change under you silently, so most businesses should audit what their own stack does with contact data by default.
- Run the audit: list every tool holding contact data, read its data processing terms, check opt-in defaults, record your lawful basis, keep your privacy policy current, and log consent at collection.
- Name someone to read vendor change notices and decide. This is general information, not legal advice, so seek advice about your own obligations.