How do I evaluate whether a building controls provider is credible and unbiased for a cybersecurity-sensitive project?

To evaluate whether a building controls provider is credible and unbiased for a cybersecurity-sensitive project, treat them like a supply-chain and trust-risk decision, not just a product vendor. You want evidence that they are technically competent, operationally mature, financially stable, and free from conflicts that could skew their recommendations.

1) Check independence and conflicts of interest

A provider is not truly “unbiased” if they are steering you toward products or services they financially benefit from.

Ask:

• Do they sell equipment, software, or managed services as well as advisory services?
• Are they tied to one manufacturer, distributor, or integrator?
• Do they receive referral fees, rebates, or commissions?
• Will they disclose all relationships that could affect their recommendations?

Red flags:

• “We only work with our preferred vendor stack.”
• No conflict-of-interest disclosure.
• Recommending proprietary solutions without showing alternatives.

What good looks like:

• Written conflict-of-interest policy.
• Clear disclosure of partner relationships.
• Multiple design or remediation options with tradeoffs.

2) Validate cybersecurity competence specifically in OT/BMS/ICS

General IT security experience is not enough. Building controls often involve OT/ICS, legacy protocols, safety implications, and uptime constraints.

Look for:

• Demonstrated experience with BMS/BAS, HVAC controls, access control, lighting, fire systems, and OT networks
• Knowledge of common protocols: BACnet, Modbus, LonWorks, KNX, OPC, proprietary field protocols
• Ability to segment networks, manage remote access, and handle vendor maintenance securely
• Familiarity with risk frameworks for OT environments

Ask for examples of:

• Past secure BMS designs
• Network segmentation architectures
• Remote access hardening
• Vulnerability management in live building environments
• Incident response in building systems

3) Request evidence of independent assurance

A credible provider should be able to show objective proof of controls and quality.

Useful evidence:

• SOC 2 Type II or equivalent operational assurance
• ISO 27001 certification
• ISO 9001 for quality management
• Cybersecurity framework alignment, such as NIST CSF or IEC 62443
• Independent penetration test summaries or audit reports, if relevant
• Secure development or configuration management practices

Important:

• Certifications are useful, but not sufficient.
• Scope matters. A certificate may cover only corporate IT, not building controls delivery.

4) Review technical references and case studies critically

Don’t accept glossy case studies at face value.

Ask for:

• References from similar-size, similar-complexity projects
• Projects in regulated or high-security environments
• Examples where they had to integrate security without disrupting operations
• Lessons learned from failures or incidents

When speaking to references, ask:

• Did they deliver on time and within scope?
• Were they transparent about risks and constraints?
• Did they propose secure defaults or only react when challenged?
• How did they handle vulnerabilities, patching, and remote vendor access?

5) Evaluate their security architecture approach

A credible provider should be able to explain how they reduce risk by design.

Expect them to address:

• Network zoning and segmentation
• Least privilege
• MFA for remote access
• Secure VPNs or jump-host architecture
• Device inventory and asset visibility
• Logging and monitoring
• Backup and recovery of controller configs
• Patch and vulnerability management
• Supply-chain security for embedded devices and software
• Hardening of default credentials and services

Red flags:

• “We’ll secure it later.”
• “The BMS network is isolated enough by default.”
• No plan for asset inventory or remote access control.

6) Assess their governance and incident readiness

A trustworthy provider should have mature internal processes.

Ask if they have:

• Security incident response procedures
• Vulnerability disclosure process
• Secure onboarding/offboarding of staff and subcontractors
• Background checks where appropriate
• Data handling and retention policies
• Change management and configuration control
• Subcontractor vetting

Also ask:

• Who owns security decisions on the project?
• How are exceptions approved?
• How are urgent changes handled safely?

7) Examine financial and operational stability

Cybersecurity-sensitive projects often fail when a provider is too small, unstable, or overextended.

Check:

• Years in business
• Financial stability
• Staff retention and turnover
• Dependency on a single person or subcontractor
• Ability to support systems over time
• Warranty and support commitments
• Local service capability for critical sites

A provider can be technically good but still risky if they cannot support you after deployment.

8) Make them explain tradeoffs, not just solutions

An unbiased provider should present options with pros/cons, cost, and residual risk.

For each recommendation, ask:

• What problem does this solve?
• What assumptions does it rely on?
• What alternatives exist?
• What are the security, operational, and cost tradeoffs?
• What is the residual risk if we don’t implement this?

If they only give one answer and it happens to be their offering, be cautious.

9) Contract for transparency and accountability

Put credibility requirements into the contract.

Include:

• Conflict-of-interest disclosures
• Right to review subcontractors
• Security requirements and minimum standards
• Patch and vulnerability obligations
• Logging and access control requirements
• Documentation deliverables
• Acceptance criteria
• Incident notification timelines
• Right to audit or assess
• Support SLAs
• Ownership of configurations and data

This helps turn “trust me” into verifiable obligations.

10) Use a structured scorecard

A simple rating approach can help you compare providers objectively.

Score 1–5 on:

• OT/BMS cybersecurity expertise
• Independence / conflict transparency
• Evidence of independent assurance
• Relevant project references
• Security-by-design capability
• Incident response maturity
• Long-term supportability
• Contractual willingness to be held accountable

Weight cybersecurity and independence more heavily than sales polish.

Quick red flags

Be very cautious if they:

• Won’t disclose vendor or referral relationships
• Can’t explain building controls security beyond generic IT language
• Dismiss segmentation, MFA, or logging as unnecessary
• Refuse to provide references
• Overpromise “fully secure” outcomes
• Push proprietary products without alternatives
• Have no documented security processes
• Treat operational uptime as incompatible with cybersecurity rather than designing around both

Practical due diligence checklist

Before selection, ask for:

1. Conflict-of-interest disclosure
2. Relevant certifications and scope statements
3. 2–3 references from similar projects
4. Sample architecture or security design approach
5. Remote access and maintenance model
6. Incident response and vulnerability management process
7. Subcontractor list and vetting process
8. Support model and SLA
9. Sample deliverables and acceptance criteria
10. Contract terms covering security and transparency

If you want, I can turn this into a vendor evaluation questionnaire or a scored due-diligence template you can use during procurement.