Working With the Security Function, or Being It

Tuesday, 11:15, at Acme, in a meeting room with no window. Lena runs the desk of four. Tom is "security", which at Acme means one person who also does compliance, the insurance questionnaire and, on alternate Fridays, the firewall. Tom asks, carefully, why nobody told him about last week's lockouts. Lena says they put it in the tickets. Tom says he does not read the tickets. Lena asks what he does read, and there is a pause. Both of them realise that neither has ever been told what the other does all day. Each had assumed the other was watching.

Nothing had gone wrong at Acme yet. The lockouts had been a contractor who had typed an old password into three systems, and the whole thing was a Tuesday. But the pause in that meeting was the real finding. Two teams, both competent, had the only two views in the building that mattered for spotting an incident. They had no agreement about how one view reached the other. Lena and Tom wrote one that afternoon. It was a page long, and it is at the end of this article.

The security function is whoever is responsible for deciding what the organisation does about a security event. In a large organisation, it is a team. In a mid-sized one, it is a person with two hats or a contractor on a retainer. In a small one, it is nobody at all, which means the desk does the basics and says so. A working agreement is the one page that says who does what between the desk and that function, how the handoff works, and what comes back. This article is part of our The Helpdesk's Role in Security Culture series. This article is the one where the desk's role is drawn against somebody else's, so that both know where the line is.

It covers why two teams each think the other is watching, who does what, the handoff, and the feedback loop. Next come the shared vocabulary, the standing rhythm, and the security function that is a contractor. Then come the organisation with no security function and writing the agreement. A short war story and the desk-security working agreement to copy come last, in that order.

Two Sides Who Each Think the Other Is Watching

The gap between the desk and the security function is not a failing of either. It is a difference in what each one looks at. The desk lives in tickets: names, phone calls, "it felt wrong", a queue that refreshes all day. The security function lives in logs, alerts, policies and the questionnaire from the insurer: events with timestamps, rules, and a monthly review. The desk's view is people. The security function's view is systems. An incident begins in the first view and is proven in the second, and nothing connects them unless somebody writes down how.

The assumption that fills the gap is always the same: the other team can see this. The desk assumes the security function reads the sign-in logs, so a user's odd sign-in alert is "already known". The security function assumes the desk would ring if anything looked wrong, so silence from the desk is reassurance. Both assumptions are reasonable. Together they produce a building in which an incident can be visible to two teams for a week without either one saying a word. Lena's "we put it in the tickets" and Tom's "I don't read the tickets" are the same sentence from two sides.

The fix is not a tool or a meeting. It is a page. Who tells whom, about what, by when, and what comes back. Once the page exists, the previous articles in this series start working. The signals from Spotting Incidents Early From the Queue have somewhere to go. The thank-you culture from Security Without Blame has somebody to back it when a director wants a name. Without the page, both are good intentions with nobody on the other end.

Who Does What

The desk teaches, spots, contains by runbook, records, thanks and reports. It delivers the one-sentence lesson, tags and links the signals, and runs the first-hour steps when somebody clicks. It writes the timed note, thanks the reporter, and sends the message. All of that is work the desk already does inside ordinary tickets, which is why it belongs to the desk: nobody else is in the conversation when it happens.

The security function decides and investigates. It decides whether a pattern is an incident and whether everyone's password is reset. It decides whether a message is pulled from every mailbox and whether the insurer and anyone else are told. It investigates. It reads the logs and preserves the evidence in the order evidence has to be preserved. It works out what the account did and for how long, and hunts for the second account the desk has not seen yet. It owns the policy, the annual programme, any simulated phishing, and the conversation with the manager when the same person has clicked three times. None of that is desk work, and a desk that tries to do it is both slower and, occasionally, destructive.

The grey zone is where the agreement earns its keep, and the table below settles the common cases. The reset after a click is the desk's, because it is the runbook. The mailbox review is the security function's, because it is evidence. The forced password change for everyone is the security function's decision and the desk's execution. And the desk absorbs the ninety tickets that follow, which is worth saying out loud so that nobody is surprised. The teachable-moment lines are the desk's to say and the security function's to agree, so that the module and the sentence tell the same story.

