From Sensors to Signal: Unlocking Building Telemetry for Resilience and Security

Why Building Telemetry Matters More Than Most Teams Realize

This episode of Built, Wired, and Secured examines a problem that hits many commercial properties: critical building signals exist, but they are scattered across disconnected systems and separate vendor portals. The conversation opens with a vivid scenario many operators can picture immediately. A winter morning begins with backup power warnings, elevator fault codes, and tenant reports of intermittent outages. The issue is not a total lack of data. It is the opposite. The building is producing useful information, but no one is correlating it fast enough to stop a cascading failure.

That framing sets up the episode’s central argument: building telemetry should be treated as an operational asset. When organizations connect and govern the right signals, they can shorten outages, improve incident response, reduce confusion, and protect tenant trust.

What Counts as Building Telemetry

The discussion defines building telemetry broadly as the operational signals emitted by the systems that keep a property functioning. These are not abstract analytics. They are concrete inputs that already exist across most buildings, including:

• Access control logs and badge events
• HVAC temperatures and set point changes
• UPS and power quality alarms
• Elevator fault codes
• Smoke and fire panel statuses
• Water leak sensors
• Edge device heartbeats

Each stream has value on its own. The larger opportunity comes when multiple signals are reviewed together. A single alarm may look routine. Several aligned events across systems can reveal a developing outage, a safety issue, or a security concern much earlier.

Why Telemetry Gets Fragmented

Michael Harrington explains that fragmentation usually happens for three practical reasons. First, vendor stacks create separation. Contractors deliver systems with their own portals and their own ways of storing or exposing data. Second, organizations divide ownership by department. Facilities may own HVAC, IT may own networked sensors, and security may own access control. In that model, no one owns telemetry as a product. Third, budget and timeline pressure often push integration work to the bottom of the list.

The result is a blind spot around cross-system failure. Teams can see pieces of the event but miss the overall pattern. That makes it harder to answer a critical operational question quickly: what breaks if this goes down? Without that understanding, decision makers struggle to prioritize fixes, escalations, and investments.

The Trade-Offs: Visibility, Privacy, and Noise

The episode does not argue for collecting everything and showing it to everyone. Instead, it presents a disciplined approach to balancing visibility with privacy and operational usefulness.

The starting point is intent. Teams should ask who needs a given data stream and why. For example, tenant access logs may be necessary for incident response, but they may not belong in day-to-day analytics dashboards. That distinction matters because it shapes access controls and anonymization decisions.

The conversation also emphasizes signal value and latency. Not every feed needs the same timing. An HVAC temperature update every 15 minutes may be acceptable for comfort trends, but it will not help much during a fast-moving electrical event. Power quality and UPS alarms, by contrast, need near real-time visibility.

Finally, the episode addresses alert fatigue directly. More data does not automatically lead to better decisions. Aggregation, thresholding, and defined escalation policies are necessary to reduce noise and keep the important signals visible.

A Success Story: Correlation That Prevented a Bigger Outage

One of the strongest moments in the episode is a practical success story from a mixed-use campus. In that pilot, the team centralized UPS telemetry, remote breaker status, and elevator fault codes into a lightweight analytics dashboard. During one overnight event, the UPS reported rising internal temperature while breaker trips began on a secondary feeder. Because the dashboard correlated those timestamps, it triggered an on-call escalation quickly enough for the crew to respond.

The team replaced a failing converter before the issue became a full floor outage. Tenants barely noticed. The operational value was clear: faster response, fewer visible disruptions, and reduced reputational risk. The example reinforces an important point for leadership teams. Telemetry projects do not need to begin as massive enterprise integrations. A focused pilot around a high-value use case can produce measurable results.

A Failure Story: Separate Ownership, Shared Consequences

The cautionary example is just as instructive. In another tower, access control, HVAC, and the building management system were all owned and monitored separately. A chilled water pump tripped, HVAC alarms fired, tenants began reporting comfort issues, and security noticed badge anomalies as people changed circulation patterns and moved from elevators to stairs.

Every team assumed another group had escalated the issue. No one had a unified timeline. Contractors disputed who should place the emergency call. The incident dragged on with duplicated communication, delays, and a blame loop that damaged trust.

The lesson is blunt and useful: when ownership is unclear and no cross-system timeline exists, even a smaller fault can become a much bigger operational problem.

The Five-Step Implementation Checklist

For listeners looking to turn the discussion into action, the episode lays out a short and measurable checklist:

• Catalog the highest-value telemetry sources and identify owners. Keep the list focused on the top ten signals tied to uptime and safety.
• Assign owners not only for each system, but also for telemetry correlation and retention policy.
• Define retention and access rules, including what needs raw logs, what can be aggregated, and who can view personally identifying events.
• Set thresholds and playbooks so teams know what counts as an alert and how escalation should happen.
• Pilot analytics around one use case, then measure mean time to restore or tenant impact before expanding.

