What Happens After the Vendor Leaves
Most security engagements end when installation ends. The vendor completes the work, hands over documentation, and moves on to the next project. What happens after that — when the system is live, the warranty period is running out, and leadership is starting to notice things that don’t work the way they were described — rarely gets planned for.
This is one of the most common situations G.I.S. is called into. Not during planning. Not during installation. After.
A hotel that upgraded its camera and access control infrastructure eighteen months ago now has a general manager who can’t get clear answers from the integrator about why three entry points aren’t functioning as specified. A multifamily property with a new key fob system that was supposed to eliminate unauthorized access but hasn’t changed the pattern at all. A school district that completed a perimeter security project and is now being asked by its board whether what was installed actually meets the protocols it was supposed to support. A commercial office building whose tenants have been reporting lobby access issues since a system upgrade, and whose property manager has no independent way to assess whether the problem is the system or the configuration.
Post-implementation independent security assessment is different from pre-decision advisory work. The window for changing direction has narrowed. But the findings still matter — and in many cases, what gets found is still actionable.
What G.I.S. typically finds in post-implementation review falls into four categories. Performance gaps between specification and reality — what the vendor proposed and what was installed don’t always match. Vendor dependency that wasn’t disclosed upfront — proprietary systems, ongoing licensing requirements, hardware that locks the organization into a single service provider. Operational gaps the system was never going to address — the specification missed what the environment actually required, and no amount of post-installation service fixes a design problem. And documentation that doesn’t reflect actual conditions — system maps and coverage diagrams accurate at installation but not maintained as the building’s use evolved, which for healthcare facilities, schools, and government properties has liability implications that go beyond operational inconvenience.
A post-implementation review doesn’t undo what was installed. But it gives leadership an honest picture of what they actually have, what can be addressed through reconfiguration or supplemental work, what requires a longer-term plan, and what will need to be replaced at the next appropriate decision point.
That picture is worth having — whether or not it’s what anyone wanted to find.