Control #15 Deep-Dive: Link Protection and Sandboxing for Inbound Mail

Cyber-insurance control #15 asks a simple yes/no: does your inbound mail include link rewriting, time-of-click URL analysis, and attachment sandboxing?

The honest answer is often "yes, because it's licensed" when the truthful answer is "no, because it's not enforced." That mismatch is exactly what carriers unwind after a loss.

This piece is the deep-dive on control #15. It sits under the broader 22 cyber-insurance controls underwriters ask about in 2026 and complements the architecture-level email security for SMBs in 2026: gateway vs API vs built-in buyer guide.

For every claim below, the goal is the same: pass control #15 honestly, produce evidence a carrier accepts, and avoid the "controls warranty" clawback after a claim.

What the carrier is actually asking

The typical questionnaire language on control #15 varies. Common phrasings:

• "Does inbound mail include URL rewriting and time-of-click analysis?"
• "Are inbound attachments detonated in a sandbox before delivery?"
• "Do you have link protection and attachment sandboxing on all mailboxes?"
• "Does your email-security tier include time-of-click URL reanalysis?"

Behind the language, the carrier is testing three specific capabilities on inbound mail:

1. URL rewriting. Links in inbound messages are replaced with a proxy URL so the platform can re-inspect the destination at click time, not just at delivery.
2. Time-of-click analysis. When a user clicks the rewritten link, the platform re-checks the destination against current threat intelligence. A URL that was benign at delivery but weaponized an hour later gets blocked at click.
3. Attachment sandboxing. Attachments are detonated in an isolated environment before delivery, so payloads that don't reveal themselves in a static scan (dropper macros, delayed execution, obfuscated scripts) can still be identified.

Static filtering catches known-bad URLs and attachment hashes at scan time. Phishing payloads increasingly weaponize after delivery — links that flip to bad, attachments that reveal payload on open. That's the gap this control is testing.

CISA's phishing guidance calls the pattern out explicitly: attackers use links and attachments that appear legitimate at first inspection, so recognizing and reporting matters at every layer.

Source: CISA: Recognize and Report Phishing

How to answer "yes" on Microsoft 365

For most SMB tenants on Microsoft 365, Defender for Office 365 is the built-in tier that satisfies control #15. Safe Links handles the URL rewriting and time-of-click analysis. Safe Attachments handles the sandboxing.

Sources: Safe Links in Microsoft Defender for Office 365, Safe Attachments in Microsoft Defender for Office 365

To answer "yes" honestly, the tenant needs all of the following:

• Defender for Office 365 licensed at Plan 1 or Plan 2, or bundled through Microsoft 365 Business Premium (which includes Plan 1).
• A Safe Links policy created, applied to all users (including executives and finance), with URL rewriting enabled and click tracking on.
• A Safe Attachments policy created, applied to all users, with dynamic delivery or block action configured.
• No carve-outs that quietly turn the protection off for high-value targets. If the policy has a "do not rewrite" list, verify who's on it and why.
• Preset security policies at Standard or Strict, or an equivalent custom policy — not left at the "Built-in protection" default, which is Microsoft's floor, not their recommended posture.

Microsoft's preset security policies (Standard, Strict) are the fastest path to a defensible configuration for most SMBs because they turn on Safe Links, Safe Attachments, anti-phishing, and impersonation protection with vetted defaults.

Source: Preset security policies in Defender for Office 365

The honest-yes checklist for Microsoft 365 is: policy exists, scope is tenant-wide, exceptions are documented, the protection is running today (not "will be enabled next quarter").

How to answer "yes" on Google Workspace

For Google Workspace tenants, the built-in tier that satisfies control #15 is the advanced phishing and malware protection settings plus the Security Sandbox.

Sources: Advanced phishing and malware protection in Google Workspace, Security Sandbox in Google Workspace

To answer "yes" honestly:

• Advanced phishing and malware protection turned on at the tenant level — spoofing checks, unauthenticated-sender warnings, attachment scanning, external-image warnings, and link scanning.
• Security Sandbox enabled on Enterprise Standard, Enterprise Plus, Education Standard, or Education Plus (where the license permits) for pre-delivery attachment detonation.
• All settings applied to the top-level organizational unit so they inherit to every sub-org, not just enabled in a pilot OU.
• Post-delivery threat protection enabled where available, so mail flagged after delivery can be quarantined or removed.

Google's advanced phishing and malware protection covers the link-scanning half of control #15. Security Sandbox is the answer to the attachment-sandboxing half. For a small business on a Google Workspace Business tier without Security Sandbox, the honest answer to control #15 depends on whether the carrier accepts advanced protection without pre-delivery attachment detonation — some do, some don't.