Another practical recommendation is to stay vendor agnostic where possible and use existing endpoints and open protocols. That lowers friction and makes future expansion easier.

Governance Turns Data Into Usable Intelligence

The governance section is especially valuable for organizations concerned about privacy and legal exposure. The episode argues that governance is what separates raw data from usable intelligence. That means defining clear roles such as data steward, system owner, and incident commander. It means limiting raw data access to people who truly need it, anonymizing badge IDs for analytics when appropriate, logging access events, and putting retention policies in writing.

The suggested model is practical: maintain short-term high-fidelity logs for incident response while keeping aggregated long-term metrics for trend analysis. Just as important, teams should document the success metrics that justify ongoing investment, such as reduced mean time to restore, fewer tenant complaints, and avoided outage minutes.

Three Actions to Take This Quarter

The episode closes with three concrete actions teams can take right away:

• Run a 10-minute telemetry inventory meeting with facilities, IT, and security to identify the top five signals used during outages.
• Assign a telemetry owner and agree on one retention and access rule to implement this quarter.
• Launch a one-month pilot that correlates at least two data sources for a single use case, such as UPS alarms plus elevator faults, and measure time to resolution before and after.

That is the core value of this conversation. It does not present telemetry as a buzzword or a giant transformation project. It presents a realistic roadmap for making existing building data more actionable. For commercial real estate teams, the upside is not only less downtime. It is clearer accountability, stronger incident timelines, better tenant experience, and more resilient operations.

From Building Data to Building Resilience

Commercial buildings generate more operational data than ever before. Access control systems log badge events. HVAC platforms track temperatures and set point changes. UPS systems issue alarms. Elevators report fault codes. Fire panels expose status changes. Water leak sensors and edge devices add still more signals to the mix. Yet in many properties, all of that telemetry remains trapped in separate systems, separate portals, and separate teams.

That gap is the focus of this Built, Wired, and Secured episode, “From Sensors to Signal: Unlocking Building Telemetry for Resilience and Security.” The conversation makes a practical case for treating telemetry as an operational asset rather than a byproduct of installed systems. The goal is not to collect data for its own sake. The goal is to make incidents easier to understand, easier to resolve, and less disruptive to tenants.

The episode opens with a realistic outage scenario. On a winter morning in a downtown office tower, the backup power system throws a warning. Elevator fault codes begin to stack up. Tenants start reporting intermittent outages. The issue is not that the building has no visibility. The issue is that the alerts live in three separate vendor portals, no one correlates timestamps, and teams piece the story together too late. By then, multiple floors are dark, productivity is lost, and trust takes a hit.

That example captures the main problem perfectly. Most buildings already have data. What they often lack is correlation, ownership, and governance.

What Building Telemetry Actually Includes

One reason telemetry programs stall is that teams talk about them too vaguely. This episode helps by defining building telemetry in concrete terms. It includes the streams of operational signals emitted by major building systems, such as access control logs and badge events, HVAC temperatures and set point changes, UPS and power quality alarms, elevator fault codes, smoke and fire panel statuses, water leak sensors, and edge device heartbeats.

Individually, those sources are useful. Together, they can tell a much more complete story. A badge anomaly alone may not reveal much. An elevator fault alone may not seem urgent. A UPS temperature alarm by itself may look manageable. But when those events line up by time and location, operators can detect a cross-system problem earlier and respond with more confidence.

That is why the episode frames telemetry as both a resilience issue and a security issue. Correlated data shortens troubleshooting, surfaces early warning signs, and produces a factual incident timeline instead of a blame-driven reconstruction after the fact.

Why So Many Buildings Still Operate in Silos

Michael Harrington identifies three common reasons telemetry remains fragmented.

First, vendor stacks create separation by default. Contractors and vendors deliver systems with their own dashboards, alerts, and reporting logic. There is often no standard ingestion path across those products.

Second, organizational boundaries reinforce the fragmentation. Facilities may own HVAC. IT may own networked devices and sensors. Security may own access control. In that arrangement, each group manages its own environment, but no one owns the telemetry layer across the building.

Third, integration work is easy to defer. Budget pressure and project timelines push teams to focus on getting systems installed and functioning. Correlation, retention design, and analytics often get postponed.

The operational cost of that delay can be high. When teams cannot quickly answer what systems depend on one another and what breaks when one signal changes, they struggle to prioritize the right fixes. The building may have dozens of alarms, but no shared view of which ones matter most.

The Real Balancing Act: Visibility Without Overreach

A useful part of the episode is that it avoids the simplistic idea that more visibility is always better. The better question is visibility for whom, for what purpose, and at what level of detail.

The recommended starting point is intent. If a data stream exists, teams should decide who needs it and why. Tenant access logs may be important for incident response or investigations, but not necessary for routine operational dashboards. That distinction helps organizations limit access, anonymize appropriately, and reduce unnecessary exposure.

