The Alert That Is Actually a Process Failure

Somebody emailed a spreadsheet to a personal address. That is the alert. The reason is frequently that the approved route does not work, and nobody has ever been told.

The distinction made in “The Alert That Is Actually a Process Failure” should also shape any workforce technology used near an investigation. When reviewers consult a practical approach to time tracking with screenshots for time tracking with screenshots, its records can provide operational context, but a signal still needs validation, a stated threshold and a human decision before it becomes a finding.

The pattern

A file sent home because the remote access is unusable and the deadline is tomorrow.

For a separate perspective relevant to “The Alert That Is Actually a Process Failure”, consult the Google Security Blog. Use it to test the proposed threshold, investigation scope and review process rather than to substitute a generic checklist for the facts of a case.

A document shared through a consumer service because the official one requires a licence the person does not have.

Credentials shared because the permission request takes three weeks and the work takes two days.

Data exported to a spreadsheet because the system cannot produce the report that somebody above asked for this morning.

Each of these produces an alert that looks, from the console, exactly like exfiltration.

How to tell the difference quickly

Ask what they were trying to do. Not as an interview — as a question.

Somebody working around a broken process answers immediately, specifically, and usually with visible frustration about the process. The answer is checkable within an hour.

Somebody doing something else does not have that answer ready.

This single step resolves a large share of cases before anybody is named, which is the preliminary review note's argument.

Why it matters beyond the individual case

Each of these alerts is reporting a genuine defect: a tool that does not work, a permission process that is too slow, a report the system cannot produce.

A programme that closes the case and files it has discarded the finding. One that routes it to whoever owns the process has converted a security alert into an operational improvement, and reduced the future alert volume at the same time.

Most insider programmes have no route for doing that, which means the same workaround generates the same alert every month and nobody fixes the cause.

What this is not

Not a reason to treat every workaround as blameless. Sharing credentials is a real risk whatever the motive, and the person needs to be told so.

The distinction is between a response that addresses the behaviour and a response that treats the behaviour as evidence of intent. The first is proportionate and the second is not.

What to build

A category in the case record: closed, process defect, referred to whoever owns it.

And a quarterly count of those, sent to operations. It is frequently the most useful output an insider programme produces, and nobody expects it from a security function.

The question that takes thirty seconds

What were you trying to do. Asked early and without ceremony, it resolves a substantial share of alerts before anybody becomes a subject. Programmes avoid it because asking seems to tip the person off, which is a consideration in a small minority of cases and is applied to all of them.

Where the defect report should go

Not into the case file to be closed with it. To whoever owns the broken process, as a finding, with a count of how many alerts it has generated. That report is what converts a security function from something the organisation tolerates into something it uses, and it costs one email per recurring pattern.

Counting the category

A tally of cases closed as process defects, reported quarterly to operations. It is the clearest evidence that the programme produces something beyond enquiries, and it is available at no cost from records already being kept.

Asking without making it an event

What were you trying to do, asked as a question rather than as the opening of a process. Most people answer immediately and specifically, and the answer is checkable within the hour. The reluctance to ask comes from a tipping-off concern that applies to a small minority of cases and is applied to all of them.

For the file: Before concluding anything about intent, establish what the person was trying to achieve. Most of the time the answer is in the broken thing they were working around.