The Handoff

The handoff is a short message with ticket numbers in it, and the shape is the one in the signals sheet. It says what was reported, by whom, and when, and what the desk did, with times. It includes the sentence that makes it a pattern and what the desk has not done. It is sent to a named person by a named route, with a fallback if that person does not answer inside an agreed time. It is not a retelling of the tickets, because the tickets exist and the security function can read them. It is the pointer and the one-line reason. The habit of handing over without dumping is the same one as in The Handoff That Does Not Dump, applied to a different recipient.

Mark the handoff on the ticket so it is visible without reading the notes. A flag, a status, a note that begins "told security 09:40, by phone, acknowledged 09:52". If you run QuerySolv, the linked tickets and the complete event history mean the security function opens one ticket and sees the whole pattern with its times. So the handoff is a link rather than a reconstruction. The escalation flag that sits apart from priority lets the desk say "this needs security" without pretending a routine unlock is urgent. Most tools have some way to do this. What matters is that the next technician can see the handoff happened.

What comes back, first, is an acknowledgement and an owner. "Got it, mine, will update by four" is enough, and the agreement says how quickly it arrives. A handoff with no acknowledgement is a message that may not have been read. The desk chases once by the fallback route and then notes that it did. The desk does not keep working the security side of the ticket while waiting. It keeps the user informed, keeps the record, and leaves the rest alone.

The Feedback Loop

The security function tells the desk what happened. And the desk tells the reporter, because a desk that reports into silence stops reporting and so do its users. The loop is small. It is a line on the ticket from the security function when its part is done ("message pulled from forty-one mailboxes; sender blocked; nothing clicked elsewhere; closed"). Then comes the desk's outcome message to the reporter in plain words. The outcome message and the monthly note of what the reports caught are described in Rewarding the Reporters. The agreement simply makes the security function's line a commitment rather than a favour.

The loop runs the other way too. The desk tells the security function what it is seeing in aggregate: reports up this month, lockouts quiet, three found devices, the lesson lines delivered. That is the material for the counts in the final article in this series. For the security function, it is the only view of the organisation's behaviour, as opposed to its systems, that exists. A security function that gets this from the desk every month stops treating the desk as a source of noise and starts treating it as an instrument.

Close the loop on the tickets that turned out to be nothing, with the same care. "Checked; the sign-in was the new mail app; thanks for flagging" costs the security function thirty seconds. It teaches the desk, and through it the user, that a false alarm was still welcome. The tickets that end in silence are the ones that teach everybody to stop sending them.

The Shared Vocabulary

The two teams use the same words to mean different things, and the agreement fixes a short list. "Incident" on the desk means an outage, the subject of What Makes an Incident Major. To the security function it means a confirmed compromise. "Report" is a user telling the desk something. An "event" is a signal the desk has tagged. An "incident" is the security function's word for what it has decided is real. "Click" is a person following a link. A "compromise" is an account somebody else has used. "Contained" is the runbook done. "Closed" is the security function's decision that nothing else is needed.

"Urgent" is the word to settle most carefully, because the desk's urgent and the security function's urgent arrive by different clocks. Agree that an account acting on its own, or a request the named requester denies, is a phone call now. Agree that a pattern is a message today and a single tagged signal is in the daily digest. Write the three levels on the page with the route for each. Without that, "urgent" means whatever the sender felt at the time, which is a poor way to schedule a response.

The tag is vocabulary too. One word on every ticket that carries a signal, agreed by both teams, so that the desk's search and the security function's digest use the same filter. Keep the list to ten words and resist the urge to grow it. A glossary that needs a glossary has stopped helping. (It will try to grow. Glossaries always do.)

The Standing Rhythm

