Physical Security Information Management: When the Badge Alarm and Its Video Live in Two Different Systems

Why a global security console can be blind at 3am

An operator in a security operations centre sees a forced door alarm at a site in another region. He needs three things immediately: who badged in that area in the last ten minutes, the video covering that door, and the procedure for this alarm at this site. What he actually has is a console showing the alarm text and a phone number for the local facilities manager. The site was acquired four years ago, it runs an access control platform nobody at head office has credentials for, and its video sits on a recorder behind a site firewall that the network team locked down after a security review. He calls the local team.

That is the normal condition in large estates. The corporate standard exists on paper, and the estate is a museum of every vendor and firmware generation acquired over two decades. Head office standardised in 2019, which means the fifteen sites bought since then are standardised and the other seventy are not. Meanwhile the operating model assumes one operating picture, because that is what the security function was funded to deliver.

The consequence is not usually a dramatic breach. It is response time and evidence quality. An incident gets handled in twenty five minutes instead of four because the console could not answer basic questions, and afterwards the investigation packet has to be assembled by hand from three systems by people who have to be woken up. In the security integration work we have delivered, the metric that moves first is time to first useful evidence, and it moves a long way.

Problem 1: every acquired site speaks a different dialect

Access control and video are mature markets with genuine standards, and the standards only take you part of the way. ONVIF gives you a common approach to many video devices, but profile support varies by device and generation, and the recorder's own interface still holds the recorded footage and its bookmarking. On the access side, older readers on Wiegand and newer ones on OSDP behave differently, and the head end platforms expose events through SDKs, database connections, or in some cases nothing you are allowed to use without a licence.

Then there is the estate reality. Servers on site rather than centrally. Firmware several versions behind because upgrading means a maintenance window in an operating facility. Sites where the integrator who installed the system is out of business and nobody has the admin password.

What a custom build does: a connector per system and generation that normalises events into one internal model, with the connector deployed close to the site rather than assuming central access, and with an explicit contract about what it may do. Read only is the right default. A central console that can unlock doors across an estate is a much larger risk conversation than one that observes and escalates, and starting read only usually gets you through security review months earlier.

Problem 2: correlation is the actual product, and identity is the hard part

A PSIM is worth having only if it can answer questions that span systems. Show me everyone in this zone right now. Show me this person's movements across all sites in the last hour. Show me the video for this badge event without knowing which recorder owns the camera.

Every one of those questions breaks on identity. One employee exists as five different records with five different 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 has ever reconciled those, because inside each site the local record was sufficient.

What a custom build does: an identity resolution layer that maps person records across systems to a single subject, sourced where possible from your directory or joiners and leavers process rather than from the access systems themselves. Then a card, a badge event, a camera, a door, and a floor plan position all attach to a common model, and correlation becomes a query rather than a phone call. This is also the layer that lets you answer the audit question nobody enjoys: which credentials does this departed contractor still hold, across all systems.

Camera to door mapping deserves its own attention. In most estates it lives in a drawing. Making it explicit data is what turns a badge event into an evidence packet automatically.

Problem 3: what Genetec, Qognify Situator and Vidsys actually do

Genetec Security Center is a strong unified platform and if you can standardise your estate on it, that is often the right answer and cheaper than integrating around it. The honest limitation is what it is optimised for: it is at its best as the system of record for access and video, so the more of your estate you migrate to it, the better it gets. If your reality is seventy sites on other vendors that you are not going to replace, you are asking a platform to be an integration layer for its competitors, and depth varies by which competitor.

Qognify Situator and Vidsys are genuine PSIM products with real strength in situation management and response procedures, which is exactly the part most homegrown attempts underestimate. The practical considerations are deployment weight and change cost: integration modules are built and licensed per device type and firmware generation, professional services cycles are long, and adding a newly acquired site with an unusual system is a vendor engagement rather than an internal task. Vendor consolidation in this market has also been active, so ask directly about roadmap and support commitments for the specific modules your estate depends on before you commit.