When a third-party layer changes the answer

An API-integrated third-party layer or a secure email gateway can satisfy control #15 with its own URL detonation and attachment analysis, running on top of or in front of the built-in tier.

Cases where a third-party layer becomes the right answer:

• The built-in tier isn't licensed at the correct level. A Microsoft 365 Business Basic tenant without a Defender for Office 365 license can't turn on Safe Links or Safe Attachments. Buying the license upgrade or adding a third-party layer are both defensible answers.
• The built-in tier is on and still missing detections. If the environment is a high-value BEC target and post-delivery phishing is still landing after Defender or Google is tuned properly, an API-integrated layer that re-inspects after delivery can catch more.
• The carrier explicitly wants a named third-party. Some questionnaires — especially for higher limits or specific verticals — request a named dedicated email-security product beyond the built-in tier.
• Internal-mail protection is required. The built-in tiers focus on inbound. If the carrier or the environment requires protection against internal-account fanout after a mailbox compromise, an API-integrated layer or a gateway with internal-mail inspection is the right architecture.

Naming a specific third-party product on the questionnaire is a commitment. If the carrier asks for a named layer, use the vendor's exact product name from the license, and be ready to produce configuration evidence for that product, not the built-in tier.

The architecture-level buyer guide walks through when the third-party decision earns its cost. For control #15 specifically, the question is narrower: does the layer you named actually do URL rewriting, time-of-click analysis, and attachment sandboxing on inbound mail?

Evidence carriers accept

A "yes" without evidence is a "yes" the carrier can unwind at claim time.

The evidence pack for control #15, in practice:

• Policy screenshots or exports. A screenshot of the Safe Links policy showing URL rewriting enabled and the applied-users scope, or a PowerShell export of the Get-SafeLinksPolicy and Get-SafeLinksRule output. Google equivalent: screenshots of the advanced phishing and malware protection settings at the top-level OU.
• Scope confirmation. Evidence that the policy applies to all mailboxes in scope of the answer — the executive team, finance, and any accounts that get targeted the most, not just a pilot OU.
• Effective date. When the setting was turned on. A policy enabled the week before renewal is defensible; a policy enabled the day after a phishing loss and back-dated on the questionnaire is not.
• Exception log. If any user or domain is excluded from Safe Links rewriting or Safe Attachments processing, a written reason for the exclusion.
• A dated screenshot from within the last 90 days. Underwriters increasingly accept — and prefer — recent evidence over a control-attestation letter from a year ago.

The evidence doesn't need to be a compliance-platform export. A dated screenshot with the policy name, scope, and current settings is defensible for most SMB questionnaires.

Common ways this "yes" gets clawed back after a claim

Carriers audit controls warranties after a loss. Control #15 has a small number of common failure modes that come up in post-claim reviews:

• The protection is licensed but not enabled. Defender for Office 365 sits in the license bundle; Safe Links is never turned on by policy. The forensic report shows the phishing URL was clicked and delivered a payload the platform would have caught at click time.
• The exception list is where the loss happened. The Safe Links policy exists tenant-wide, but the compromised executive's account was on a "do not rewrite" list, so their click was never inspected.
• Google Security Sandbox is claimed but the license doesn't include it. A Business Standard tenant answers "yes" on attachment sandboxing based on the built-in scanner, not the Security Sandbox (which requires Enterprise Standard or above).
• The tenant's third-party gateway sits in front of a mailbox that also has the built-in tier off. The gateway went unpaid three months ago and the tenant is now leaning on a built-in tier that was never enabled.
• The answer refers to a tenant that isn't in scope. A multi-tenant environment where the mailbox that got compromised is on a different tenant than the one the answer was written about.

The pattern in every one: the license or the technology existed, but the enforcement, the scope, or the maintenance didn't. The underwriter's post-loss investigation reads the difference clearly.

One caveat: a rewritten link is not a trust signal

URL rewriting has a documented abuse vector. Starting in mid-2024, researchers tracked phishing campaigns that launder links through the rewrite domains of email-security vendors: the attacker compromises an account at a company using a rewriting gateway, emails themselves a clean link so the gateway wraps it in the vendor's trusted domain, then reuses that wrapped link in phishing sent to other victims. Downstream filters — and trained users — see the security vendor's domain and relax. Proofpoint, Mimecast, INKY, and Sophos rewrite domains were all documented in the campaign wave.

Sources: Perception Point research, Mimecast threat intelligence

Two practical consequences. First, rewriting still protects your own tenant — the time-of-click check fires when your users click links your own gateway rewrote, so answering "yes" on control #15 with rewriting enforced remains correct. Second, train the other direction explicitly: a link wrapped in a security vendor's domain is not evidence the destination is safe. If your awareness training teaches "hover and check the domain," teach that exception too.

