Google Workspace phishing protection

Gmail groups its anti-phishing behaviour into three blocks: attachment protection, link and external image protection, and spoofing and authentication protection. Each block is applied per org unit, and each has a separate choice of action — move to spam, or show a warning. Warnings are worth keeping in the first month because they tell you what would have been quarantined before anything is quarantined.

The failure pattern is structural rather than technical. An organisation configures the root org unit properly, then someone creates a child unit for contractors, interns or a newly acquired brand, and inheritance is broken by a single unrelated override. Reviewing the settings org unit by org unit takes twenty minutes and is the single highest-yield hour available in the console.

Security sandbox detonates attachments in a virtual environment before delivery, which catches malware that has no signature yet. It requires Enterprise Standard, Enterprise Plus, Education Standard or Education Plus, and it adds delivery latency measured in seconds rather than minutes.

For an organisation whose inbound mail is mostly internal and mostly from known suppliers, sandboxing is not usually the reason to move edition. For anyone receiving unsolicited attachments as a matter of routine — recruitment, accounts payable, claims handling, admissions — it is the control that changes outcomes most, and the edition cost per protected inbox is small against a single ransomware event.

A simulation sends a benign but realistic lure to staff and records who clicked, who submitted credentials and who reported it. The number that matters is not the click rate; it is the report rate, because reporting is the only behaviour that shortens an incident. Organisations that train on clicking alone drive clicks down and reporting down at the same time, which is worse.

The first run is free because it produces the evidence for the conversation that follows. A dated report showing a fifth of staff submitting credentials to a fake sign-in page settles budget arguments that no proposal document ever wins. Subsequent runs are quarterly, with the templates rotated so the exercise measures behaviour rather than memory of the last lure.

No inbound filter catches a plain-text message from a real, compromised supplier mailbox asking for a bank detail change. There is no attachment, no link, no spoofed header, and the sending domain has good reputation. Filtering treats it as ordinary business mail because that is what it looks like.

That class of attack is answered by process rather than configuration: a callback rule on payment changes, dual authorisation above a threshold, and a payee-verification step that does not use contact details taken from the requesting email. We write those rules into the runbook during setup, and they are the part clients most often skip.