By John Bigelow

The question facing security managers is no longer whether cloud technology has a place in physical security. It is where that place should be. A remote site with limited local infrastructure presents a different problem from a large facility that needs substantial video storage and dependable local operations. Treating both as candidates for the same deployment model makes little sense.

In a recent Security Solutions Media interview, Andy Mackay, Regional Vice President of EMEA and APAC Marketing at Genetec, offered a more practical starting point. Look at each workload through three lenses: operational need, risk and compliance, and cybersecurity. The answer may be on premises, in the cloud or somewhere between the two. The important thing is being able to explain why.

Start with the work the system must do

Before discussing architecture, identify what must keep working at each site and under what conditions. Which functions need local processing or storage? How much connectivity can the operation depend on? Where do staff need to see and act on information? Then consider the rules governing the data and the consequences if access is interrupted.

That exercise changes the purchasing conversation. Instead of asking a vendor whether its platform is cloud ready, ask which specific functions can be managed centrally, which should continue locally and how they work together. A hybrid arrangement may be the sensible outcome. It may also be a stage in a longer transition, provided the organisation retains the option to change course.

Make responsibility explicit

Mackay is clear that risk does not belong to a single team. The vendor is responsible for building security into its products. The integrator must design and deploy the system in line with the customer’s requirements and applicable rules. IT brings the organisation’s policies for technology, cybersecurity and governance. Security operations must be able to use the resulting system to do its job.

These roles overlap at precisely the points where projects can go wrong. A system may meet the operational brief but fail an IT review late in procurement. An integration may work in a demonstration yet leave uncertainty about who maintains it. Bring all four parties into the discussion early, and record who owns decisions, changes and incident response after handover.

Follow the data

For any cloud service, Mackay recommends starting with basic questions: Where is the data stored? Who owns it? Who can access it? How long is it retained? He then turns to encryption, access logs and evidence of the provider’s security practices. These are contractual and operational questions, not details to be left to a brochure. The answers should distinguish the customer’s users from the provider’s support staff and subcontractors, and explain how access is authorised and recorded. Buyers should also establish what happens to recordings and metadata when the contract ends.

Australian buyers should check how a supplier’s claims apply to the service they intend to buy. Genetec, for example, says Security Center SaaS is hosted in Australia and has completed an IRAP assessment to the OFFICIAL level. That is useful information for relevant buyers, but an assessment does not replace their own review of data flows, configuration, access rights and obligations.

Keep an exit open

Open architecture has traditionally meant avoiding a wholesale replacement of cameras, controllers and other hardware simply to adopt a new platform. Mackay argues that the same thinking must now extend to cloud services. A system can accept existing devices and still make it difficult to move data, integrate another service or change provider later.

Ask prospective suppliers to demonstrate the integrations that matter to your environment, including how they are secured and supported. Find out what happens when an integration breaks, a product reaches end of support or a contract ends. The ability to connect two systems is only the beginning; the combined system also has to remain usable and maintainable.

Buy for the next decision too

Before signing a long-term contract, Mackay suggests testing three things: flexibility with existing investments, the supplier’s cybersecurity approach and the platform’s capacity to evolve. His example is an organisation that begins entirely on premises, then acquires a business with many remote sites. Can it add cloud capability without forcing another complete redesign? Ask for a practical migration path, including any limits on compatible equipment or functions. A promise of future flexibility is more useful when its cost and conditions are clear.

The same discipline applies to AI. Mackay advises security managers to define the business result they need before becoming absorbed in features. That is a sound test for any new technology: identify the operational problem, agree on a measurable outcome and ask the vendor to show how the system delivers it while meeting the required controls.

Physical security is likely to span local infrastructure and cloud services for some time. A good decision leaves the organisation with a system it can operate securely today and adapt when its sites, risks and responsibilities change.

Click here to watch the full interview.