Does the Applicant employ a sandboxing solution for investigating suspicious emails/attachments?
The previous question asks whether detonation happens automatically. This one asks whether you can investigate something specific when a user reports it.
What the carrier is actually asking
The carrier is asking about investigative capability: when a suspicious message arrives, can you examine it and its attachments safely, and can you act on the result across every mailbox that received it. Automatic detonation is prevention; this is response.
Why it is underwritten
Detonation catches most of what it sees and not all of it. The messages that get through are the ones a user reports, and what happens next determines whether one person clicked or forty did. The ability to search the estate for a message and remove it is the control that limits the second number.
Where the answer lives in Microsoft 365, Entra ID, and Azure
Microsoft 365 provides this natively through the security portal, and the capability depends on the plan and on whether anyone has ever used it.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Microsoft 365 | Threat Explorer and the ability to search delivered mail by sender, subject, or attachment hash | Available and used, so an investigation starts with data rather than with a mailbox-by-mailbox search |
| Microsoft 365 | Automated investigation and response actions | Configured so a reported message triggers an automatic investigation rather than a manual one |
| Microsoft 365 | Ability to soft-delete or purge a message across mailboxes | Permissions in place before the incident, since obtaining them during one costs hours |
| Microsoft 365 | Safe Attachments dynamic delivery and detonation verdict history | Detonation verdicts retained, giving an investigative record for attachments already delivered |
| Process | A named owner for investigating reported mail and a target response time | A defined route from a user report to an action. Attested |
The technical ability to remove a message from every mailbox exists in most tenants and has been exercised in very few. The first attempt during a live phishing campaign is not the moment to discover which role holds the permission.
What a defensible yes requires
- Delivered mail can be searched across the tenant by content, sender, or attachment.
- Messages can be removed from mailboxes in bulk, by someone who has done it before.
- Reported messages reach a named owner with a response expectation.
- Automated investigation is enabled where the plan supports it.
- Detonation verdicts and investigation records are retained long enough to be useful after the fact.
How this answer goes wrong
The capability is licensed and unused. A user reports a phishing message, someone forwards it to the IT mailbox, and nobody searches for how many other people received it. The technical control existed throughout and answered nothing, because the process around it did not.
Frequently asked
Is this the same as the detonation question?
Related and distinct. Detonation is automatic and preventive; this is investigative and responsive. Carriers ask both because organisations often have one without the other.
Do we need a separate sandbox product?
Rarely. Microsoft 365 provides detonation and investigation natively at the appropriate plan level. A separate sandbox matters more for malware analysis teams than for this question.
Who should own reported mail?
Someone with a service level. A shared mailbox with no owner is where phishing reports go to be ignored, which undermines the report-phishing control on the next question.
What evidence works here?
A dated record of an investigation: message reported, search run, recipients identified, messages purged. One real example proves the whole chain.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture