Other Security Tickets the Desk Will See, and Who It Tells

One Wednesday at Acme, on a desk of four. At 08:10 reception hands Sam a USB stick someone found in the car park, "in case it's one of ours". At 09:30 a buyer forwards an alert from the mail service: "New sign-in from a location you don't usually use." At 11:00 a warehouse lead reports his access badge missing since Monday. At 13:15 the receptionist mentions, as an afterthought, that a man in a hi-vis vest "from the printer company" followed Dave through the side door. She assumed somebody had booked him. At 15:40 the finance clerk says a caller from "the bank's fraud team" asked her to read out the code that had just been sent to her phone. She did not, but she is shaken. At 16:30 a sales manager writes: "My sent items has emails I didn't send. Have I been hacked?"

None of those tickets says "phishing" and none of them is a broken laptop. A desk that only knows those two categories will file them as "other" and get to them on Friday. Each one is a security ticket. Each one has a first thing the desk does, a person the desk tells, and a line that the desk does not cross. Sam handles all six that day in a little over two hours, and five of them turn out to be nothing much. The sixth is the printer engineer.

A security ticket is any ticket where the first question is "could someone be getting in?" rather than "what is broken?". The desk's job on one is the same as on a phishing report: recognise it, do the first safe thing, tell the right person, and record what happened, without ever becoming the investigator. This article is part of our Phishing Reports & Security Tickets series. It covers the security tickets that are not about a suspicious e-mail. That is most of them once the organisation has learned that the desk is the place to say "this seems wrong".

It covers recognising a security ticket that does not announce itself and the odd sign-in alert. Then come the account doing things its owner did not do, and the found USB stick and the free gadget. Next come the lost badge, key or fob; the tailgater and the visitor nobody booked; and the suspicious phone call. After that comes the pattern they share, contain, tell and record. Last come a short war story and the security ticket routing table to copy.

Recognising a Security Ticket That Does Not Say So

Users do not say "I would like to report a security incident". They say "this is weird", "I didn't do that", "someone was in the building", "is this normal?", and "I probably shouldn't have, but". The triager's rule is a single question applied to every ticket at first touch: could this be someone getting in, to an account, a device, a building or a conversation? If the answer is "possibly", the ticket is a security ticket until shown otherwise, and it jumps the queue. A possible intruder is high impact by definition, because the desk does not yet know how far it reaches. That is enough to set the priority without a debate. The reasoning about impact and urgency is in Impact and Urgency in Practice. The short version for security tickets is that "we don't know yet" counts as high.

Give these tickets a category of their own, "security: other" beside "security: suspicious message". That way, they can be found and counted, and the pattern of them shows over a year. If you run QuerySolv, a department for security with its own form and mailbox puts them in one queue with service-level targets of their own. That is a cleaner answer than a priority flag on a general ticket. Any tool that can route by form or mailbox can do the same. What matters is that a found USB stick is not sitting behind a toner request.

The desk also needs, before any of these arrive, a short list of who it tells. The security function for anything involving an account or a device. Facilities, or whoever holds the door system, for badges and buildings. Finance for anything involving money or bank details. HR for anything involving a person's conduct or a leaver. The data-protection role, if the organisation has one, for anything involving personal data. Write the names and numbers on the routing table at the end of this article, and keep it where the desk can see it. Sam had the list. That is why six tickets took two hours rather than two days.

The Odd Sign-In Alert

Most mail and directory services send the account owner an alert when a sign-in happens from a device, place or app they have not used before. Users forward these to the desk with "is this me?". Sometimes it is. The services guess location from the network address. The guess is often a city away from the person, or a country away when they are on a mobile network, travelling, or connected through the organisation's VPN. Sometimes it is not them, and the alert is the earliest notice of a stolen password that nobody has reported. The desk cannot tell which from the alert alone, so it asks.

Ask three things: were you signing in at about that time, on a new device or app, or away from your usual place? A confident yes to any of them, with a plausible story, is usually the end of it, and the ticket closes with a line saying so. A no, or an unsure, means the desk treats it as a click. In that case, reset the password and have the account signed out everywhere. Check the mailbox rules and the recent sign-in history, and tell the security function. Do this in the order and with the care described in When Someone Clicked: The First Hour. The alert does not say how the password was obtained, and the desk does not need to know that to act.

Never tell a user to ignore sign-in alerts, even when the last three were false alarms. Never let the desk's own tone suggest that forwarding one is a nuisance. The person who stops forwarding them is the person whose real one goes unread. "Thanks for sending it, that one was you on your phone on the train, and please keep sending them" is thirty seconds of typing and keeps the channel open. The alerts are tedious. The alternative is quieter, and worse.

"My Account Is Doing Things I Didn't Do"

The sales manager's ticket, messages in the sent folder that he did not send, is the clearest security ticket the desk ever receives. It has siblings: rules in the mailbox he did not create, contacts asking why he sent them an invoice, and files shared from his account that he did not share. Other siblings are calendar invitations in his name and a password that no longer works although he did not change it. Each means that someone else has, or had, his sign-in. The desk treats all of them exactly as a confirmed click: reset, revoke, check, tell, in the first hour. The person's worry is "have I been hacked?" The honest answer is "something has used your account, we're ending that now, and the security team will check what it did".

