Physical Security Information Management Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does connector scope on a PSIM project blow out so often?

The business case is written in terms of sites. Eighty locations, one operating picture, one console. That framing is where the money goes wrong, because cost in this category has almost nothing to do with the number of sites and almost everything to do with the number of distinct system types and firmware generations behind them.

Fifteen sites bought since the corporate standard was set are genuinely easy. The other sixty five are a museum of every vendor and generation acquired over two decades. Some expose events through a documented interface. Some require a database connection nobody has ever authorised. Some run a head end whose vendor now wants a licence conversation before you may read your own events, which is a commercial negotiation that can outlast the engineering work beside it.

This is specific to physical security because the equipment is capitalised on a twenty year cycle and lives inside operating facilities. Upgrading firmware means a maintenance window in a building that does not want one. Nobody replaces a working access control panel because a head office console would prefer a newer interface.

The fix is a survey before a scope. Spend three or four weeks confirming, per site, which head end and firmware version is running, whether a documented interface exists, who holds the credentials, and whether the vendor will licence access. Price connectors from that survey rather than from a site count. Then start with the two access systems and two video platforms covering most of your alarm volume, prove the response time improvement, and extend from evidence.

What goes wrong with identity and camera to door data?

Two data problems decide whether a security console can answer questions worth asking, and both are usually discovered late.

The first is identity. One employee exists as five records with five card numbers in five access systems, plus a record in the identity provider, plus a contractor entry with a different spelling of their name. Nobody reconciled them because inside each site the local record was sufficient. Every question you actually want to ask breaks on this. Show me everyone in this zone now. Show me this person's movements across all sites in the last hour. Which credentials does this departed contractor still hold. A console that cannot answer those is an alarm viewer with a nicer layout.

The second is the relationship between doors and cameras. In most estates it lives in a drawing, or in the memory of a technician who covers three regions. Without it as maintained data, a badge alarm cannot produce its own video and the operator stays on the phone.

The fix for identity is to source it from your directory or your joiners and leavers process rather than from the access systems, each of which believes its own record is authoritative. Build the resolution layer early, because everything downstream depends on it and retrofitting it means reprocessing history. The fix for camera to door mapping is less glamorous: a data capture exercise with the local teams, and a rule that any new camera or reader commissioned anywhere in the estate must record its relationship before the work order closes. Without that rule the mapping decays within a year.

Why do access control and video integrations break after launch?

Connectors in this category do not fail loudly. They fail quietly, and the console keeps showing a clean board.

The failures are predictable. A site upgrades its head end during a refurbishment and the event schema shifts, so one category of alarm stops arriving while everything else continues. Service account credentials expire under a rotation policy nobody told the security team about. A recorder replaced under warranty carries a different retention setting, so footage from last month is already gone. A segmentation project silently blocks a connector at a site nobody remembers.

All of those are worse in security than in most domains because the absence of an event looks exactly like a quiet night. Nobody phones to complain that no alarms came in.

What to require: heartbeat monitoring on every connector with an alert when a source that normally produces events falls silent for longer than its own baseline, not a fixed threshold, since a warehouse and a headquarters have very different overnight patterns. Version detection on each head end so a firmware change raises a flag. Retention checks against each recorder so the console knows how far back footage is actually retrievable rather than assuming a policy. And a named owner for the connector estate, because in a large organisation infrastructure changes are announced to distribution lists the security operations team is not on.

What happens when security review, privacy and retention are not covered?

The gap that most often costs a quarter is not technical debt. It is the review you did not plan for.

A console reaching every security system in the estate is a target and a data protection obligation at the same time. Movement data about identified people is personal data in most jurisdictions, video adds to it, and any use of biometrics carries rules that vary significantly by country and by state. Teams that treat this as a compliance step after the build get sent back to change the architecture, because retention and residency rules determine where data is stored, and that is not a late configuration change.

The other half is your own security engineering function, which will ask about least privilege, credential handling, segmentation, and audit logging of which operator viewed which footage. Those are reasonable questions with expensive answers if the design assumed a single service account with broad rights across the estate.

Bring privacy counsel and security engineering into the design phase. Default every connector to read only, and treat any control capability such as remote door release as separately scoped, approved and audited. Read only observation and escalation delivers most of the operational value and passes review far faster, usually a difference measured in months. Enforce retention per data type and per jurisdiction in the system rather than in a policy document, and log operator access to footage from the first release, since that log defends the programme when someone asks whether the console was misused.

Should you build custom or configure what you already own?

A significant share of organisations reading this should standardise rather than build, and the test is whether migration is realistic within a couple of budget cycles.

Genetec Security Center is a strong unified platform for access control and video, and if you can move your estate onto it, that is usually better and cheaper than integrating around it. It is optimised as the system of record rather than as an integration layer for competitors, so its value rises with the share of your estate running on it. One vendor doing access and video well beats an integration layer over a mess, if you can get there.

Qognify Situator and Vidsys are genuine products with real strength in situation management and response procedures, which is the part homegrown attempts most often underestimate. If your estate is mixed but stable, you have a modest number of system types, and your team would rather manage a vendor than an engineering backlog, buying is a legitimate answer. Ask two questions before you commit: what a newly acquired site with an unfamiliar platform costs to add and how long it takes, and who can edit a response procedure, your team or the vendor.

Build when the estate changes faster than a vendor engagement cycle, which is true of any organisation acquiring sites regularly. Build when your operating picture has to include systems no product covers, such as case management, joiners and leavers, travel security or building systems. Build when per site integration fees make the estate wide total look absurd. And build when procedures encode policy that gets revised after every incident review, because that content has to be yours to edit.

How do hidden costs get into the quote?

The items below are where security integration quotes lose contact with reality.

• System types, not sites. Each distinct head end and firmware generation is a discrete connector. A quote priced per site is not a quote.
• Vendor interface licensing. Whether a vendor will grant you access to their events is a commercial negotiation, and it can take longer than building the connector.
• Network and security review cycles. In a large organisation these are real months, and they belong on the plan as a workstream with an owner.
• Video specifically. Live streaming and recorded retrieval across mixed recorders is materially harder than event ingestion and is often quoted as though it were the same thing.
• Any control capability. Remote door release changes the risk conversation, the approval path and the audit requirement all at once.
• Geographic spread, which brings residency and retention differences that shape where components are deployed.

In Digital Heroes delivery experience, a first release covering connectors for two access control systems and two video platforms, event normalisation, a correlated alarm queue with camera to door mapping and one response procedure runs $120,000 to $260,000 over 16 to 24 weeks. A full platform adding identity resolution, mapping, mass notification, further connectors, guard tour and audit reporting runs $300,000 to $800,000 over 10 to 18 months.

What separates a build that works from one that fails here?

Four habits distinguish the programmes that deliver.

They treat access to systems as a workstream, not an assumption. From week one, someone owns the list of vendor conversations, credential recoveries and network approvals, and reports on it weekly. Every stalled PSIM programme we have seen had those items sitting in a risk register with no name against them.

They build identity resolution before they build the console. Correlation is the product, correlation depends on knowing that five records are one person, and a console shipped without it teaches operators that the answers are not there.

They hold response procedures as versioned data owned by the security operations team, with each step recorded as it is completed and by whom. Procedures change after every incident review. If a change needs a vendor ticket or a software release, operators go back to the laminated card and the situation management layer becomes decoration.

And they measure the thing the business case promised. Time to first useful evidence, from alarm to the operator having the video and the badge history in front of them, is the number that moves first and moves most. Baseline it before the build, publish it monthly afterwards, and the case for extending across the rest of the estate makes itself.