Why would you share your data?

So I asked him the obvious question: why would a client share their data with you?

His answer: so they can see their climate risk.

That was not enough, and on some level he already knew it. "So they can see their risk" is a reason for him to want their data. It is not a reason for them to hand it over. And once you sit on the client's side of that table, a second problem shows up behind the first, and it is the one that matters if you are the person deciding whether to bring in an outside data consultant at all.

The question every buyer is quietly asking

When someone pitches you a tool that runs on your data, you are not really evaluating the tool. You are evaluating a trade: your data, in exchange for whatever the tool shows you. And most of the time that trade is worse than it looks.

Your data leaving your walls is not a neutral act. It can be breached, subpoenaed, retained after the engagement ends, used to train something, or simply mishandled by a small vendor with no real security program. None of that requires bad intent. It just requires the data to be somewhere you no longer control. A cautious leader is right to hesitate, and the climate consultant's prospects were not being difficult. They were being reasonable.

"So they can see their risk" is a reason for the consultant to want the data. It is not a reason for the client to hand it over.

So the tool sat there, technically impressive and commercially stuck, because it was built on an assumption that quietly asked every client to take on risk for the vendor's convenience.

The part almost nobody says out loud: you probably don't need to share it

Here is what makes this more than a cautionary tale. In most of these situations, the data never needed to leave in the first place.

Building a capable tool inside a company's own environment is easier today than it has ever been. On the enterprise end you have platforms like Microsoft Power Apps, sitting inside the Microsoft 365 tenant you already pay for. On the lighter end you have quickly assembled internal tools, some genuinely useful, some less secure than their makers think. The back end is just as available in-house: a SharePoint list at the simple end, a SQL database you own and control at the serious end.

Put those together and the whole premise of "upload your data to my tool" starts to look like a choice, not a requirement. The consultant built his product as an outside destination your data had to travel to. He could just as easily have built the same analysis inside the client's own systems, on data that never moved. Same result on the screen. None of the risk.

What this means when you're the one hiring

If you are a senior leader weighing an external data consultant, this reframes the decision in a useful way. Do not evaluate whether you trust their tool enough to feed it. Ask whether they will build inside the systems you already own.

The good version works like this. You give the consultant access, scoped and temporary, to build. They stand the solution up on your infrastructure: your tenant, your database, your Power Platform, your governance. When the engagement ends, the tool does not leave with them and neither does your data. You are not renting a black box. You are getting an asset that lives in your house, on foundations you already paid for, that your own people can run and extend.

That is a different transaction from "share your data so you can see the output." It keeps ownership where it belongs, keeps your data where it is safest, and leaves you with something durable instead of a subscription and a dependency. The consultant's value was never the tool as a destination. It was the ability to build the right thing in the place you already control.

The consultant I met had it backwards, and it cost him months. He kept trying to talk clients into crossing a bridge they had every reason not to cross. He never stopped to ask why the bridge needed to be there at all.

Frequently asked questions

Should I ever let a consultant use their own separate tool with my data?
Sometimes, but treat it as the exception, not the default. If a vendor's platform genuinely does something you cannot replicate in-house, get the specifics in writing: where your data lives, who can see it, how long it is kept, and what happens to it when the engagement ends. If the same result can be built inside systems you already own, that is almost always the better trade.

What does giving a consultant "access to build" actually involve?
Scoped, temporary permissions inside your environment, the same way you would onboard a contractor. They build the solution on your infrastructure, hand it off, and their access is revoked when the work is done. The tool and the data both stay with you. See why buying a dashboard didn't fix your reporting for what that durable underneath-the-surface work usually is.

How do I know if a consultant works this way?
Ask them directly, early: "Will this live in our systems or yours?" The answer tells you quickly whether you are hiring someone to build you an asset you keep, or to sell you access to a tool you never own.