What happened: You denied access. The man left without incident. But you didn't call Grant & Associates to verify whether the visit was legitimate, you didn't document the individual's description, and you didn't alert IT Security or building management to the attempted access. There was no record of the incident.
Three days later, the same individual returned — this time at the building's loading dock. He told the loading dock supervisor he was a server maintenance technician delivering a firmware update. Because the first incident wasn't in the system, the loading dock team had no context. The supervisor gave him temporary access to the service corridor adjacent to the server room.
Denial without documentation and escalation leaves the threat free to try again through a different vector.
// WHAT WENT WRONG
• Denial was correct — but it was the beginning of the response, not the end
• No verification: you don't know if this was a real Grant & Associates visit that went wrong or an attack
• No documentation: no description of the individual, no timestamp, no record of the scenario presented
• No escalation: IT Security and building management had no information to act on
• Result: the same individual tried again with a different pretext and succeeded through a different entry point
The complete protocol is: stop → verify → escalate → document. Denial without the other three steps leaves a partial response. The attacker now knows your front-entrance protocol and will try again through a different vector.