Somewhere in the last fifteen years, your access control system, your cameras, and possibly your visitor management moved onto the corporate network. When that happened, ownership of those systems drifted to the people who own the network, and in many mid-sized organizations physical security is now run out of the IT department. If that is true where you work, the IT team did not ask for it and is probably handling it better than anyone had a right to expect. The problem with letting IT own physical security is a structural one, and it has less to do with the people involved than with what the assignment quietly leaves out.
I say this with real respect for IT leaders. They manage more risk, more change, and more vendors than almost anyone else in the building, and they have absorbed physical security systems the same way they absorbed everything else that plugs into a switch. What they were never given is the mandate, the training, or the time to lead a security program, and what they are measured on has very little to do with whether the lobby officer checks credentials or whether a terminated employee’s badge still opens the side door. The systems are administered. The program is not led. Leadership rarely notices the difference until it matters.
How Physical Security Became an IT Asset
The migration was driven by the technology itself. Card readers became network devices. Cameras became IP endpoints with storage on a server. Alarm panels started reporting over the internet. Each of these needed an IP address, a place on the network, a patch schedule, and someone to call when it stopped responding, and all of that is IT work. Vendors began selling directly to IT because IT controlled the infrastructure, and the procurement process followed. Within a few years the organization’s physical security systems appeared on the IT asset list and nowhere else.
Once the systems were IT assets, the people responsible for them were IT people, and the natural questions became IT questions. Is it patched, is it backed up, is it on a supported version, does it integrate with the directory. Those are good questions and they need to be asked. They are also entirely about whether the system is healthy, and say nothing about whether the system is doing the job it was bought for.
What the IT Frame Leaves Out
IT security and physical security share a vocabulary and very little else. An IT team thinks in terms of accounts, permissions, and logs, and it is very good at those things. Physical security thinks in terms of people, spaces, and the moments when someone decides to do something they should not. The access control system sits between the two, and the IT frame handles the account side of it well while missing the rest. Credentials are issued when HR sends a ticket and are often left active when the ticket to remove them never arrives. Door schedules are set at installation and rarely revisited. The question of whether the wrong person can follow the right person through a door is never asked, because it is not a system question.
Cameras illustrate the gap even more clearly. IT ensures the recorder has storage and the streams are up. No one is asking whether the views cover the places where the organization’s actual exposure lives, whether anyone reviews footage before an incident, or whether the retention period matches what an investigation would need. The guard force, if there is one, usually sits entirely outside IT’s world, and so the people who watch the building and the systems that watch the building are managed by different departments that seldom speak. The threats that matter most, which come from people rather than devices, have no owner at all.
The Incentive Problem
IT leaders are measured on availability, cost, ticket resolution, and increasingly on cyber risk. None of those measures rewards walking the building at night, pulling on doors, or holding a guard vendor to its contract. When a physical security task competes for attention with a network outage or a phishing campaign, it loses every time, and it should, because that is what the IT leader is accountable for. The result is a physical security program that receives attention only when a device breaks, and a set of risks that no one is scored on and therefore no one pursues.
There is also a quieter effect on how leadership hears about security. When the board asks whether the organization is protected, the answer comes from the IT leader and tends to be about systems: everything is patched, everything is monitored, everything is on a supported version. That is a true answer to a different question. The board wanted to know whether a terminated employee could get back into the building, and no one in the room was in a position to say.
What It Looks Like When It Fails
The failures follow a recognizable pattern. An access audit, if one is ever performed, turns up credentials belonging to contractors whose projects ended long ago and employees who have transferred or left. A camera that has been online and healthy for years turns out to have been pointed at a wall since a renovation. A concerning comment from a departing employee is reported to a manager who does not know where to take it, because the nearest thing to a security function is a help desk. The incident response plan covers a ransomware event in detail and says nothing about a violent person in the lobby. In every case the systems were working. The program was absent.
How to Fix It Without Taking Anything Away From IT
IT should keep the infrastructure. The readers, recorders, and panels belong on the network, patched and supported by the people who know how to do that. What the organization needs to add is a security leader who owns the program those systems serve. That person decides who should hold credentials and how often the list is reviewed, sets the camera coverage against the organization’s real risks, manages the guard vendor against the contract, builds the protocol for threats that come from people, and briefs leadership in the language of risk rather than uptime. For most mid-sized organizations this role fits comfortably in a fractional engagement, and a good fractional director will treat the IT leader as a partner rather than a rival, because the two functions need each other.
You can start before that person is in place. Ask IT for the full list of active physical credentials and have HR compare it against the current roster; the difference is your first finding. Ask who is notified when a door is forced or held open after hours and whether that person knows what to do. Have someone walk the camera views against a floor plan and mark the places where the organization’s exposure is not covered. Ask whether the incident plan addresses a person rather than a device. Then, once the leader is in place, test everything instead of assuming it works. That is the principle behind Until Tested: Security Is Only Assumed, and it is the fastest way to learn what a healthy network has been quietly hiding.
Go Deeper
Putting a leader over the program while IT keeps the infrastructure is exactly the arrangement the fractional model is built for, and I describe it in What Is a Fractional Security Director? The Complete Guide. My book Fractional Security Director covers how a part-time executive director works with IT, facilities, and HR to close the gap that most mid-sized organizations do not know they have.
Commissioner William Epps is a former elected Fire Commissioner, federal law-enforcement supervisor, and firefighter since 2006, with instructor credentials in Hazardous Materials response, Active Shooter preparedness, and Stop the Bleed®. He spent seven years in federal law enforcement in physical security, executive protection, and incident command, and now serves organizations as a Fractional Security Director. He is the author of The Spirit of Saul, The Spirit of Pharaoh, and other practical books on security, leadership, and faith, built around one idea: knowledge should be practical enough to use when it matters.
Leave a Reply