BMS Data Access Policies for the Collected Copy

Access to a building management system is taken seriously, and rightly, because somebody with the wrong permissions can change a setpoint or override a safety interlock. Once that same data has been collected into a historian, a reporting warehouse or an analytics tool, the conversation tends to stop, on the implicit grounds that reading numbers cannot hurt anything. The collected copy then ends up with far wider access than the system it came from, and it travels further, because a reporting layer exists to be exported from.

The message up front: the collected copy needs its own access policy, separate from control system permissions and from the maintenance system's role model. Classify the data by what it reveals rather than by where it came from, set access at the dataset level with the site boundary enforced in the store, treat export and third-party sharing as the point of highest risk, and log reads on the categories where that matters. Most of this is cheap, and none of it happens by default.

1. Why control permissions do not cover this

Three things are being governed, and they are routinely conflated.

• Write access to the control system. The ability to change how the building operates. Governed by the controls team, usually well, and entirely out of scope here. Keeping the data path read-only is the subject of securing read-only BACnet access.
• Read access to the live system. Who can log into the head end and look. Usually restricted to operations, mostly because licences are expensive rather than as a deliberate control.
• Read access to the collected data. Who can query the historian, open the dashboard, run the report or take the export. This is the one with no owner, and it is the one that scales, because the whole point of collecting data centrally is to let more people and more tools use it.

The maintenance system's role model does not cover it either. That model, designed as in RBAC design for CAFM systems, governs records and transactions in that application. The telemetry store is a different system with a different, usually much coarser, permission model.

2. Classify by what the data reveals

Building telemetry is not uniformly sensitive, and treating it as one category produces either a policy so restrictive that the data is unusable or one so open that genuinely sensitive series are exposed.

3. Where to enforce it

Access intent is easy to write down and routinely enforced in the wrong layer, which is how it gets bypassed.

• Enforce in the store, not in the dashboard. A dashboard that filters by site is a presentation, not a control. Anybody with the underlying credential queries around it. For a multi-site estate this is the mechanism described in row-level security for multi-site reporting.
• Grant on datasets, not on tables. A time-series store usually has few physical tables and many logical series, so permissions have to be expressed in terms of point or asset groupings. If the store cannot do that, serve restricted categories through a separate view or schema.
• Make the site boundary real. On a managed estate, access scoped to a site is frequently a contractual requirement rather than a preference, and the architecture has to support it, per multi-site CAFM architecture.
• Use service accounts per consumer, not one shared credential. One shared account across every integration means nobody can revoke access to one tool, and nobody can tell which tool did what.
• Separate read from metadata. Some consumers need the point register to interpret data they are entitled to; others should not get the register at all. Those are different grants.

4. Export and third-party sharing

This is where the policy is actually tested, because it is where data leaves the controls you built.

Analytics vendors, energy consultants, commissioning agents and equipment suppliers all have legitimate reasons to want building data, and the usual mechanism is a bulk extract sent once and then forgotten. Three practices make that manageable. Define in advance what a standard external extract contains, so each request is answered from a template rather than negotiated, and so nothing is included by accident because it happened to be in the same table. Give external parties a scoped, expiring credential against the store rather than a file, where the tooling allows it, because a credential can be revoked and a spreadsheet cannot. And record what went where, with what date range and what point scope, because that record is the only way to answer the question later and it takes a line in a register to maintain.

It is also worth being explicit that an export loses its data quality context at the boundary. A recipient who receives values without the quality flags or completeness figures described in data quality flags will treat all of it as sound, and their conclusions will come back to you.

5. Logging reads, proportionately

Logging every query against a high-volume telemetry store is usually impractical and rarely proportionate. Logging nothing means there is no answer when somebody asks who took a dataset.

• Log bulk extracts and exports rather than interactive queries. These are few, they are the high-impact events, and the record is small.
• Log all access to the restricted categories, particularly occupancy-derived and security-relevant data, where the obligation often requires it.
• Log grants and revocations, which is the record that answers who had access during a given period and is usually missing.
• Review service account activity periodically. An integration that stopped being used but kept its credential is a common finding, and the same discipline as integration monitoring and logging applies.

6. Writing a policy that is short enough to be followed

A long document gets approved and ignored. What works is a two-page statement containing the category list, who may read each category, who may export it, who approves an external release, and where the release register lives.

Add one review obligation and one named owner. The review is a periodic walk through who currently has access, which reliably finds leavers, finished projects and service accounts for integrations that were decommissioned. The owner is the person who answers an external data request, and naming them is the single most useful line in the document, because without it those requests get answered by whoever is asked and the policy never applies. This sits inside the wider framework in data governance in asset-heavy organisations.

The idea to walk away with

Collecting building data centrally creates a second copy with a different, usually weaker, access model than the system it came from, and that copy is the one designed to be queried, shared and exported.

Give it a policy of its own. Classify by what the data reveals rather than by its source, enforce the boundary in the store rather than in the dashboard, treat export as the highest-risk event and template it, log the bulk movements and the grants, and name the person who answers external requests.

Final thoughts

One question usually settles how much of this is needed: who currently has read access to the historian or reporting store, and when did anybody last look at that list.

If the answer is a short list that somebody reviews, the policy is a formality worth writing down anyway. If the answer is a shared credential and a list nobody owns, then the categories above are the fastest route to something defensible, and the review itself will probably justify the effort on the first pass.

Related reading: RBAC design for CAFM, Securing read-only BACnet access, BMS cybersecurity, Row-level security, Data governance, Data retention policy.