NIST SP 800-61 Rev 3 and SANS PICERL Applied to Cloud Incident Response

Why frameworks matter for cloud IR

A framework gives you the structure to respond under pressure. When an executive calls at 2 AM asking whether customer data was compromised, you need a process that tells you what to do now, what comes next, and what you can defer. Without that structure, incident response becomes reactive improvisation where the loudest voice in the room drives the investigation and critical steps get skipped.

Two frameworks dominate IR practice: NIST SP 800-61 and the SANS PICERL model. Both provide the lifecycle structure. Neither was designed for SaaS environments where the evidence is ephemeral, containment targets identity rather than endpoints, and the investigation spans four evidence domains simultaneously. This section maps both frameworks to M365 reality so you can use them as operational guides, not abstract references.

NIST SP 800-61 Revision 3

NIST released SP 800-61 Revision 3 in April 2025, superseding Revision 2 entirely. The update is a complete restructuring, not an incremental revision. Revision 2 defined four phases (Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity) as a sequential lifecycle. Revision 3 abandons that linear model and aligns incident response with the six functions of the NIST Cybersecurity Framework 2.0: Govern, Identify, Protect, Detect, Respond, and Recover.

The restructured model has three levels. The bottom level covers preparation through the Govern, Identify, and Protect functions. These are broader cybersecurity risk management activities that support incident response but are not incident response themselves. The top level covers the incident response itself through Detect, Respond, and Recover. The middle level is continuous improvement, fed by lessons learned across all functions.

The key shift from Revision 2: preparation is no longer an IR-specific phase. It's part of the organization's broader cybersecurity risk management. This matters for M365 because the preparation decisions that determine your IR capability (log retention configuration, Graph API permissions, Conditional Access design, break-glass accounts) are exactly the kind of cross-functional governance decisions that Revision 3 places under Govern, Identify, and Protect. They're not something the IR team does in isolation. They require coordination with the identity team, the M365 platform team, and leadership who approve the licensing and configuration changes.

The other significant change: continuous improvement is no longer a post-incident activity. Revision 3 places it as a persistent feedback loop across all functions. In M365 terms, this means you don't wait until after an incident to discover that your Sentinel workspace doesn't ingest all four sign-in log tables. You run readiness tests (Module 2), identify the gap, and fix it as part of ongoing improvement.

SANS PICERL

The SANS PICERL model defines six sequential phases: Preparation, Identification, Containment, Eradication, Recovery, and Lessons Learned. PICERL is more tactical than NIST's framework approach. It's a sequence of actions: identify the incident, contain the threat, remove the attacker, restore operations, and document what happened. Most IR practitioners use PICERL as their operational model because it tells you what to do in what order.

PICERL and NIST are not competing frameworks. NIST Rev 3's Detect maps to PICERL's Identification. Respond maps to Containment and Eradication. Recover maps to Recovery. The primary difference is that SANS separates Containment, Eradication, and Recovery into distinct phases where NIST Rev 2 grouped them and Rev 3 splits them across Respond and Recover. In practice, most IR teams use PICERL for operational execution and NIST for governance alignment.

This course uses both. The course structure follows NIST Rev 3's lifecycle (Modules 1 through 3 are Govern/Identify/Protect preparation, Modules 4 through 6 are Detect/Respond/Recover, Module 10 is continuous improvement). The operational procedures within each module follow PICERL sequencing because that's how you execute under pressure.

Mapping frameworks to M365 reality

The frameworks define what to do. M365 defines the specific constraints and capabilities you work with. Each phase looks fundamentally different when the perimeter is an identity provider, the evidence is audit logs with retention limits, and the attacker holds OAuth tokens rather than malware on disk.

Preparation in M365

In traditional IR, preparation means building an IR plan, assembling a team, configuring forensic workstations, and deploying collection tools. In M365, preparation includes all of that plus a set of platform-specific decisions that directly determine your IR capability.

Log retention is a preparation decision. If your Sentinel workspace doesn't ingest AADServicePrincipalSignInLogs, you won't detect service principal abuse. If your UAL retention is at the default 180 days and the incident started seven months ago, the early evidence is gone. If your organization runs E3 instead of E5, MailItemsAccessed doesn't exist and you cannot prove which emails the attacker read. These are decisions made during preparation that constrain every subsequent phase.

Containment tooling is a preparation decision. The Graph API permissions required to revoke sessions, deploy Conditional Access policies, and audit OAuth applications must be configured before the incident. The emergency Conditional Access policies that block all authentication except from the IR team's IP must be pre-built, tested, and ready to activate. The PowerShell scripts that enumerate inbox rules, forwarding, and delegate access across 500 mailboxes must be written and validated. Module 3 covers this preparation in detail.

Detection and identification in M365

