Summary

This work focused on structuring an email protection capability around a question that is more useful than simply asking which security product is installed:

How can we increase our ability to detect and contain messages capable of compromising business decisions and critical processes?

The starting point was not a specific tool. It was understanding how email participates in payments, supplier relationships, contracts, customer interactions, HR processes, executive communications, and access to information.

From there, the capability was organized around prevention, detection, context, operations, review, and continuous improvement.

Context

Email remains essential to the operation of many organizations.

It carries:

  • invoices and payment requests;
  • supplier-data changes;
  • executive communications;
  • shared documents;
  • contracts;
  • customer information;
  • files from candidates and third parties;
  • notifications related to platforms and accounts;
  • information that may be confidential or regulated.

That makes email an attractive attack surface because it combines identity, trust, and the ability to act.

A message does not need to carry malware to create damage. It may try to make someone disclose credentials, approve a payment, modify bank details, open a file, share information, or continue a conversation with an impersonated party.

Problem

Email protection is often evaluated through technical questions:

  • is antispam enabled?;
  • are attachments analyzed?;
  • are malicious links blocked?;
  • are domain-authentication controls configured?

All of these matter, but they do not by themselves tell us whether the organization can recognize an attack that uses context and trust to alter a process.

The problem becomes broader when we consider scenarios such as:

  • targeted phishing against privileged or high-authority users;
  • business email compromise and supplier impersonation;
  • fraudulent requests to change bank-account details;
  • credential theft through fake authentication pages;
  • attachments or links whose risk changes over time;
  • corporate-domain impersonation against employees, customers, or third parties;
  • accidental or intentional data leakage;
  • messages that pass initial controls and are identified only later.

The objective, therefore, should not simply be to block more email, but to build a capability with better context and better learning.

Design principle

The guiding principle was simple:

Do not start with the tool. Start with the scenarios we need to be able to detect, contain, and explain.

This separates a product-feature conversation from a security-outcome conversation.

The capability was organized into seven components.

01 — Identity and trust

The first component asks who appears to be sending the message and how much trust should be assigned to that identity.

It includes criteria such as:

  • domain authentication;
  • impersonation detection;
  • lookalike or suspicious domains;
  • new or unusual senders;
  • protection of the organization’s email identity;
  • relationship context between sender and recipient.

The goal is to reduce the ability of an attacker to inherit trust simply by appearing to be someone else.

02 — Content, intent, and context

The second component expands analysis beyond signatures and malware.

It looks for signals related to:

  • phishing;
  • BEC and fraud;
  • unusual pressure or urgency;
  • sensitive requests;
  • language designed to provoke an action;
  • behavior inconsistent with the normal relationship between the parties.

The point is not to assume that a particular word is malicious. It is to combine enough signals to identify interactions that deserve different treatment or review.

03 — Files, links, and active content

Attachments and URLs remain important attack paths.

The capability should consider:

  • attachment analysis;
  • URL evaluation;
  • malicious-content prevention;
  • isolation or review when risk is uncertain;
  • the ability to incorporate new intelligence after the initial analysis.

A decision made when a message is received should not always be treated as final.

04 — Continuous protection after delivery

One of the most important design principles is that delivery should not end detection.

Risk can change when new information becomes available.

The capability should therefore be able to:

  • review delivered messages;
  • identify related messages or campaigns;
  • reassess links or threats when context changes;
  • locate potentially exposed users;
  • take corrective action when a threat is reclassified.

This turns detection into a continuous activity.

05 — Critical users and processes

The capability should not focus only on total threat volume.

It needs to answer questions such as:

  • which users receive the most attacks?;
  • which areas concentrate phishing or fraud?;
  • are executives receiving targeted attempts?;
  • do finance and procurement receive sensitive requests through email?;
  • which accounts can approve, modify, or access critical processes?

Finance, procurement, executives, HR, legal, and administrators may need differentiated attention because the potential impact of a successful deception is different.

06 — Domain governance and information protection

The design also includes two email-related surfaces that are often reviewed separately.

The first is domain identity: defining who is authorized to send on behalf of the organization, validating message integrity, and establishing policy for authentication failures.

The second is information leaving through email: contracts, financial statements, personal data, legal documents, or customer information may require monitoring and gradually stronger controls to reduce accidental or intentional leakage.

The principle here is to avoid abrupt controls that break operations. Monitoring, learning, tuning, and then applying stricter controls is often more sustainable.

07 — Operations, metrics, and learning

A technology layer does not remain useful on its own.

The operating model includes activities such as:

  • review of relevant security events;
  • quarantine management;
  • false-positive and false-negative analysis;
  • policy tuning;
  • review of the most exposed users and areas;
  • documentation of meaningful changes;
  • prioritized recommendations;
  • periodic reporting with context for decision-making.

This creates a feedback loop based on what is actually happening rather than a static configuration.

What to observe to know whether the capability is working

I do not consider a single metric sufficient.

A more useful set of signals can include:

  • volume of messages and events analyzed;
  • phishing identified;
  • BEC and fraud attempts;
  • impersonation of people, suppliers, or the corporate domain;
  • malicious or suspicious links and attachments;
  • most targeted users and areas;
  • meaningful false positives;
  • false negatives identified;
  • policies that required adjustment;
  • threats identified after delivery;
  • decisions or recommendations produced by the analysis.

The goal is not to build a dashboard full of numbers. It is to determine whether the capability is reducing exposure, improving detection, and producing useful information for decisions.

Business controls that complement detection

Technology should not be the only control point.

In especially sensitive processes, a second validation can significantly reduce the impact of a convincing message.

Examples include:

  • verifying a bank-account change through another channel;
  • requiring dual approval for certain payments;
  • validating exceptional executive requests;
  • defining procedures for containing or recovering compromised accounts;
  • making it easy for users to report suspicious messages.

Security improves when technical controls and business-process controls reinforce each other.

Role

My work in this piece focused on:

  • framing the problem from business risk;
  • identifying relevant attack scenarios;
  • organizing the capability into detection, protection, and operating components;
  • defining useful signals and metrics;
  • connecting critical users to business processes;
  • separating required capabilities from vendor-specific product functions;
  • designing an incremental improvement approach.

Result

The result was a capability model that makes it possible to discuss email security without starting with brands or feature lists.

The conversation shifts from:

“Which features does the tool have?”

toward questions such as:

“Which scenarios are we able to detect?”

“Which users and processes carry greater potential impact?”

“What happens when a threat changes after delivery?”

“How do we learn from false positives, false negatives, and real attacks?”

“What does leadership need to know in order to decide?”

Lessons learned

  • protecting email means protecting decisions and processes, not only mailboxes;
  • high-impact attacks may depend more on identity and context than on malware;
  • message delivery should not close the detection cycle;
  • a sustainable capability needs operations, metrics, and continuous tuning;
  • users with authority or access to sensitive processes require a different risk lens;
  • strong technology loses value if there is no process to review, learn, and act;
  • business controls can contain attacks that pass through technical controls.

A practical conclusion

An email protection capability creates value when it increases the probability of detecting a dangerous interaction before it becomes a compromised credential, a fraudulent payment, a data leak, or a disruption to a critical process.

That is the outcome I am interested in measuring.