The installed base of IoT devices in commercial buildings grew from 1.55 billion in 2022 to just under 2 billion by the end of 2024, and Memoori projects it will reach roughly 4.12 billion by 2030. Every sensor, controller, and BBMD added to that count is another stream of readings, states, and alarms flowing across the building’s OT network, all day, every day.
That growth is increasingly a liability, because a building that is collecting more data than it can govern isn’t actually more informed. It’s more exposed.
The question worth asking isn’t how much data a building generates anymore. It’s who controls access to it, who can trust it, and who gets to act on it.
The Data Needs a Plan, Not Just a Pipe
In every modern-ish building, connected systems — HVAC, lighting, access control, metering, fire and life safety — now report continuously instead of on a maintenance cycle. That data only has value if it’s accurate and available when someone needs it, which means the pipe itself has become a governance problem, not just a bandwidth one.
This is a critical spot where OT monitoring earns its keep. Visibility into the OT network, what devices exist, what they’re saying, and whether that traffic is behaving normally, is the precondition for trusting any of the data flowing through it. Without it, a building operator is reasoning from data they can’t verify, and can’t control where it ends up.
The shift is no longer treating the OT network as an open access point. Not every system, vendor, or algorithm should have equal, unrestricted reach into a building’s operational data by default. A real governance plan defines who and what can read from the network, who can write to it, and how both are audited over time.
Why This Is a Business Imperative, Not Just an IT Problem
Keith La Rose, Chief Revenue Officer at CopperTree Analytics, made the commercial case for this bluntly in a LinkedIn article and a companion piece for AutomatedBuildings.com. His argument starts with a line most building owners never negotiate: what happens to your data the day you fire the vendor.
For most portfolios, La Rose writes, the honest answer is brutal: without full, usable data portability the moment a contract ends, an owner hasn’t bought software, they’ve taken out a mortgage on their own building’s history. [editors note: for those following the current controversy with Sony’s decision to end physical media sales of Playstation games, this is exactly the criticism being levied against them].
When a legacy hardware vendor controls both the physical controls and the diagnostics built on top of them, he argues in his LinkedIn piece, three things follow:
- Data gets locked inside vendor-specific protocols.
- Every software improvement is gated behind a hardware refresh.
- Native interfaces throw hundreds of raw alarms a day instead of surfacing root-cause diagnostics.
There’s also a conflict-of-interest problem underneath the technical one. As La Rose points out, a vendor who designed a system, installed it, and profits from it is poorly positioned to grade its own performance honestly. His conclusion: real independence means an owner controls the data and can analyze it apart from whoever built the system in the first place.
Own your data and things get easier. You can check how a building is actually performing without buying new hardware first. You can roll out fault detection and optimization across a hundred buildings at once, instead of waiting on equipment upgrades site by site. And when it’s time to sell, the buyer isn’t stuck inheriting a mess of proprietary systems they can’t pull data out of, which protects what the building is worth.
Two Different Answers to Who Controls the Data
La Rose’s argument is about ownership: who has the rights to the evidence a building generates. It doesn’t resolve a second, separate question, which showed up in the comments on his LinkedIn post as a direct challenge from Greggory Don Butler, founder of TA-14, a governance framework focused on what he calls admissible execution.
Butler’s argument, in short: once intelligence is decoupled from the BMS, a different boundary starts to matter more than data ownership, namely who decides whether that intelligence is allowed to become a physical consequence. Clean, normalized, owner-controlled data can support better diagnostics and digital twins, he writes, but it doesn’t by itself make an automated action admissible. Before an optimization, override, reset, or shutdown command is allowed, someone still has to confirm the evidence behind it is current, the authority issuing it is valid, its scope is bounded, and the resulting outcome can be proven after the fact.
La Rose draws the line between the two problems cleanly. He calls “separat(ing) intelligence from the permission to act” the sharpest way he’s heard the distinction put: his piece was about who owns the evidence, Butler’s is about who’s authorized to let that evidence pull the trigger, and those are genuinely different governance problems.
He points out that they share a root, though, because both fail the same way: silently.
Bad data produces a confidently wrong diagnosis. Ungoverned authority lets that wrong diagnosis execute a shutdown on the hottest day of the year.
Two people don’t make a consensus, and this shouldn’t be read as an industry having converged on an answer. What it is: two specific, well-argued positions on the same underlying question, sovereignty of the data versus authority to act on it, that most governance conversations still collapse into one. They’re worth holding apart.
The Business Imperative, Expressed Through the OT Network
Both halves of that argument — who owns the evidence and who’s authorized to act on it — have to be enforced somewhere physical, and that somewhere is the OT network.
Most of that traffic in a commercial building still runs on BACnet, moving between controllers, routers, and supervisory devices that were built to execute sequences of operation, not to adjudicate whether a given command should be allowed to execute. That’s precisely the gap Butler is pointing at: a BACnet/IP network will faithfully carry an override or a shutdown command regardless of whether the evidence behind it is current, or whether whoever issued it had the authority to. Older buildings still running MS/TP segments have the same problem, and the cost case for making the jump to BACnet/IP only gets stronger the longer that gap goes ungoverned.
In part, this kind of gap in governance and reasoning is what led one of Optigo’s customers to help a client reclaim over 118,000 hours in lost scheduling, because no one could pin down the root cause of schedules constantly being overwritten – the system wasn’t wrong, it was doing what it’s programmed to do.
This is why OT monitoring tools matter beyond troubleshooting. Real end-to-end visibility into the OT network, what’s talking to what, what’s changed, what’s authorized, is the mechanism that makes both governance questions answerable in practice. Without it, a building can have perfectly clean, owned data and still have no way to prove that a given automated action was legitimate when it fired.
Building the Plan
A smart building generating millions of data points a year doesn’t need less data, it needs a clear plan for who owns and controls that data, and a separate plan for who (or what) is authorized to let it trigger a physical consequence. Clean, sovereign data is necessary, but it’s not the end state for good governance.
That first layer, visibility into what’s actually happening on the OT network, is where Optigo’s monitoring tools live, giving owners and operators the independent view of their BACnet/IP infrastructure they need before they can reasonably ask the harder question about authority to act. If you don’t yet have a clear answer to who owns your building’s data and who can prove your OT network’s traffic is legitimate, that’s the place to start.
FAQ
1. What is data governance for a smart building, and why does it matter now?
It’s the plan for who can access, trust, and act on the data a building generates. It matters more than ever because commercial buildings are on pace to have roughly 4.12 billion connected IoT devices by 2030 (up from under 2 billion in 2024), and a building collecting more data than it can govern isn’t more informed, it’s more exposed.
2. Is owning your building’s data the same as being able to safely automate on it?
No, and that’s the core distinction the piece draws out. Owning clean, normalized data (data sovereignty) is a different governance problem from deciding who’s authorized to let that data trigger a physical action (admissibility). Clean, owned data is necessary, but on its own it doesn’t establish that an automated command, like an override or a shutdown, should be allowed to execute.
3. What happens to a building’s operational data when you switch BMS vendors?
For most portfolios, it’s a bad outcome: without full, usable data portability the moment a contract ends, the owner hasn’t really owned their software, they’ve effectively been renting access to their own building’s operating history the whole time.
4. Why is it a conflict of interest for a BMS vendor to evaluate its own system’s performance?
Because the vendor who designed, installed, and profits from a system has little incentive to flag its own shortcomings. Real independence requires the owner to control the data and be able to analyze it apart from whoever built the system.
5. What is BACnet/IP, and why does it matter for building data governance?
BACnet/IP is the protocol most commercial building traffic still runs on, moving data between controllers, routers, and supervisory devices. Those devices are built to execute commands, not to check whether a given command should be allowed to, so the network will faithfully carry an override or shutdown regardless of whether the evidence behind it is current or legitimate.
6. What does a real governance gap actually look like?
One example from the piece: a governance and reasoning gap led an Optigo customer to help a client recover over 118,000 hours in lost scheduling, because no one could pin down why schedules kept getting overwritten. As the post puts it, “the system wasn’t wrong, it was doing what it’s programmed to do” — the failure was in governance, not in the equipment.
FAQs are created with the assistance of generative AI.
