Getting an AI building analytics platform through your client's IT review

You have won the technical argument. The client's engineering team likes the platform, the pilot scope is agreed, and then the project stops for six weeks while someone in IT works out what a building analytics platform actually connects to. For engineering firms, this is now one of the most common reasons a signed-off project slips.

This article is written for the engineering, commissioning and controls firms who have to get a client's IT and security team to approve a fault detection and diagnostics platform on their behalf. It covers what reviewers ask, what changes once AI agents are involved, what evidence to assemble before the review starts, and how to run approval alongside the pilot rather than after it.

Key takeaways

• The review is about access, not analytics. Reviewers care what the platform connects to, what it can change, and what it leaves behind as a record. The quality of the fault detection is rarely the sticking point.
• AI agents changed the questions. Two years ago the review asked whether the platform was secure. It now also asks what an agent can do on its own, whose identity it acts under, and who is accountable for what it recommends.
• Read-only access answers most of the hard questions. A platform that reads existing BMS points and writes nothing back removes an entire class of objection before it is raised.
• The audit trail is the deliverable. Reviewers want to see that an action can be traced from the rule that fired, to the person it was assigned to, to the data that confirmed the fix.
• Start the review in week one. Firms that hand over a security pack at the same time as the pilot scope consistently get live faster than firms that treat approval as a closing step.

What does a client's IT team actually ask before approving a building analytics platform?

A client's IT team asks six things: what connects to what, which direction traffic flows, what the platform can change, who sees the data, which third parties are involved, and what evidence exists afterwards. Analytics quality is an engineering question. Approval is about access, accountability and records, decided by people who will never open the platform.

It helps to recognise that the reviewer is not being obstructive. Building systems sit in an awkward place: they are operational technology, often old, frequently reachable from the corporate network, and rarely covered by the same controls as the IT estate. A reviewer who has read NIST SP 800-82 knows that the risk in a controls network is not data loss but loss of control of plant. The questions follow from that.

The checklist below is the one worth running against your own platform before you put it in front of a client. If you cannot answer eight out of eight, the review will find the gaps for you.

Two of these deserve particular attention, because they are the ones engineering firms most often cannot answer on the spot: what the platform can change, and what an AI agent is permitted to do without a person. The rest of this article works through both.

Why does an AI agent change what the security review asks for?

An agent acts between reviews. Traditional software does what a person tells it to, when they tell it. An agent triages, assigns and chases on its own schedule, so the reviewer can no longer assume that every action in the system was initiated by a known human at a known time. The review shifts from permissions to accountability.

This is the single biggest change in building analytics procurement over the last two years, and most vendor security documentation has not caught up with it. A pack that describes encryption in transit and at rest answers a 2023 review. It does not answer the question a 2026 reviewer asks, which is closer to: if this thing does something we did not expect, how would we know, and who is responsible?

There are three questions behind that, and they are worth separating because they have different answers:

1. Capability. What is the agent technically able to do? If it can only read data and create a record for a person to action, the blast radius is small. If it can write to a controller, it is a different review entirely.
2. Identity. Whose permissions does the agent act under? An agent that inherits a specific user's access is auditable in the same way that user is. A shared service account with portfolio-wide rights is not.
3. Accountability. When the agent recommends something and a person acts on it, whose decision was that? Reviewers want a name, not a system.

CIM's position on the third point is deliberately blunt: the AI recommends, your engineers decide. That is not a limitation to apologise for. It is the answer that makes the review straightforward, because it keeps a named professional accountable for every change made to a building.

Who decides what happens, the agent or your engineer?

The agent decides what to surface and who to chase. The engineer decides what is true and what gets fixed. Splitting the work this way means every change to a building is still authorised by a named person, while the repetitive work of triage and follow-up is handled automatically. It is also the split that a security reviewer can verify.

The four layers below are how CIM describes that split. The useful column for a security review is the last one, because it names the record each layer produces. A reviewer who can see what is logged at each stage rarely needs to understand the analytics at all.

