Picture this: your best tenant, occupying the top five floors of your multi-tenant building, asks for last quarter’s occupancy data. You reply that the sensors are part of the building’s infrastructure, so the occupancy data is not automatically theirs. At the same time, your sensor vendor says that the collected analytics live in its cloud, so the processed data must remain there. The vendor wants to keep charging for occupancy insights from that data. You’re considering charging your tenants for those insights too. Sensing a problem, your legal team reviews all lease agreements and finds nothing specific about who owns the information generated by sensor systems, or who can profit from it. In a nutshell:
- You say, “I paid for the sensors.”
- The smart sensor vendor says, “I generated the analytics.”
- The tenant says, “That’s data about my people and my space.”
So, who really owns the data in this situation? Until you answer this question, the owner, the tenant, and the vendor will each try to use that data for their own gain, which creates disputes, privacy risk, and no clean path to monetize it.
Who Owns the Data in a Multi-Tenant Building?
When determining who owns the data, a bit of organization must happen first. Step one includes categorizing all data into three distinct segments:
- Feeds: Raw sensor data such as temperature readings, motion detection recordings, energy use, etc.
- Records: Data tied to a tenant or person, such as badge files, suite/floor level occupancy, after-hours access, etc.
- Insights: Information derived when analyzing feed and record data and making sense of it all in the form of dashboards, utilization scores, and forecasts.
It’s important to note that ownership of this data is not determined by who owns or pays for the sensor. Instead, you determine it by the language of two documents: the lease for tenants and the contract for technology vendors.
The lease and the vendor contract have to treat those three segments separately. The lease should say who owns feeds from tenant space, who owns records tied to a tenant’s people or floors, and whether either party can reuse insights built from that mix. The vendor contract should say who owns the raw feeds, who owns the processed insights, whether tenant records can leave the building, and whether the vendor can keep a copy for other products. If the documents lump every data type together, or say nothing at all, the owner does not have a clean claim. In practice, the party that stores each segment often controls it.
Unfortunately, shared systems make this process a bit messier. For example, a lobby occupancy sensor or a common-area access reader can capture traffic from every tenant at once. That feed can be considered building data and tenant data at the same time. To remove the gray area, you must name the system in both contracts. State that shared-area feeds belong to the owner, that tenant-identifiable records stay with the tenant or require permission to use, and that insights built from mixed data can be used only in aggregated form. If the contract does not draw that distinction, every shared sensor remains a dispute waiting to happen.
Where Privacy Laws Meet Smart Building Systems
Defining data ownership is only half of the problem, as some collected data involves personal data, which can lead to privacy issues.
Badge swipes, after-hours access, surveillance camera footage, Wi-Fi or Bluetooth tracking, and suite-level occupancy counts can identify a person or a tenant. This data falls under the records category, not the less risky raw feed. Once you can tie data to someone, GDPR, CCPA, and similar laws follow the use, not the sensor. Thus, as the building owner, you’re often held responsible even if a vendor runs the platform. Tenants also need to be told what you collect and why. Collecting extra data “just in case” is often what turns a smart building system into a privacy nightmare.
How to Monetize Building Data Without Losing Trust
Once ownership and privacy are clear and legally binding, monetization becomes an option in certain situations. There are low-risk and high-risk paths:
Low-risk: Sell or bundle building-level insights to tenants, buyers, or lenders. Examples include overall building energy or occupancy reports.
High-risk: Sell records or thinly masked insights that still point to one tenant or person. Examples include badge patterns, suite-level headcount, or a report that shows how one company uses its floors.
It’s always wise to stay away from high-risk data and insights monetization. Selling any report that points to one tenant or occupant can violate privacy laws, break tenant trust, and start a contract fight. Instead, it’s highly advisable to monetize insights that are building-level-only, and make sure to state this clearly in lease and vendor contracts.
