You are paying for security. The guard contract renews every year, the access control system was upgraded not long ago, and the alarm monitoring invoice arrives every month. What you are almost certainly not paying for is anyone to confirm that these things work. That is not a criticism of you or your team. It is the normal condition of most organizations I have walked into, and it is the reason I have spent much of my career repeating one sentence to executives: security should be tested, not assumed.
This article explains what that sentence means in practice and describes the thinking behind the P.R.O.O.F. framework, which I laid out in Until Tested: Security Is Only Assumed. The framework is a structured way of verifying that a security program does what it is supposed to do, using tests rather than confidence. You do not need a security background to understand it, and you do not need one to run the first tests yourself.
What It Means That Security Is Only Assumed
Every element of a security program carries an assumption. The door is assumed to lock when it closes. The officer is assumed to check credentials rather than nod at a familiar face. The alarm is assumed to reach someone who will act on it. The access list is assumed to contain only current people. The emergency plan is assumed to work because it is written down. Until each of those has been checked, the program is a collection of beliefs, and the organization’s actual protection is whatever those beliefs happen to be worth on the day something goes wrong.
What makes this dangerous is that assumptions are invisible from the executive suite. The equipment is there, the invoices are paid, and no incident has occurred, so the program appears to be working. In my experience the gap between what leadership believes and what is true on the ground is the single largest risk in most mid-sized organizations, larger than any specific threat. Testing is how you close that gap.
Security Should Be Tested, Not Assumed: The Doctrine Behind P.R.O.O.F.
The P.R.O.O.F. framework grew out of a simple observation from years in law enforcement, fire service, private security, and federal work. Nearly every failure I investigated or responded to had been discoverable in advance by someone willing to check. The alarm that did not dispatch had a call list nobody had reviewed. The door that let the intruder in had not latched properly for months. The plan that fell apart under pressure had never been rehearsed. In each case a short, inexpensive test would have exposed the problem while it was still cheap to fix.
The framework organizes that lesson into a discipline. Rather than asking whether the organization has security, it asks whether each part of the program has been verified, how recently, by whom, and with what result. It treats a control that has not been tested as a control whose status is unknown, and it treats an unknown as a gap until proven otherwise. The full method is in the book, and I will not reduce it to a slogan here. What I can give you is the set of tests it begins with, because they are the ones that find the most.
The Tests That Find the Most
Pull the doors. After hours, walk every exterior door and every interior door that is supposed to be controlled, and pull on each one. You are looking for doors that are propped, doors that close without latching, and doors that open for a credential that should not work there. Do this without announcing it to the guard vendor or the facilities team, because an announced test measures preparation rather than reality.
Watch the guard post at shift change. Stand where you can see the post for the fifteen minutes on either side of the handoff. Note whether the post is ever unattended, whether the incoming officer receives any briefing, and whether people walking past are checked or waved through. Then compare what you saw to the post orders in the contract. The difference between the two is the difference between what you pay for and what you receive.
Call the alarm company. Ask them to read your account’s call list back to you, name by name and number by number. Ask what happens when nobody on the list answers. Then arrange a test and trigger the alarm at an agreed time, and see who actually gets the call. I have never done this exercise at an organization that had not reviewed the list in more than a year and found it accurate.
Audit the access list. Export every active credential from the access control system and compare it against current employees and active contractors. Anyone on the first list and not the second is a person who can still open your doors. Look also at who has access to sensitive spaces and whether their current role justifies it.
Run the incident plan as a tabletop. Gather the people who would have to act during a serious event, give them a realistic scenario, and walk through it step by step. The plan will look fine on paper and then break at a specific point, usually a decision nobody is authorized to make or a person who is not reachable. That breaking point is the finding.
What to Do With the Results
Record every finding in plain language that a board member could read, and rank each one by how much harm it enables and how easy it would be to exploit. Assign an owner and a date. Some fixes are free, such as removing stale credentials or correcting a call list. Some are small, such as repairing a door closer or rewriting a post order. A few will require a budget decision, and those should go to leadership with the test result attached, because a finding backed by evidence gets funded and a general concern does not.
Then put the tests on a calendar. Testing once tells you the state of the program on one day. Testing on a schedule, with results tracked over time, tells you whether the program is improving or drifting, and it gives the vendors and staff who run it a reason to keep it right. A program that knows it will be tested behaves differently from one that assumes it never will be.
Who Should Own the Testing
Somebody has to own this, and it should be someone with both security experience and enough standing to act on what the tests reveal. The facilities manager can pull doors but cannot renegotiate the guard contract. The guard vendor can watch its own post but has no incentive to report its own gaps. In most mid-sized organizations there is no one whose job this is, which is why the tests are not being run. A part-time executive security director, working a few days a month, can own the testing cycle, interpret the results, and carry them to leadership in the language leadership uses. That is the model I built my practice around, and it is the practical way to make testing a habit rather than a one-time project.
Go Deeper
For an explanation of how a part-time security executive fits a mid-sized organization and what the role owns, start with What Is a Fractional Security Director? The Complete Guide. My book Fractional Security Director describes how that role builds and sustains the testing discipline this article describes.
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