Establishing IoT governance before facilities goes shopping
If your facilities team was paying attention to CES earlier this month, they probably noticed the smart building technology on display, such as occupancy sensors that optimize space utilization, air quality monitors that support healthier workplaces, temperature controls promising 30% energy savings. The value is real, and facilities teams are right to explore these opportunities.
Now comes the part where someone in facilities starts asking IT about network access, firewall exceptions, and why the sensors aren’t showing up in the dashboard yet. By the time you hear about it, the purchase decision may already have been made.
Veteran IT pros have usually been through some version of this problem before. Building technology lands on your network without much IT input, and you’re expected to make it work. The goal here isn’t to relitigate past decisions. Instead, it’s to establish clearer boundaries going forward while figuring out what support you can realistically provide for the systems that are already in place.
Deciding which building IoT systems actually need IT oversight
Not every sensor in your building requires IT involvement, and treating them all as critical will burn through time you don’t have. The trick is distinguishing systems that actually need your involvement from those that can reasonably stay in facilities’ lane.
A standalone thermostat with a local display and no network connection doesn’t require IT oversight, for example, and neither does a basic motion sensor that just triggers lights in that room. If the device doesn’t connect to your network, doesn’t store data beyond the device itself, and doesn’t integrate with other platforms, facilities can probably handle it without you.
The calculus changes as soon as something touches your network, though. That includes occupancy sensors feeding analytics dashboards, air quality monitors sending data to vendor cloud platforms, and anything requiring authentication or integrating with building management systems, all of which could create security exposure you might be responsible for when something goes wrong. The same logic applies to devices collecting data with privacy implications, like occupancy patterns or access logs.
Before you invest time in fully evaluating a system, ask a few vetting questions:
- Does it need network connectivity?
- Does it send data outside the building?
- Does it integrate with other platforms?
- Will it require ongoing updates or credential management?
If the answer to any of these questions is yes, you need a seat at the table before procurement happens. Each networked device adds complexity—another endpoint to secure, another integration to maintain, another vendor relationship to manage.
Getting ahead of the next IoT purchase
Proactive governance doesn’t mean blocking facilities from buying anything, of course. It means establishing what IT needs to know before procurement happens, so you can ask questions, flag concerns, and document what you’re agreeing to support.
Network and bandwidth questions
Network requirements are the obvious starting point, but the questions go deeper than just “Wi-Fi or Ethernet.” Some IoT devices are notoriously chatty, constantly polling cloud services or broadcasting discovery traffic that can create congestion on networks that weren’t designed for dozens or hundreds of connected endpoints. Find out whether the system needs a dedicated VLAN, what kind of bandwidth it expects, and how it behaves when connectivity drops.
Security practices to ask about
Even a temperature sensor raises security questions worth asking before procurement. You’ll want to know how the vendor handles firmware updates, what their patch cadence looks like when vulnerabilities emerge, and whether data is encrypted in transit and at rest. You don’t need a 50-page security assessment, but you do need to know whether the vendor treats security as a priority or an afterthought.
Where the data goes
Facilities teams might assume the data stays local, but most of these systems phone home to vendor cloud platforms. Ask where the information actually goes, who owns it, and whether you can export it if you switch vendors. These seem like vendor-selection details until you’re three years into a contract and discover the vendor has been reselling your occupancy data, or that migrating away means rebuilding everything from scratch.
Support expectations
It’s easier to have the support conversation before the system goes live than after you’ve spent a weekend debugging someone else’s purchasing decision. What does the facilities team expect IT to troubleshoot versus what’s vendor-supported? Who contacts the vendor when something breaks? Answering these questions in advance will set everyone up for success.
What to do when facilities already bought it
Maybe you’re reading this article and thinking it’s too late. Facilities bought the occupancy sensors six months ago, they’re on your network, and now you’re fielding support requests for a system you never evaluated. You can still establish workable boundaries even when it looks like the horse is out of the barn.
Soft skills come in handy at a time like this. The conversation might go better if you lead with what you can support rather than what you can’t. “We can ensure network connectivity and escalate to the vendor when the system goes offline” is more productive than “We never approved this and we’re not supporting it.” Both points might be true, but only one message moves the relationship forward.
By explicitly documenting the support scope—for example, IT handles network connectivity, the vendor handles application troubleshooting, and facilities owns the vendor relationship—you’ll be able to avoid the “I thought you were handling that” conversations later. Response times should reflect the system’s actual business importance, not necessarily the urgency facilities may feel about it.
That said, it’s reasonable to push back on some things. Undocumented systems that facilities can’t explain don’t belong on your network, for instance. Devices with known security vulnerabilities and no patch path create liability you shouldn’t accept. If you can’t get basic information about what a system does, how it’s secured, and who’s responsible for maintaining it, that’s an appropriate place to draw a line.
Why it pays to have the sticky boundaries conversation now
IT’s relationship with facilities will outlast any individual sensor deployment, which is why it’s worth investing in clear communication now. Not only will it help everyone figure out how best to support the IoT solution at hand, but it will also keep paying off every time a new technology decision comes up. That way, your company can begin realizing the value of smart buildings that much sooner.