Two things are the desk's and two are not. The desk contains the account and reassures the person; the desk records what the person saw, with times, and what it did. The desk does not work out how the sign-in was obtained. It does not decide who should be told about the messages the account sent, because that notice can have consequences the desk cannot see. Both of those belong to the security function. The handoff is the same as for a click: the facts with clock times, the examples of what the account did, and a phone call if that is faster than a ticket.

A good share of "have I been hacked?" tickets are not. Mail that has gone missing is usually in the junk folder or caught by a rule the person made themselves. A message that "looks like it came from me" is usually a sender using the person's display name on a different address. That is unpleasant but is not a sign-in. The desk can tell those apart in a few minutes, and the ordinary mailbox cases are covered in Missing Mail and the Junk Folder. The rule is to check the security reading first and the ordinary one second, because the cost of the two mistakes is unequal. A junk-folder problem treated as a compromise costs the person a password change. A compromise treated as a junk-folder problem costs the organisation the rest of the month.

The Found USB Stick and the Free Gadget

A USB stick found in the car park, the lobby, the meeting room or the post is never plugged into anything to find out whose it is. The rule needs saying to the whole organisation, because the instinct to be helpful is strong and "I'll just see if there's a name on it" is how it starts. A storage device can carry things that run the moment it is connected. The desk's machines are the worst possible place to find out. The desk's handling is physical. Put the stick in an envelope. Write the date, where it was found and who found it on the outside. Log a ticket and hand it to the security function. If nobody claims it, the security function decides what happens to it, and the desk does not need to know what was on it.

The same rule covers the free gadget: the branded charging cable, the "promotional" device, the unsolicited phone accessory that arrives in the post addressed to a senior person. Anything that plugs in and was not ordered by the organisation goes in the envelope, not the port. Say so in the knowledge base in one short article that everyone can read, with the one instruction and the one address. Expect to be thanked for it about once a year by someone who was holding a stick over a port when they remembered.

When the stick has already been plugged in, treat the device it was plugged into as the opened-attachment case. That means off the network, isolated, the security function told, a loan machine issued, no blame. The desk usually learns that the stick was plugged in from a slightly sheepish ticket. The person who tells you they plugged it in has done the useful thing, and the one who does not is the reason the rule exists.

The Lost Badge, Key or Fob

A lost badge is a lost password for a door, and the desk treats it with the same order of operations: disable first, replace second, ask questions third. Whoever holds the door system, which is usually facilities and sometimes the desk itself, disables the badge the moment the loss is reported. This happens before anybody discusses whether it might be in a coat pocket. A badge that turns up later is re-enabled in a minute. A badge that is used by someone else during the three days it took to be sure it was gone is a different kind of ticket.

The desk's questions come after the disable, and they are about what else was with it. A badge on a lanyard with a laptop in the same bag is a lost device as well. In that case, the device steps in Lost and Stolen Devices apply alongside the door steps. A badge with the person's name, photo and the organisation's logo is also a small piece of identity. The security function may want to know where it was lost. A badge that belonged to someone who has left the organisation is not a lost badge at all. It is an offboarding step that was missed. The ticket goes to the leaver process in Same-Day and Immediate Exits with a note that the door system was not on the checklist.

Keys and fobs follow the same logic with a worse replacement story, because a physical key cannot be disabled and a lock may need changing. The desk's part is to tell facilities the same hour and record what the key opened. The lost badge ticket is, in my experience, the one users apologise for most and the one that costs the desk least. Reassure them, disable it, and move on.

The Tailgater and the Visitor Nobody Booked

Tailgating is following an authorised person through a controlled door without using your own badge. A report of it is a now ticket, not an afternoon ticket, because the person is in the building now. The desk does not send a technician to find them. It phones facilities or security, or whoever is nearest the door system, immediately, with what the reporter saw. That means the time, the door, a description, who they followed and where they seemed to be going. Then the ticket is written. A tailgating report that goes into the queue to be triaged with the printers has already failed.

The visitor nobody booked is the same ticket in a better costume. It could be the engineer, the auditor, the courier, or the person from the lift company, who arrives with a clipboard and a reason and no appointment. The desk's standard is that a visitor the desk did not expect is confirmed with the supplier before they go anywhere unescorted. That confirmation uses a number the organisation already holds, never a number the visitor provides. A visitor who cannot be confirmed waits in reception with a coffee and a polite host. None of that is unfriendly, and nearly every genuine engineer is used to it. The one who objects is the one you wanted to check.

The desk's role in both is to be the place the report lands and the person who makes the phone call, not the person who confronts anyone. Reception staff need to know that "I think someone followed Dave in" is a call to the desk, that the desk will take it seriously, and that nobody will be told they overreacted. That last point is the same no-blame rule that keeps phishing reports coming, applied to doors. Reception at Acme mentioned the printer engineer as an afterthought because the previous time they had mentioned a visitor, somebody had sighed.

The Suspicious Phone Call

The call the finance clerk received, someone claiming to be the bank's fraud team asking her to read out a code, is a phishing message with a voice. It is reported to the desk because the desk is where people report things. The desk's handling is the same as for any report. Thank her and ask what was said and what she gave, which in her case was nothing. Tell finance and the security function, and record it. If anything was given, a code, a password, a card number, remote access to her computer, the first hour starts. In that case, the account is reset and revoked, the device is checked, and finance is told to watch for the transaction the code was meant to approve.

The desk's own standing rule, published where everyone can read it and repeated in the monthly note, is short. The desk will never phone you and ask for your password, your sign-in code, or remote access to your computer out of the blue, and neither will the bank. If anyone does, hang up and phone the desk on the number you already know. That rule protects the organisation against most of what a caller can attempt without the desk needing to describe any of it. It gives every person a script for the moment they are flustered: hang up, phone us. There is no need for the desk to teach what the callers say. Teach the one response.

The other direction matters too. A call to the desk asking for a reset, an unlock or access "for a colleague who is in a meeting" is verified by the same standard the desk uses for any reset. There is no exception for urgency, seniority or how friendly the caller is. That standard is set out in Verifying Identity Before a Reset. The desk should know that the callers who are not who they say they are have read the same article you have. The standard holds because it has no exceptions, and the day the desk makes one is the day it stops being a standard.

The Pattern: Contain, Tell, Record

Six tickets, six subjects, and one shape. First, contain: do the one safe thing that stops it getting worse. That is a disable, a reset and revoke, an envelope, an isolation, or a phone call to the door. Second, tell: the named person for that kind of ticket, within the hour, by phone when the building is involved. Third, record: the facts with clock times on the ticket, in the security category, linked to whatever record the security function keeps, with no judgement and no secrets. The three steps are the same for a lost fob as for a stolen sign-in; only the names change, and the names are on the routing table.

The first five minutes of any security ticket, then, are a fixed checklist, and the desk should be able to run it without thinking:

• Ask the one question: could this be someone getting in? If possibly, it is a security ticket now.
• Set the priority high and put it in the security category before doing anything else.
• Do the one containing action for that kind of ticket, from the routing table.
• Phone or message the named person for that kind of ticket, and say what has been done.
• Thank the reporter and tell them what happens next, without blame.
• Write the facts and the clock times on the ticket as an internal note. Put nothing in it you would not want the reporter to read.

A help desk is not a security tool, and most small-team help desks have no security module and no need for one. The ticket is a record and a route, and that is what these tickets need. What the desk adds is the thing no tool provides. It is a person who recognises that "this is weird" might be the most important message of the week and knows whom to phone. Everything beyond that, the examination of what was done, the decision about who else is told, the legal and regulatory steps, belongs to the security function. The desk's record is what they start from.

A Short War Story: The Printer Engineer at Hollins Dairy

At Hollins Dairy a man in a hi-vis vest with a toolbox and a lanyard arrived at reception one Tuesday "to service the printers". He was waved through by a receptionist named Carys who assumed the desk had booked him. He spent forty minutes walking the first floor while she dealt with a delivery. Carys mentioned him to the desk at three in the afternoon, as a question rather than a report. The technician who took the call logged it as low priority with a note to check whether anyone had booked a printer visit. Nobody had. Two laptops were missing from the sales office by the next morning, both of them signed in when they were taken. The clean-up involved resetting and revoking two accounts, a contracted security firm examining what the sign-ins could reach, and replacing the devices. It also involved a conversation with the dairy's largest customer about a shared price list. The clean-up came to something over seventy hours and a very quiet week in sales. The desk lead's note in the review was that the desk had treated a person in the building as a question for later. The note also said that a tailgater report is a now ticket, every time, whatever it sounds like.

The Security Ticket Routing Table

The table below is the template. It has one row per kind of ticket the desk will see, with the first containing action, who is told and how fast, and the priority. Each row also lists the one thing the desk never does. Copy it and fill in the names and phone numbers for your organisation in the "who" column. Keep it where the desk can see it from the phone. It is deliberately a table and not a procedure, because at the moment it is needed the technician has a worried person on the line and wants one row, not a page.

Sam's Wednesday ended with the USB stick in an envelope on the IT manager's desk. The sign-in alert was confirmed as the buyer at a trade show. The badge was disabled at 11:04 and found in a van on Thursday. The finance clerk was thanked and the bank's real fraud line told. The sales manager's account was reset and revoked with a rule removed from it. The printer engineer was handed to facilities at 13:20 and, as it turned out, found in the second-floor kitchen. He was a real engineer whose appointment had been booked by the finance director without telling anyone. Five of six were nothing much. The desk did not know that at the start, and treated all six as if they were the sixth, which is the only way the pattern works.

Frequently Asked Questions