Fifteen minutes a fortnight, same time, both present, and the agenda never changes. The tagged tickets since last time, in one list. The counts: reports, acknowledgement time, lessons delivered, anything the desk's habits check found. What the reports caught, in a sentence, for the monthly note. And the security function's side supplies anything about to happen that will generate tickets. That could be a new sign-in prompt, a simulated phishing run, or a policy change that will lock out everybody with an old phone. The desk that hears about the campaign on Monday is a desk that is not blindsided by forty "is this real?" tickets on Tuesday.

Twice a year the meeting is longer. It looks at the desk's habits with the checklist from The Desk's Own Security Habits, as a desk and never as individuals. The meeting also looks at the agreement itself. The question is whether the page still describes what happens. After any incident the page is reviewed within the month, while everyone remembers which line was missing. Most of the time the answer is a sentence added to the grey-zone table and a name updated on the contacts line.

The rhythm is the cheapest part of the arrangement and the part most often dropped when things are busy, which is to say when it matters. A standing fifteen minutes that survives a bad month has done more for the relationship between the two teams than any amount of goodwill, because goodwill does not have a calendar entry.

When the Security Function Is a Contractor

Many mid-sized organisations buy the security function by the hour, and the agreement has to say what those hours cover. A consultant on four hours a month who spends them on the firewall is not reading the desk's digest. Nobody has done anything wrong until the day the desk assumed otherwise. Write down what the retainer includes. Does the contractor receive the daily digest? Does a pattern message get a reply inside the day? Who does the desk ring out of hours, and what happens when they do not answer? The practical side of working with an outside provider, contacts, hours and the escalation when they are quiet, is covered in Working With an MSP. Most of it transfers directly.

The fallback is the line that matters. If the contractor does not acknowledge a pattern message inside the agreed time, the desk tells whoever owns IT internally, in writing. The desk continues to do the basics. The desk does not expand into investigation to fill the gap. It records that the gap existed. A quiet contractor is a problem for the organisation to solve with the contractor. It is not a reason for the desk to start reading mailboxes.

When There Is No Security Function

In the small organisation there is nobody called security. The honest arrangement is that the desk does the basics, does them well, and says plainly to management what it does not do. The basics are the things this series and its neighbours describe. They include the verification standard, phishing triage, the first-hour runbook after a click, and disable-first offboarding. They also include the teachable-moment lines, the signals sheet with its daily glance, the desk's own habits, and the monthly counts. A desk of one or two that does those consistently is doing more than many organisations with a security team do.

What the desk does not do is also written down, and said to management in one paragraph rather than discovered during an incident. The desk does not investigate what an account did or determine whether an incident is a breach in any legal sense. It does not preserve evidence to a standard anyone outside would accept. It does not talk to the insurer or anyone else outside. For each of those, the agreement names who does. Usually, that means an outside firm on a call-out basis, the insurer's own incident line if the policy has one, and a named person in management. That named person decides whether to make the call. The sentence to management is "we do the basics and we do them every day; nobody here investigates; here is who we would ring and who decides to ring them". Management hearing that sentence in a quiet month is a very different conversation from management hearing it at nine on a Friday night.

The boundary is also a protection for the person on the desk. A solo administrator who is also, by default, the security function, the compliance function and the firewall is one bad week from being blamed for all three. And the one-page agreement with management is the document that says what was agreed and what was not. The wider case for written boundaries when there is one of you is in Boundaries for the Solo Admin. This is the security chapter of it.

Writing the Working Agreement

The agreement is one page, written by the desk lead and the security contact together in an afternoon. It is signed by both and by whoever they both report to. It is kept where the desk can read it at eight in the morning. It has six parts. They start with who the parties are, with real names and routes, and who does what, with the grey-zone table. Next come the three urgency levels and the route for each, and what comes back and by when. The standing rhythm and the review come last. In the small organisation the second party is management and the agreement adds a line naming the outside help.

Write it in plain words, because the newest technician will be the one reading it under pressure. "Phone Tom. If no answer in thirty minutes, phone Priya. If neither, e-mail both and note it on the ticket" is an agreement. "Escalate to the appropriate security contact per the escalation matrix" is a sentence that has never once been read at 08:50. Keep names current. A page with a leaver's name on the contact line is a page that tells nobody.