If you want the longer version of how the agents themselves work, including how permissions are scoped and what a connected assistant can and cannot see, our article on AI agents in fault detection covers it in detail. For this conversation, the point is narrower: the decision rights are explicit, and they are visible in the record.

How do you show the platform cannot change anything in the building?

Show the direction of the connection and the absence of a write path. PEAK reads points that already exist in the building management system over an outbound connection, adds no new sensors and no new controllers, and has no mechanism to send a command back to plant. A reviewer can confirm that from the network diagram rather than taking it on trust.

This is worth stating plainly in the security pack, because it closes several questions at once. If the platform cannot write, then the worst case is not a plant outage. There is no path for an agent, a compromised account or a mistaken configuration to change a setpoint, because that path does not exist in the product.

It also changes the shape of the conversation about the controls network. A great deal of reviewer anxiety concerns vendor remote access: a standing route into the BMS so that someone off site can log in and adjust things. Being able to say that the integration is one outbound connection, and that nobody at the platform vendor has a login to the client's controls, removes the objection rather than mitigating it.

The related question reviewers ask is what the platform needs from the BMS to be useful, because a request for hundreds of extra points looks like scope creep to an IT team. In practice the constraint is data quality rather than data volume, which we cover in BMS point naming, Haystack and Brick. Bringing that detail to the review early tends to shorten it.

What audit trail should you be able to produce afterwards?

You should be able to take any closed action and reconstruct it: the rule that fired, the data that triggered it, the impact score, who it was assigned to, when, what they did, and whether the data agreed afterwards. If any link in that chain is missing, the record proves activity rather than outcome, and a reviewer will say so.

The last link is the one most platforms skip. An action that closes when somebody clicks close is a record of a claim, not a record of a repair. In CIM's own sample, about 1 in 6 closed fault tickets were closed before the data confirmed the fix had held. That is not a criticism of the engineers involved; it is what happens when the system has no way to check.

For a security reviewer, this matters for a reason that has nothing to do with energy. An auditable trail that distinguishes "someone said this was fixed" from "the data shows this was fixed" is the same control they would expect on any other system of record. It is also the thing that makes the platform defensible if the client is ever asked to show how a building was operated.

Independence sits underneath this. A record is only as credible as the party keeping it, which is why we argue that monitoring should sit outside the contractor and the controls vendor. Our piece on independent building monitoring sets out why nobody should be marking their own homework.

Which frameworks and evidence do reviewers expect?

Most reviewers work from a recognised framework rather than a bespoke list: usually NIST in the US, and commonly ISO 27001 plus a local baseline in the UK and Australia. You do not need to know it in depth. You need to know which one your client uses, and to ask your vendor for evidence in that shape.

The frameworks that come up most often in building analytics reviews are:

• NIST SP 800-82, the guide to operational technology security, which is where the segmentation and remote access questions usually originate.
• The NIST Cybersecurity Framework, used as the organising structure for many US client security questionnaires.
• CISA's guidance for operators working with third-party ICS integrators, which is directly relevant when an engineering firm is the integrator.
• ISO 27001, the information security management standard most often named in UK and European procurement.
• The Australian Signals Directorate's Essential Eight, common in Australian government and institutional portfolios.

Ask your vendor which independent assessments they hold and how recently they were carried out, and get the answer in writing before you commit to a date with the client. A vendor who cannot produce this quickly is telling you something about how the review will go.

How do you run security approval alongside the pilot instead of after it?

Treat approval as a parallel workstream with its own owner and dates, started the week the pilot is scoped. Most delay comes from serialising: the engineering team proves the value, then hands a finished proposal to a reviewer who is seeing the platform for the first time. Running both from day one typically removes weeks without changing the scope.

In practice that means four things:

1. Identify the reviewer by name in week one. Not "IT", a person. The commonest cause of a stalled review is that nobody owns it on the client side.
2. Send the pack before the pilot, not with the contract. Network diagram, data flow, direction of the connection, what is installed, agent permissions, audit trail export, data handling at exit.
3. Offer a scoped first building. A single building with a defined point list is a much smaller approval than a portfolio, and it gives the reviewer something proportionate to say yes to.
4. Prove it on your own estate first where you can. Hoffman Building Technologies deployed PEAK on its own 180,000 square foot Charlotte headquarters before taking it to clients, which gave them a real reference deployment to point at. ADG Energy runs phased school district rollouts and supplies equipment lists with levels and zones before integration starts, so the client's side of the work is visible from the beginning.

