skip to content

A genuine supplier invoice sat in phishing quarantine six hours. Who should hold release authority?

level: principalimportance: nice to knowfreq 29%

answer

  1. two failures: a wrong verdict and a slow undo
  2. release permission follows the verdict class
  3. the requester is not a neutral judge
  4. publish an adjudication response target
  5. an allow-list invites the hijacked thread

basics

~20 s

Split authority by verdict class, not by team politics. Low-confidence spam and bulk can be user-releasable; a high-confidence phishing verdict should stay administrator-released with a request path. The six hours is an adjudication-workflow problem, not a reason to weaken the filter.

solid answer

~50 s

Two decisions hide in this escalation. The first is the release model, and platforms already split it by verdict class: users can typically release their own bulk and spam, while a high-confidence phishing verdict is administrator-only with a request path. That split is right, because the class states how confident the control is and how bad a wrong release would be. The second decision is who answers the request and how fast, and that is what failed here. Where the mail admin and the security team hold different consoles, a request with no named owner waits for whoever notices. I would give the mail admin authority over spam and bulk, keep phishing releases with security, publish a response time, and measure false quarantine per class. I would not allow-list the supplier's domain, which is the door a hijacked reply chain walks through.

go deeper

for a junior

Know that quarantined mail is released by an administrator for the serious verdict classes and that users can request release rather than take it themselves. Never release a message just because the recipient is insistent.

for a middle

Explain why release permission is tied to the verdict class, and what you would actually check on the artefact before releasing something the control called phishing.

for a senior

Separate the wrong verdict from the slow undo and fix each with the right instrument, and be able to describe the checks and the record you leave behind when you release a message.

for a principal

Own the policy: how authority is split between a mail team and a security team with separate consoles, what response target you publish, what measure you take to the business, and how you refuse an allow-list without losing the argument.

## The escalation, and the trap in it An executive assistant's genuine supplier invoice was quarantined as phishing. It sat for six hours while she chased it, and the business escalated. The instinctive fixes offered in the room will be: let users release their own quarantine, allow-list the supplier, or turn the aggressiveness down. Two of those are wrong and one is right for the wrong reason. ## Separate the two failures The control made a wrong call. That is a **quality** problem, and it is measured as a false quarantine rate. The wrong call took six hours to undo. That is a **workflow** problem, and it is measured as time to adjudicate. Six hours is not evidence that the filter is too aggressive. It is evidence that nobody owns the request queue. Confusing the two is how organisations weaken a control that was working, in response to an incident that was really about a missing rota. ## Release models, and why the platform already splits them Mail platforms tie release permission to the verdict class: - **Spam and bulk**: low confidence, low harm if wrong. End users can normally release their own, and should be able to. - **High-confidence phishing and malware**: the control is asserting it is fairly sure, and the cost of a wrong release is a credential-harvesting page in front of the one person most motivated to open it. These stay administrator-released; the user can *request* release. That asymmetry is deliberate and worth defending out loud, because the person asking for their message is, by construction, the person who most wants to open it. A user pressured by a convincing invoice thread is not a neutral adjudicator of whether that thread is real. ## So who releases? Ownership should follow the same split rather than tribal boundaries: - Give the mail administrators full authority over spam and bulk, including bulk-threshold tuning, because that is where most of the volume and most of the annoyance lives. - Keep phishing and malware releases with the security team, because releasing one is a security judgement about a specific message, not a mail-flow operation. - Write down what security actually does before releasing: examine the artefact, check whether the URL or attachment is the reason for the verdict, confirm the thread and the sender through a channel other than the message, and record the decision with a reason. A release is a decision that should leave a trail, exactly like a detection tuning change. ## Fix the six hours properly - A named owner for the request queue during business hours, and an explicit response target the business can hold you to. In a team of three that may be a rota entry, not a tier. - A visible request path. Most delay comes from the user not knowing that requesting release is possible and telephoning IT instead. - Priority for senders the organisation already transacts with, so a supplier invoice is looked at before a marketing newsletter. - Report the false quarantine rate per verdict class monthly. When the business says the filter is too aggressive, you want to answer with a number and a trend rather than with the memory of one bad morning. ## The allow-list, and why it is the wrong souvenir The request that will follow this incident is: never quarantine mail from this supplier again. Refuse it, and explain why with the adversary in the room. Suppliers get compromised. When a supplier's mailbox is under adversary control, the mail that arrives is genuinely from them, authenticates correctly and quotes a real thread. A domain allow-list is precisely the instruction to stop inspecting the messages most likely to be trusted and most likely to be weaponised. If pressure to allow-list is irresistible, scope it as narrowly as the platform permits, put an expiry on it, and log it as an accepted risk with an owner rather than as a permanent configuration nobody remembers. ## What a principal-level answer sounds like "The verdict class sets who can release. The response time sets how much the business hates us. I would keep phishing releases with security, hand spam and bulk to the mail team, publish an adjudication target, and bring a false-quarantine number to the next review. I would not allow-list the supplier, because the next hijacked thread from that supplier is exactly what that allow-list would deliver untouched."

  • Why not simply let end users release their own high-confidence phishing quarantine?
    Because the person asking is the person the lure was written for, and they are usually under time pressure from the thread itself. That verdict class exists to say the control is confident and the cost of being wrong is high, so the release decision belongs to someone who can look at the artefact rather than at the invoice deadline.
  • The business demands the supplier's domain be allow-listed. How do you respond?
    I explain that suppliers get compromised, and that a hijacked reply chain from that supplier authenticates correctly and quotes real correspondence, so the allow-list would deliver the single most convincing attack we face untouched. If it is imposed anyway, I scope it as tightly as the platform allows, set an expiry, and record it as an accepted risk with a named owner.
  • What number would you bring to the next review to settle the aggressiveness argument?
    The false quarantine rate per verdict class over time, with the count of releases and how long each took to adjudicate. That separates the quality of the control from the speed of the workflow, and usually shows that the complaint is about the second while the proposed fix would damage the first.

saying these in an interview costs you the question

  • Lowers filter aggressiveness in response to one escalation
  • Allow-lists the supplier's whole sending domain
  • Lets end users release their own high-confidence phishing verdicts
  • Treats the six-hour delay as evidence the filter is wrong
  • Leaves the release request queue with no named owner

context

resolving links…