Administration
Which security alerts are worth switching on
An alert that reaches everyone reaches nobody. Which ones matter and who they must reach.
Many things can be alerted on, and that is the problem. When everything alerts, the team learns to ignore it within two weeks, and the alert that mattered arrives on the same day as thirty others. The question is not what can be alerted: it is what deserves to interrupt someone.
The ones worth an alert
| Event | Why it matters | Who it must reach |
|---|---|---|
| Someone signs in from a new device or place | First sign of a compromised account | That person, always |
| A password or second factor changes | If it was not you, it is urgent | That person, immediately |
| Someone gains administrator rights | It changes what that account can do to everything | The administrators |
| An integration key is created or withdrawn | It opens or closes a door that is not a person | The administrators |
| Many failed attempts in a row | Someone is trying | The administrators |
Important
And the criterion that decides whether this works is not on the list, it is the recipient: **a security alert cannot go only to a shared mailbox everyone can read**. If the compromised account is one of those reading that mailbox, whoever got in sees the alert before you do and can delete it. A person's alerts go to that person; the organisation's go to two named administrators, not to `info@`.
What is better left unalerted
Watch out
There is a consequence of this that surprises people: **the best alert is the one that almost never arrives**. If your team gets a security alert every couple of weeks, the day a real one lands they will read it carefully. If they get five a week, that day they will file it with the rest. Tuning what alerts is not about comfort: it decides whether the alert works when it counts.
How to set it up in ten minutes
- 1
Switch on the five in the table and nothing else at first
Widen it later if something is missed.
- 2
Name the people who receive the organisation ones
Two people, not a mailbox; and both should know they get them.
- 3
Check they actually arrive, once
Sign in from another device and see whether it warns you.
- 4
And decide what happens on receiving each one
An alert with no action attached ends up ignored.
Worth knowing
If an alert nobody recognises ever arrives, the order matters: close sessions and change that account's password first, investigate afterwards. It is set out step by step in the article on suspected access.
›What if the team travels a lot?
The new-device alert will keep firing: that is correct, and it is dismissed in a second.
›Do alerts replace reviewing the log?
No: they flag the urgent. The monthly review catches what does not fire.
›Should management be alerted?
Only about what they will decide. Otherwise it is noise with more seniority.
A real case
The situation
A company sends every security alert to the general admin mailbox.
What you do
- Routes personal alerts to each person and organisation ones to two named administrators
What you get
The alert reaches someone who can act, not a mailbox anyone can clear.
The situation
No security notices are switched on.
What you do
- Turns on those warning about access and changes
What you get
The odd thing shows in the moment.
The situation
Notices go to a single person.
What you do
- Addresses them to more than one
What you get
The notice reaches somebody who can act.
The situation
There are so many notices nobody reads them.
What you do
- Leaves on the ones that genuinely matter
What you get
The notice works again.
The situation
A notice fires and nobody knows what to do.
What you do
- Writes down what to do with each
What you get
The response is not improvised.
The situation
Notices go to a mailbox nobody watches.
What you do
- Directs them to a monitored address
What you get
The notice gets read.
This article answers
- account security alerts
- new device login notifications
- who should receive the alerts
- too many security notifications