The last point is the one engineering firms underuse. A reviewer asked to approve an abstract platform behaves differently to a reviewer shown a working deployment with a named reference. Our guide, The Building Operations Manager's AI Portfolio Playbook, covers how to frame AI-assisted operations for the people who have to sign them off.

Where does CIM's PEAK Platform fit?

PEAK is an independent building analytics and fault detection platform. CIM is not owned by an equipment, controls or BMS manufacturer, which means the platform has no commercial interest in the outcome of a fault it raises against a contractor or a piece of plant.

For the specific questions a security review asks: PEAK reads existing BMS points, is BMS-agnostic, requires no new sensors and no new controllers, and does not write to building systems. More than 5,000 engineering rules deploy automatically rather than being written on site, and buildings are typically live within about 30 days, which keeps the approved scope small and dated. The platform runs across more than 700 commercial buildings and more than 100 million square feet, with more than 20 engineering and service partners delivering on it.

On AI specifically, the Analyst Agent answers questions about a portfolio through a connector for Claude, ChatGPT and Microsoft Copilot, and its permissions follow the PEAK login of the person using it, so it cannot surface anything that person could not already open. The Compliance Agent triages, assigns, chases and verifies fixes in the data. An Optimisation Agent is in development. In every case the agent recommends and your engineers decide.

If you are evaluating platforms rather than preparing a review, our comparison of FDD and building analytics platforms and the building analytics RFP guide are the better starting points, and how long it takes to get a building live covers the deployment timeline the review usually runs against. Partners can find deployment and enablement detail on the CIM partner programme page, and the fault detection and diagnostics solution page covers the platform itself.

Frequently asked questions

How do engineering firms get client IT and cyber security approval for building analytics platforms?

Start the review in week one rather than at contract stage, name the reviewer on the client side, and send a pack covering the network diagram, data flow direction, what is installed, agent permissions, the audit trail and data handling at exit. Scoping the first approval to a single building with a defined point list makes it far easier to approve.

Does a building analytics platform need to write to the BMS?

No. Fault detection and diagnostics works entirely from reading points that already exist in the building management system. PEAK is read-only and sends no commands to plant. Platforms that offer automated optimisation do need write access, and that should be treated as a separate decision with its own approval rather than bundled into the same review.

What can an AI agent in a building analytics platform access?

It depends on how identity is handled. In PEAK, agent permissions follow the login of the person using them, so an agent cannot surface anything that user could not already open in the platform. The question to ask any vendor is whether the agent acts under a named user's permissions or a shared service account with blanket access.

Can an AI agent change a setpoint in a building?

Not in PEAK. The agents triage faults, assign actions to named people, chase open work and check the data afterwards. They make no changes to building systems. The framing CIM uses is that the AI recommends and your engineers decide, which keeps a named professional accountable for every change made to a building.

Which security frameworks apply to building analytics platforms?

NIST SP 800-82 covers operational technology security and is where most segmentation and remote access questions originate. The NIST Cybersecurity Framework structures many US client questionnaires, ISO 27001 is most often named in UK and European procurement, and the Essential Eight is common in Australian portfolios. Ask which one your client uses before the review opens.

What audit trail should a building analytics platform produce?

You should be able to take any closed action and reconstruct the rule that fired, the data behind it, the impact score, who it was assigned to and when, what they did, and whether the data confirmed the fix afterwards. A record that stops at someone clicking close proves activity rather than outcome.

How long does client IT approval for a building analytics platform take?

It varies by client, but the biggest factor is whether the review runs in parallel with the pilot or after it. Firms that identify the reviewer and send the security pack while the pilot is still being scoped routinely get live sooner than firms that treat approval as a closing step, without changing the scope at all.