Office 365 incident report
The regulator wants it in 72 hours. The evidence is already collected.
An incident report has three sections nobody can write from memory: what happened and when, how far the account could reach, and what was actually done about it. 1Security produces all three from data it already holds - up to three years of attributed activity, the live permission graph, and a log of every action taken - so the impact section is a count, not an estimate, and the report is done before the deadline is close.
The problem
The clock starts before the investigation ends.
Incident reports fail in the same three places. The timeline has gaps because the entry point was in month seven and nobody kept the history that far back. The impact section says "potentially affected" because nobody can enumerate what the account could reach - in a typical tenant that is hundreds of thousands of files through groups, links and inheritance. And the remediation section says "access was revoked" with nothing attached to prove it.
Meanwhile the deadlines are statutory. GDPR gives you 72 hours from awareness to notify the supervisory authority. NIS2 wants an early warning within 24 hours, a notification with an initial assessment within 72, and a final report within a month - each with severity, impact and indicators of compromise spelled out. Every one of those needs facts you either have on hand or spend the deadline reconstructing.
The usual result is a report written from four exports and a memory of who did what, finished at 2 a.m., with an impact section that ends in a question mark. The next incident starts the same way.
In practice
Four sections, produced instead of written.
How the report comes together in 1Security, in the order a regulator reads it.
- 01
Reconstruct the timeline
Open Activity logs, filter to the account and the window - even if the first sign-in was ten months ago. Every event is already attributed to the file, the app, the device (managed or not) and the country it came from, with occurred-at and discovered-at kept apart and the raw Microsoft record one click away. Sort by severity: the mailbox forwarding rule at 03:14 and the 600 downloads at 03:20 come first.
- 02
Count the blast radius
Open the account in Users. The drawer resolves everything it could reach through direct grants, sharing links, nested groups and site inheritance - sites, files, mailboxes - and how many of those files carry sensitive data or a sensitivity label. "Potentially affected" becomes "could reach 214,000 files, 3,100 of them with personal data".
- 03
State what was actually touched
Cross the reach with the activity: which files were opened, downloaded or shared, from which device and location, whether any of them held regulated data - with detection types and counts to cite. The travel trail shows whether the sign-ins were plausible for the account's owner or an impossible hop between two countries in an hour.
- 04
Attach the remediation trail
Every action taken through 1Security - links expired, sessions revoked, guest removed, account disabled, automated or manual - sits in Actions with the resource, the action, who approved it and when. The "corrective measures" section becomes an export with timestamps, not a sentence.
What makes it work
Memory, a map, and a log of what you did.
The report is only as good as the history and the permission graph underneath it.
Three years of audit history
Go from 180 days of audit history to three years with 1Security - searchable, attributed, on the licenses you already have, with the raw record one click away.
See the feature →Answers, not exports
Saved views, full exports and a read-only REST API - so the numbers in the report match the numbers on the screen, and your SOC can pull the same feed.
See the feature →Blast radius on demand
Effective access resolved through groups, links and inheritance - the impact section stops being an estimate and becomes a lookup.
See the feature →
FAQ
Common questions.
Does this cover the GDPR and NIS2 reporting deadlines?
It supplies the facts they ask for. The 24-hour early warning leans on real-time alerts and locations, the 72-hour notification on blast radius and sensitive-data scope, and the one-month final report on the retained history and the actions log. Deciding whether an incident is reportable, and to whom, stays with your counsel.
What if the incident started months ago?
That is what the retention is for. Up to three years of history on a standard license means an entry point from last quarter is still in the record, attributed to its user, device and location - the 180-day question stops mattering.
Can we prove the remediation actually happened?
Yes. Automated and manual actions land in one list with the resource, the action, the approver and the timestamp. Actions taken through 1Security are real Microsoft-side changes, reversible and visible in the admin centers, so the export matches what the auditor sees there.
Do we need E5 or a SIEM to get this?
No. Retention, attribution, blast radius and the actions log run on standard Microsoft 365 licenses with a read-only connection and nothing to install. Write actions are a separate opt-in module; until you enable it, the report still has the timeline and the reach - only the remediation section is filled by hand.
Write the next incident report from data.
Connect read-only and the history starts building the same day. When the next incident lands, the timeline, the blast radius and the remediation trail come out of one screen - while the 72 hours are still comfortable.
Or keep writing impact sections that end in a question mark.