A Short War Story: The Fourteen Tickets at Fenwick Marine

Fenwick Marine built boats, ran a desk of two, and paid a security consultant for four hours a month. The consultant spent those hours, sensibly and as asked, on the firewall. Over three months the desk closed fourteen tickets in which a user had received an odd sign-in alert. Each had the note "user confirmed it was probably them, closed". That was because the desk assumed the consultant saw the sign-in logs and the consultant assumed the desk would ring if anything looked wrong. The fifteenth alert belonged to an estimator whose account, two days later, sent a customer a quotation with the bank details changed. The customer, fortunately, rang to check. The cost was two days of the consultant's time at an urgent rate and a forced password change across the yard. It included a very long phone call with the customer. It also included the discovery that fourteen signals had been sitting in the queue, tagged by nothing, for a quarter. The lesson Fenwick wrote at the top of its new agreement was that an afternoon spent agreeing who watches what is cheaper than a quarter spent discovering that nobody did.

The Desk-Security Working Agreement

The agreement below is the one Lena and Tom wrote at Acme, with Fenwick's lesson added at the top. Fill every blank with a real name and a real route, keep it to one page, and have both parties sign it. The grey-zone lines are the ones most desks need to add to. The rest rarely changes. In an organisation with no security function, the second party is management, and the "outside help" line is the most important one on the page.

THE DESK-SECURITY WORKING AGREEMENT — ONE PAGE, SIGNED BY BOTH
Desk lead: ______________________   Security contact: ______________________   Signed off by: ______________
Security route: phone ____________ / message ____________   Fallback contact: ______________  after ____ minutes
Outside help (if no security function): ______________________   Who decides to call them: ______________

WHO DOES WHAT
  The desk: the one-sentence lesson; tagging, linking and the daily glance; phishing triage and the
    reporter's acknowledgement; the first hour after a click, by runbook; the timed record; the thank-you;
    the outcome message to the reporter; the monthly counts; its own habits check.
  Security: deciding what is an incident; reading logs, mailboxes and what an account did; preserving
    evidence; telling the insurer, leadership and anyone outside; the policy, the module and any
    simulated phishing; the conversation with the repeat clicker and their manager.
  Grey zone, settled here:
    Forced password change for everyone ..... security decides, desk executes, desk plans for the tickets
    The teachable-moment lines .............. desk says them, security agrees them
    Request that fails verification ......... desk refuses and records, security is told the same day
    ______________________________________ ... ______________________________________

URGENCY AND ROUTE
  Now (phone): an account acting on its own; an access request its named owner denies; a privileged
    account that cannot pass verification
  Today (message): any pattern: 2+ sign-in alerts in a week, 2+ unrelated lockouts in an hour,
    the same e-mail from 3 people, 2 failed verifications in a week
  Daily digest: every single tagged signal, explained or not

WHAT COMES BACK
  Acknowledgement and an owner within ____ minutes (now) / ____ hours (today) / next rhythm (digest)
  A closing line on every handed-over ticket, including the ones that were nothing
  One sentence per month on what the reports caught, for the desk's note to reporters
  Notice before anything that will generate tickets: campaigns, new prompts, policy changes

THE RHYTHM
  Fifteen minutes every ____________ : tagged tickets, counts, what was caught, what is coming
  Twice a year: the desk's habits checklist, as a desk; this page, line by line
  After any incident: this page reviewed within the month

WHAT THE DESK DOES NOT DO, WHOEVER IS ABSENT
  Investigate. Sign in as a user. Read beyond containment. Change logging or lockout policy.
  Decide whether something is a breach. Talk to the insurer or anyone outside. Tidy up.

Reviewed: ____________   Next review: ____________

Tom reads the digest now, because the page says he does, and Lena rings him, because the page says when. Neither of them is watching the other's view any more. They are watching their own, and handing over at the line, which is all two teams in a building ever needed to do.

Frequently Asked Questions