The episode also draws a line between signals based on value and latency. Not every feed has to move at the same speed. An HVAC temperature reading every 15 minutes may be enough for trend analysis, but it is too slow to guide response in a fast-moving power event. UPS alarms and power quality data need near real-time treatment because they can indicate emerging failure conditions.

Then there is alert fatigue. Too many raw notifications create noise, not clarity. Aggregation, thresholds, and escalation rules are what make telemetry useful. Without those controls, teams simply replace one problem with another.

A Good Pilot Can Deliver Fast Results

The strongest operational example in the episode comes from a mixed-use campus where a pilot centralized UPS telemetry, remote breaker status, and elevator fault codes into a lightweight analytics dashboard. One night, the UPS began reporting rising internal temperature while breaker trips started on a secondary feeder. Because the dashboard correlated timestamps, it triggered an on-call escalation.

The responding crew arrived in time to replace a failing converter before the issue became a full floor outage. Tenants barely noticed the event.

That story matters because it demonstrates what leadership teams actually want to know: does this reduce disruption, and can it be implemented without waiting for a massive platform overhaul? In this case, the answer was yes. The pilot reduced mean time to restore by hours and avoided reputational damage.

There is a broader lesson here for commercial real estate operators and technology leaders. You do not need to begin with every possible signal in the building. You need to begin with a use case where correlation can materially reduce downtime or confusion.

What Happens When No One Owns the Timeline

The cautionary example in the episode is equally important. In another tower, access control, HVAC, and the building management system were monitored separately. A chilled water pump tripped. HVAC alarms triggered. Tenants complained about comfort issues. Security saw badge anomalies as people changed their movement patterns and took stairs instead of elevators.

But each team assumed another team had already escalated. There was no shared timeline and no clear owner for telemetry correlation. Contractors disputed who should make the emergency call. The building lost time to duplicated communication and blame.

This is where many organizations fail. They assume system ownership is enough. It is not. System ownership answers who maintains a platform. It does not answer who correlates cross-system signals during an event, who defines retention rules, or who ensures incident timelines are usable.

A Practical Roadmap for Getting Started

The episode closes the gap between strategy and execution with a five-step checklist that is concise enough for a leadership meeting and concrete enough for operations teams to act on.

First, catalog the highest-value telemetry sources and identify owners. The recommendation is to stay disciplined and focus on the top ten signals tied to uptime and safety.

Second, assign owners at two levels. Each system needs an owner, but telemetry itself also needs an owner responsible for correlation and retention policy.

Third, define retention and access clearly. Teams need to decide what requires raw logs, what can be aggregated, and who can see personally identifying events.

Fourth, create thresholds and playbooks. An alert is only useful if everyone agrees what it means and what escalation path it triggers.

Fifth, run a pilot analytics use case and measure results before expanding. The episode specifically suggests tracking mean time to restore or tenant impact before and after implementation.

Another smart recommendation is to stay vendor agnostic where possible. Using existing endpoints and open protocols reduces lock-in and makes future integration easier.

Governance Is What Makes Telemetry Actionable

For organizations concerned about privacy and legal exposure, the governance section is especially relevant. The episode makes the point that governance is what turns raw data into usable intelligence. That means defining roles such as data steward, system owner, and incident commander. It means logging access events, limiting raw data access, and anonymizing badge IDs for analytics when appropriate.

It also means putting retention policy in writing. High-fidelity short-term logs may be necessary for incident response, while aggregated long-term metrics are better suited to trend analysis. Without that structure, teams either keep too much, expose too much, or lose the detail they need when an incident occurs.

Most importantly, governance supports the business case. Reduced mean time to restore, fewer tenant complaints, and avoided outage minutes are metrics leadership can understand. They connect technical work to operational outcomes.

Three Actions Teams Can Take This Quarter

The final recommendations are refreshingly practical. Run a 10-minute telemetry inventory meeting with facilities, IT, and security. List the top five signals used in outages. Assign a telemetry owner and agree on one retention and access rule to implement this quarter. Then launch a one-month pilot that correlates at least two data sources for a single use case, such as UPS alarms and elevator faults, and measure time to resolution before and after.

That approach is manageable because it is focused. It does not require a perfect architecture on day one. It requires alignment, a limited pilot, and a commitment to measure impact.

Why This Matters for Property Teams

The broader message of the episode is straightforward. Buildings already produce operational signals that can improve resilience, security, and tenant experience. The value is not in having more dashboards. The value is in knowing which signals matter, who owns them, how they are governed, and how they get used during real incidents.

For property teams, that translates into less downtime, faster troubleshooting, clearer accountability, and stronger tenant confidence. If your organization has not yet treated telemetry as an operational asset, this episode offers a practical place to start. Listen to the full conversation and use it to begin your own inventory, ownership, and pilot planning process. Small moves here can produce outsized gains when the next incident hits.