The honest decision rule: if your estate can be standardised, standardise. If it genuinely cannot, then you are choosing between a PSIM product where each new site is a vendor project and a build where each new site is your own connector. That choice comes down to how often your estate changes and whether you have or can hire the engineering capability.

Problem 4: response procedures are policy, and generic workflow does not encode policy

The value of a situation management layer is that an operator at 3am is guided rather than improvising. What guidance means is specific: for this alarm type, at this site, during these hours, do these steps in this order, notify these people, log these decisions, and escalate if step three is not complete in six minutes.

That content is your security policy, and it differs by site, by jurisdiction, by tenancy agreement, and by whether the site is manned. It is also revised after every incident review. If changing a procedure requires a vendor ticket, the procedures will go stale and operators will revert to a laminated card.

What a custom build does: procedures as versioned, editable data owned by your security operations team, with each step recorded as it is completed, including who did it and when. Two benefits follow. Operators get consistent handling, and the post incident review has a real timeline instead of recollections. That timeline is also what defends the organisation when the handling of an incident is questioned.

Problem 5: connecting everything centrally is itself a risk you must design for

The moment you build a console that reaches every security system in the estate, you have created a target and a data protection obligation. Movement data about identified people is personal data in most jurisdictions, video adds more, and any use of biometrics brings its own rules that vary significantly by country and by state, so this is a question for your privacy counsel rather than your integrator.

What a good build does: segmented connectors with least privilege credentials, read only by default and any control capability separately approved and separately audited, retention rules per data type and per jurisdiction enforced by the system rather than by policy documents, and an audit log of operator access to footage and movement history. Your own security engineering team will ask for this. It is far better to design it in than to be sent back after a review, which typically costs a quarter.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape. A focused 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 and ships in 16 to 24 weeks. A full platform adding identity resolution across systems, mapping and situational display, mass notification, additional connectors, guard tour and patrol, visitor integration, and audit and reporting runs $300,000 to $800,000 phased over 10 to 18 months.

What drives price up specifically here: the number of distinct system types and firmware generations, since each connector is a discrete piece of work and the awkward ones are legacy platforms with poor or undocumented interfaces. Whether vendors will licence you interface access at all, which is a commercial negotiation that can outlast the engineering. Network and security review cycles in a large organisation, which are real months. Any control capability beyond read only. Video specifically, because live streaming and recorded retrieval across mixed recorders is materially harder than event ingestion. And geographic spread, which brings data residency and retention differences.

What keeps price down: starting with the two systems that cover most of your alarm volume, read only, and one region, then proving the response time improvement before extending the estate.

Build versus buy, and when buying is right

Buy, and standardise, if your estate is small enough or homogeneous enough that migrating to a single unified platform is realistic within a couple of budget cycles. One vendor doing access and video well beats an integration layer over a mess, every time, if you can actually get there.

Buy a PSIM product if your estate is mixed but stable, you have a modest number of system types, and your security team would rather manage a vendor than an engineering backlog. That is a legitimate and common answer.

Build when the estate changes faster than a vendor engagement cycle, which is the case for any organisation acquiring sites regularly. Build when your operating picture has to include systems no PSIM covers, such as internal case management, HR (Human Resources) joiners and leavers, travel security, or building systems. Build when you have been quoted per site integration fees that make the total look absurd across a large estate. And build when the procedures encode policy that changes after every incident review, because that content has to be yours to edit.

How to choose a developer for PSIM and security integration

Ask how they would resolve one person appearing as five records across five access systems. If they do not immediately reach for the directory or the joiners and leavers process as the authority, the correlation will never be trustworthy and every query you care about depends on it.

Ask what they have actually integrated, by vendor and by generation. Reading events from a current version platform with a documented interface is routine. Getting reliable events from a decade old head end at a site with no vendor support is the work, and it is where the schedule risk sits.

Ask how they will pass your security engineering review. The right answer starts with least privilege, segmentation, read only defaults, credential handling, and an audit log of operator access to footage. If security review comes up as an afterthought, expect the project to lose a quarter to it.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the cloud and on premise infrastructure, and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit, and in a security context you should be able to have any part of the system independently reviewed without asking a supplier's permission.