Some vendors answer this control with pre-delivery dynamic analysis and browser-level protection instead of rewriting. Carriers accept either — the questionnaire is testing whether post-delivery weaponization gets caught, not which mechanism catches it.

The 15-minute self-check

Before the next renewal cycle, run this fast pass:

1. Open the Microsoft 365 or Google Workspace admin center.
2. Confirm the Safe Links or advanced phishing policy is enabled and scoped to all users.
3. Confirm Safe Attachments or Security Sandbox is enabled where the license permits.
4. Check the exception lists. Anyone carved out gets flagged and re-reviewed.
5. Screenshot the current policy view with a visible date.
6. Store the screenshot in the same folder as the questionnaire and prior evidence.

That's 15 minutes and it changes the answer to control #15 from "we think so" to a defensible "yes, and here's the current-dated evidence."

Where the Cyber Insurance Readiness Sprint fits

The Sprint is the operational version of this deep-dive across the full 22-control questionnaire. In 7 business days, we map the current tenant configuration against the carrier's exact questionnaire, close the gaps that are cheap to close, and deliver a signed evidence pack with dated screenshots and policy exports for every control the carrier is asking about — including a defensible control #15 answer.

The promise is the deliverable, not the insurer's decision:

7 days. Flat fee. Signed evidence pack mapped to your carrier's questionnaire — delivered, or we keep working at no additional cost until it is. We don't control underwriter decisions. We control whether you walk in with the evidence they ask for.

If control #15 is one of the answers you're unsure about, scope a Cyber Insurance Readiness Sprint. If the tenant is closer to the renewal than 90 days, book a 30-minute briefing and we'll triage the answer before we scope the Sprint.

For a broader control map — MFA, EDR/MDR, backups, incident response, identity monitoring — the 10 control areas underwriters score and the full 22-control questionnaire breakdown are the natural companion reads. If the current gap is at the cheap-controls layer (MFA, callback rule, SPF/DKIM/DMARC), BEC and phishing on a budget is where to start.

FAQ

What does control #15 on a cyber-insurance questionnaire actually ask?

It asks whether inbound email includes URL rewriting, time-of-click URL analysis, and attachment sandboxing. The carrier is testing whether phishing payloads that weaponize after delivery — links that were benign at scan time, attachments that reveal payload at open time — will still get caught by your mail platform.

Does Microsoft Defender Safe Links satisfy control #15?

Yes, when it is licensed and actually enforced. Safe Links rewrites URLs, performs a check at click time, and can block or warn based on the verdict; Safe Attachments detonates attachments in an isolated environment before delivery. Both must be enabled by policy, applied to the users in scope, and not carved out by exceptions that quietly disable the protection.

Does Google Workspace satisfy control #15?

Yes, when the advanced phishing and malware settings are enabled at the tenant level and the Security Sandbox is turned on where the license permits (Enterprise Standard and above). Google's advanced protection covers link scanning and pre-delivery attachment analysis; Security Sandbox adds pre-delivery detonation.

What evidence do carriers accept for control #15?

Configuration screenshots or policy exports showing the setting is enabled and the scope covers all mailboxes, plus a dated record of when it was turned on. A generic "we have Microsoft 365" or "we use Google Workspace" answer usually does not survive a claim if the protection was licensed but not enforced.

What's the most common way this control fails silently?

The protection is licensed but not enabled by policy, or the policy has an exception list that carves out the executives, finance, or the accounts that get targeted the most. Anti-phishing and Safe Links policies with "do not rewrite" entries for specific users or domains are a common failure mode.

Do I need a third-party email-security layer to answer yes on control #15?

Not for most SMBs. Defender for Office 365 or Google Workspace advanced protection is generally accepted by carriers for control #15. A third-party layer is the right answer when the built-in tier is not licensed for the tenant, when the carrier specifically wants a named third-party, or when the built-in tier is on and still missing detections in the environment's real threat pattern.

How long does the Cyber Insurance Readiness Sprint take?

Seven business days. Flat fee. The output is a signed evidence pack mapped to your carrier's questionnaire, delivered or we keep working at no additional cost until it is.

Sources and references

• Safe Links in Microsoft Defender for Office 365
• Safe Attachments in Microsoft Defender for Office 365
• Preset security policies in Defender for Office 365
• Advanced phishing and malware protection in Google Workspace
• Security Sandbox in Google Workspace
• CISA: Recognize and Report Phishing
• FBI BEC overview
• Perception Point: hackers abuse URL rewriting in sophisticated phishing attack
• Mimecast threat intelligence: phishing campaigns using re-written links