Access control and video moved onto the corporate network years ago. Responsibility for them mostly did not move with it.
The result is a category of outage that neither team can prevent alone. A segmentation project takes controllers offline. A patching cycle reboots a recording server mid-week. A directory cleanup disables a service account that turns out to run the badging system. None of these were careless. They were routine changes to systems that were, from the IT side, ordinary servers and ordinary endpoints, and nobody in the room knew otherwise.
What follows is what actually reduces this, drawn from what the outages have in common rather than from an organizational chart.
The two teams are optimizing for different failures
IT is measured on confidentiality, patch currency and uptime. An unpatched server on the network is a live risk that has to be closed, and a device that cannot be identified is a device that should not be trusted. Those instincts are correct.
The security team is measured on whether doors work and whether footage exists. A patch applied at the wrong moment is not a small risk to them, because a controller that reboots during a shift change is an operational incident, and a recording server that restarts is footage that does not exist.
Neither position is wrong and the disagreement is rarely about the substance. It is about vocabulary and about timing. Both teams want the system available and secure. What is missing is usually a shared list of what exists, an agreement on who decides what, and a window in which changes happen.
Deciding who owns what, explicitly
The point is not the specific allocation, which varies by organization. The point is that every row has one name against it.
| Typically owned by | Where it goes wrong | |
|---|---|---|
| Server hardware and OS | IT | Patching and reboots applied on the standard cycle with no security-side window |
| Security application software | Security, with IT support | Application updates deferred indefinitely, leaving the OS unsupportable |
| Application patching decision | Joint | Each team assumes the other is tracking version compatibility |
| Network segment and firewall rules | IT | Rule changes that block controller ports, discovered days later |
| Device addressing | IT | Reservations removed in a DHCP cleanup; static addresses that collide with a new scope |
| Switch ports serving security devices | IT | Port security or 802.1X shutting a port after a board replacement changes the MAC |
| Time synchronization | IT | Drift between servers, controllers and cameras that makes correlation unreliable |
| Certificates | IT | Expiry on a date nobody diarised, presenting as devices connecting then dropping |
| Service accounts | IT | Password expiry policy applied to accounts that run services, failing at expiry |
| Cardholder and operator accounts | Security | Leavers removed from the directory but not from the access system |
| Backups of the security database | Joint | Each team believes the other has it; nobody has restored one |
| Storage and array health | IT | Alerts routed to a mailbox that the security team does not read and IT does not connect to video |
| Camera and controller firmware | Security | Left at shipped versions indefinitely, then upgraded all at once under pressure |
A row with two owners is an unowned row. Where the work genuinely spans both, name a single accountable owner and a contributor.
Four things that fix most of it
One shared inventory
Every security device that touches the network, in the same asset register IT already uses.
- Controllers, servers, workstations, cameras, intercoms, encoders and anything else with an address.
- Each with an owner, a criticality, a change window and a contact.
- Tagged so that a device appearing in a network tool is recognizable as security infrastructure rather than an unknown endpoint.
- Reconciled at least annually, because the register drifts as fast as the drawings do.
Security systems on the change calendar
Both directions. Network changes visible to security, security changes visible to IT.
- Any change to segmentation, addressing, switch configuration or certificates flags the security devices affected.
- Any firmware or application change on the security side goes through the same change process as anything else.
- Agreed maintenance windows that account for shift changes and operational peaks, not just for low network utilization.
- A standing exclusion for automatic reboots on recording and directory servers, with a defined alternative.
A joint runbook for the common faults
Written before the outage, naming who checks what first.
- Controller offline: who checks the switch port and the address, who checks power and the enclosure, and in what order.
- Camera not recording: who confirms the stream reaches the server and who confirms the server is writing.
- Server unavailable: who has console access out of hours and who is authorized to restart a service.
- An escalation path with a second name on it, and the point at which an external specialist is called.
Alerts with owners
Every alert has a named recipient and a defined action, or it should not exist.
- Hardware alerts from servers and storage routed to a monitored destination, not to a legacy distribution list.
- Security application alerts visible to IT where the cause is likely to be infrastructure.
- Alert routing tested by causing the condition rather than by reading the configuration.
- A quarterly review that deletes alerts nobody acts on, because volume is what makes the important ones invisible.
Two arguments worth having early
The first is the unsupported operating system. A security application that only runs on an OS past end of support is a problem that gets worse on a fixed schedule, and the resolution is an application upgrade, not an exception in the risk register renewed each year. Raising it while there is budget runway is a far better conversation than raising it after a security review mandates removal. The preparation involved is set out in preparing for a Genetec or C•CURE upgrade.
The second is least privilege applied to service accounts. The correct answer is not a broadly privileged account left alone because restricting it once broke something. It is establishing what each service actually requires, granting that, documenting it, and exempting those accounts from interactive password expiry through a managed mechanism rather than by disabling the policy. This takes a day and removes a recurring outage.
Where offline events are the presenting symptom, the diagnostic sequence is in common causes of offline access-control panels. Where the server layer is the concern, see why security servers and storage should be monitored.
Start with the inventory
If only one thing gets done, make it the shared device inventory. Almost every failure above is a consequence of somebody making a reasonable change to a device whose role they could not see. An accurate, jointly maintained list removes more incidents per hour of effort than anything else available, and it is the prerequisite for the change calendar, the runbook and the alert routing.
It is also the artefact that survives staff turnover on both sides, which is ultimately the problem being solved.
Get both teams looking at the same system
Device inventory, ownership mapping and a joint fault runbook, produced as documents you keep.