In traditional IR, detection often starts with an endpoint alert: an EDR tool flags a suspicious binary, a SIEM rule matches a network signature, or a user reports unusual behavior on their workstation. The investigation begins on the compromised endpoint.

In M365, detection starts with identity signals. Entra ID Identity Protection scores sign-in risk based on IP reputation, impossible travel, anomalous token, and other signals. Defender XDR correlates alerts across identity, email, endpoint, and cloud app sources. Sentinel analytics rules match patterns in sign-in logs and audit activity.

The critical difference from traditional detection: the time window is compressed and the evidence is expiring. The Verizon 2025 DBIR measured the median time-to-click on a phishing email at 21 seconds versus 28 minutes to report. By the time the alert reaches the SOC, the attacker may already hold a valid token, have read email, and created persistence. The first action after detection is not investigation. It's evidence preservation. Export the UAL. Snapshot the sign-in logs. Place litigation holds. Then investigate. Module 4 teaches this sequence.

M-Trends 2026 reported that 52% of incidents were detected internally, 34% by external entities, and 14% by the adversary themselves (through ransomware notes or public data leaks). IBM found that organizations with formal IR teams save $473,706 on average per breach, and AI-enabled organizations identified incidents 98 days faster than those using manual approaches. Detection speed directly reduces the blast radius of an M365 compromise because the attacker's access grows over time: first email, then files, then persistence, then lateral phishing, then data exfiltration.

Containment in M365

In PICERL, containment is a distinct phase that precedes eradication. In M365, containment requires simultaneous action across multiple channels because the attacker may maintain access through any combination of active sessions, OAuth consent grants, service principal credentials, inbox forwarding rules, and anonymous sharing links.

On an endpoint, you isolate the device and the attacker loses access. In M365, resetting the password addresses one channel. If you don't also revoke sessions (the attacker's token may remain valid), remove OAuth consent grants (the malicious app authenticates independently), delete inbox rules (email continues forwarding to the attacker), and revoke sharing links (files remain accessible), the attacker retains access through whichever channel you missed. Module 6 teaches the complete multi-channel containment methodology.

Eradication and recovery in M365

Eradication verifies that every persistence mechanism the attacker established has been removed. In traditional IR, this means scanning for backdoors, checking scheduled tasks, and verifying that the malware has been cleaned from every affected system. In M365, eradication means verifying that every OAuth app consent has been revoked, every malicious app registration and service principal credential has been removed, every inbox rule and forwarding configuration has been deleted, every unauthorized role assignment has been reversed, and every federation trust is legitimate. Each persistence type requires a different verification query.

Recovery in M365 is not rebuilding a server from a known-good image. It's restoring the identity to a known-good state, re-enabling access through clean Conditional Access policies, removing emergency lockdowns, and confirming that the attacker has no remaining path back in. Recovery also includes verifying that the attacker didn't plant time-delayed persistence: an app registration with a client secret that expires in 30 days and reactivates with a new secret, or a transport rule that forwards email to an external address only when the subject contains specific keywords.

Lessons learned and continuous improvement

NIST Rev 3 and SANS both emphasize post-incident improvement. The frameworks agree on the mechanism: conduct a lessons-learned review, identify what worked and what didn't, and implement changes. Where M365 adds specificity is in what those changes look like.

A post-incident review that concludes "the attacker used AiTM phishing to bypass MFA" has identified the technique. A review that concludes "we need to deploy phishing-resistant MFA for finance and executives, add a Sentinel rule for anomalous token sign-ins, and restrict OAuth app consent to admin-approved applications" has identified the specific controls to implement. Module 10 teaches how to run reviews that produce the second type of outcome.

How this course maps to both frameworks

The course structure aligns with both NIST Rev 3 and SANS PICERL. Modules 1 through 3 cover preparation (NIST: Govern, Identify, Protect; SANS: Preparation). Module 4 covers detection and analysis (NIST: Detect; SANS: Identification). Module 5 covers forensic evidence collection (NIST: Detect/Respond; SANS: Identification/Containment). Module 6 covers containment, eradication, and recovery (NIST: Respond/Recover; SANS: Containment, Eradication, Recovery). Module 8 covers regulatory communication (NIST: Respond). Modules 9 and 10 cover hunting and improvement (NIST: Detect + continuous improvement; SANS: Lessons Learned). Module 11 integrates everything in simulation.

Knowing which framework phase you're operating in during a live incident helps you make better decisions. If you're in the Identification phase and haven't yet completed evidence preservation, you know that containment actions that modify the environment (like resetting passwords) risk destroying evidence. If you're in the Containment phase and legal hasn't been notified, you know the regulatory clock may already be running. The framework keeps you oriented when the pressure is high.

Section 1.4 covers the regulatory context that adds a legal dimension to every phase of the IR lifecycle.