Incident Response Framework: Step-by-Step Guide

Last Updated: October 30, 2026

When a security incident hits, the difference between a contained breach and a catastrophic one often comes down to whether your team has a practiced incident response framework or is improvising under pressure. This guide maps the NIST and SANS frameworks step by step, fills in the Apple-specific and MDM-specific gaps that most generic guides skip, and gives you the practical scaffolding to build or sharpen your own plan.

NIST vs. SANS: Choosing Your Incident Response Framework

Two frameworks dominate incident response planning. Both are sound. The right choice depends on your team's maturity and regulatory environment.

NIST SP 800-61 (4 phases):

1. Preparation

2. Detection and Analysis

3. Containment, Eradication, and Recovery

4. Post-Incident Activity

SANS PICERL (6 phases):

1. Preparation

2. Identification

3. Containment

4. Eradication

5. Recovery

6. Lessons Learned

The substantive difference is granularity. SANS splits NIST's combined containment/eradication/recovery phase into three discrete steps, which is useful when you want clear handoff points between teams or need to document phase completion for a compliance audit. NIST's condensed structure works better for smaller teams that move fast and don't want procedural overhead slowing response.

For organizations aligning to NIST frameworks broadly, SP 800-61 provides natural continuity with your existing risk management posture. ISO 27035 is a third option worth noting for organizations operating under European regulatory requirements, though its structure closely mirrors NIST's phases.

The rest of this guide uses the SANS six-phase structure because the added granularity maps cleanly to the specific actions your team needs to take at each stage.

Phase 1: Preparation

Preparation is the only phase you execute entirely before an incident occurs. Everything else depends on how well you do this.

Build Your CSIRT

A Computer Security Incident Response Team (CSIRT) needs defined roles before an incident, not during one. At minimum, define:

Incident Commander: Owns the response, makes containment decisions, communicates with leadership
Technical Lead: Drives investigation, coordinates analysis tasks
Communications Lead: Handles internal notifications, legal/PR coordination, and regulatory reporting timelines
Legal/Compliance Liaison: Advises on breach notification obligations under GDPR, HIPAA, or state privacy laws

For mid-market IT teams where one person wears multiple hats, document the RACI clearly so everyone knows who makes the call when the lead is unavailable.

Document Your Asset Inventory

You cannot respond to an incident on a device you don't know exists. Accurate hardware inventory management is a prerequisite for effective triage. Your inventory should include:

Device model, serial number, OS version
Assigned user and department
Network location (subnet, VPN status)
Installed software and known vulnerabilities
Data classification of assets accessible from that device

For Apple-first environments, this means maintaining a live inventory through your MDM rather than spreadsheets. MDM enrollment data gives you real-time OS version, compliance posture, and last check-in time, which matters when you need to quickly determine whether an endpoint was online during a suspected compromise window.

Build Playbooks for High-Probability Incident Types

Generic incident response plans fail during actual incidents because the team has to make policy decisions mid-crisis. Playbooks pre-answer those decisions for specific scenarios:

Ransomware on a managed endpoint
Credential compromise (phishing or password spray)
Lost or stolen device
Insider threat data exfiltration
Supply chain compromise (malicious software update)

Each playbook should include a severity classification rubric, the specific containment actions authorized at each severity level, notification thresholds, and evidence collection steps specific to the device platform.

Establish Your Tooling Stack

Preparation also means having your tools configured and tested before you need them. At minimum:

SIEM with log ingestion from endpoints, identity providers, and network infrastructure
EDR agent deployed on all endpoints (see what is endpoint detection and response (EDR) for a full breakdown of what to expect from these tools)
MDM with remote lock, wipe, and command capabilities enrolled on all managed devices
Out-of-band communication channel (Slack is fine until your environment is compromised; have a backup)

Phase 2: Identification

Identification means detecting that something is wrong and determining whether it constitutes a genuine security incident. False positives waste resources; missed positives cause breaches. The goal is accurate, fast triage.

Detection Sources

Alerts worth triaging come from several layers:

EDR telemetry: Process execution anomalies, suspicious network connections, privilege escalation attempts
MDM compliance violations: Devices reporting out of compliance, OS versions below your minimum baseline, or MDM profile removal
Identity provider alerts: Impossible travel logins, MFA fatigue attacks, service account anomalies
SIEM correlation rules: Cross-source patterns that no single tool flags alone
User reports: Don't underestimate this. Many ransomware infections are first reported by the affected user noticing slow performance or unexpected file encryption.

Severity Classification

Not every alert is a P1. Define severity tiers explicitly so analysts don't escalate everything or suppress genuine threats. A practical four-tier model:

Severity	Definition	Initial Response SLA
P1 - Critical	Active compromise, data exfiltration in progress, ransomware spreading	15 minutes
P2 - High	Confirmed malware on endpoint, compromised credentials, policy violation with data risk	1 hour
P3 - Medium	Suspicious behavior requiring investigation, failed attack attempts	4 hours
P4 - Low	Informational alerts, minor policy violations	Next business day

Apple-Specific Detection Considerations

MacOS generates several platform-specific logs that generic IR guides overlook:

Unified Log (OSLog): Captures system and application events at high fidelity. Use log collect to pull a full archive from a suspect device.
Apple Endpoint Security framework: Provides kernel-level telemetry for authorized security tools, including file system events, process execution, and network connections at a depth unavailable on older macOS versions.
System Integrity Protection (SIP) status: A disabled SIP state is itself an indicator of compromise or unauthorized modification.
Gatekeeper and XProtect logs: Show blocked execution attempts and malware signature matches.

If your EDR vendor does not use the Apple Endpoint Security framework as its data source on macOS, your telemetry coverage has blind spots.

Phase 3: Containment

Containment stops the bleeding without destroying evidence. There are two containment modes, and you typically execute both in sequence.

Short-Term Containment

Short-term containment is about immediate isolation to prevent spread. Actions depend on severity:

Network isolation: Remove the device from the network via MDM command, firewall ACL change, or switch port shutdown. On macOS, you can push a network configuration profile that blocks all traffic except to your MDM server, preserving management while cutting lateral movement paths.
Account suspension: Disable the compromised user's SSO/IdP account immediately. Do not just reset the password; a persistent attacker with session tokens will not be logged out by a password change alone.
Preserve the device state: Do not reboot the device if you need volatile memory artifacts. Live RAM contains running processes, network connections, and potentially encryption keys.

Long-Term Containment

Long-term containment runs in parallel with the investigation and allows business operations to continue:

Provision a clean loaner device to the affected user
Implement enhanced monitoring on adjacent systems and accounts that the compromised device or user had access to
Rotate credentials for service accounts and shared resources the user could reach
Deploy temporary network segmentation if the incident scope is still unclear

MDM-Powered Containment for Apple Devices

MDM changes the containment calculus for managed Apple devices significantly. Rather than requiring physical access or end-user cooperation, your IT team can execute containment actions remotely:

Remote Lock: Immediately locks the device with a PIN, preventing local access
Remote Wipe: Erases the device if it contains sensitive data and investigation is complete or impossible
Lost Mode (supervised devices): Locks the device, displays a custom message, and sends continuous GPS location back to the MDM
Profile installation: Push a restrictive configuration profile that disables specific capabilities (USB, AirDrop, personal hotspot) while preserving MDM connectivity
Managed Apple Account sign-out: Remotely signs the user out of their Managed Apple Account to revoke iCloud data sync

For lost or stolen devices, this workflow is documented in most MDM platforms and should be in your lost/stolen playbook before you need it. Remote management capabilities are explained in more depth in our remote device management overview.

Phase 4: Eradication

Eradication removes the threat from your environment completely. Rushing this phase causes re-infection.

Identify the Root Cause

Before eradicating anything, confirm you understand how the attacker got in and what they did. Common root causes in Apple endpoint environments:

Malicious OAuth application: User granted a third-party app excessive Google Workspace or Microsoft 365 permissions
Browser extension with broad permissions: Exfiltrates data via browser context without triggering endpoint-level alerts
Vulnerable application: An unpatched version of software with a known CVE that was exploited. Systematic CVE prioritization and remediation processes reduce this attack surface significantly.
Social engineering: User was tricked into running a malicious script or disabling security controls

Eradication Actions

Remove all identified malware artifacts, persistence mechanisms (LaunchAgents, LaunchDaemons, login items), and attacker-installed tools
Revoke all active sessions and OAuth tokens for the compromised account
Remove unauthorized applications, browser extensions, and configuration profiles
Patch the exploited vulnerability or configuration weakness before bringing the device back online
Audit all accounts that the compromised user or device could access for signs of lateral movement or privilege escalation

macOS-Specific Persistence Locations to Check

Attackers targeting macOS commonly establish persistence via:

~/Library/LaunchAgents/ and /Library/LaunchAgents/ (user and system-level persistent processes)
/Library/LaunchDaemons/ (system-wide background services)
Login items in System Settings
Kernel extensions (less common post-macOS 11 but still relevant in some environments)
Cron jobs and at tasks
Shell profile files (.zshrc, .bash_profile, .zprofile)

A clean MDM re-enrollment with a wiped device is often more reliable than manual eradication for high-severity incidents. If forensic investigation is complete and you have high confidence in your findings, a wipe and re-enroll cycle through your MDM gives you a verified clean state.

Phase 5: Recovery

Recovery returns affected systems to normal operation in a controlled, verified way.

Verify Before Reconnecting

Before restoring a device to your production environment:

Confirm the device is running a patched, supported OS version
Verify all MDM configuration profiles are applied correctly
Confirm EDR agent is enrolled and reporting
Run a baseline compliance check against your endpoint hardening guide standards
Verify no unauthorized applications or processes are running

Staged Recovery

For high-severity incidents, restore access in stages rather than all at once:

1. Restore access to non-sensitive systems first

2. Monitor for 24-48 hours before restoring access to sensitive data or privileged systems

3. Keep enhanced monitoring active for 30 days post-recovery

Credential and Access Review

Recovery is not complete until you have audited and rotated all credentials the compromised identity or device could access:

User's primary IdP credentials
Any SSH keys stored on the device
API tokens or service account credentials the user had access to
Saved browser passwords (assume compromised if the browser profile was accessible)
Password manager master credentials if the password manager was open during the compromise window

Phase 6: Lessons Learned

The post-incident review is where organizations actually improve. Treat it as a required deliverable, not optional documentation.

Conduct a Blameless Post-Mortem

Within five business days of incident closure, run a post-mortem with the full CSIRT. The agenda should cover:

Timeline reconstruction: What happened, when, and in what sequence
Detection gap analysis: What did we miss and why? How long was the attacker present before detection?
Response effectiveness: What slowed us down? What worked well?
Tool and process gaps: Where did we lack visibility, access, or automation?
Playbook updates: What needs to change in our documented procedures?

Metrics That Matter

Track these metrics across incidents to measure improvement over time:

Mean Time to Detect (MTTD): Time from incident start to confirmed identification
Mean Time to Contain (MTTC): Time from identification to successful containment
Mean Time to Recover (MTTR): Time from containment to full restoration of normal operations
False Positive Rate: Percentage of alerts that were not genuine incidents

Update Your Program

Every incident should produce at least one concrete program update:

A new or revised playbook
A new detection rule or SIEM correlation
A new configuration baseline or hardening requirement
A training session or tabletop exercise based on what went wrong

Compliance Alignment for Your Incident Response Framework

Your incident response framework does not exist in isolation from your compliance obligations. Several major frameworks have specific IR requirements:

NIST CSF 2.0: The Respond and Recover functions map directly to IR phases. The 2024 update added Govern as a new function, which encompasses CSIRT organization and policy ownership.
CIS Controls v8: Control 17 (Incident Response Management) defines specific safeguards including maintaining a contact list, conducting tabletop exercises annually, and establishing a process for third-party incident reporting.
SOC 2 (CC7.3-CC7.5): Requires documented incident identification, response, and communication procedures. Auditors will ask for evidence of incident logs and post-incident reviews. See our SOC 2 compliance guide for context on what auditors actually look for.
HIPAA: Requires covered entities to have documented response and reporting procedures, with breach notifications due within 60 days of discovery for incidents affecting 500 or more individuals.
GDPR: Requires notification to supervisory authorities within 72 hours of becoming aware of a personal data breach.

Building your IR framework against these requirements simultaneously is more efficient than retrofitting compliance onto an existing process.

How Iru Approaches Incident Response

Most incident response frameworks assume you are working with separate, siloed tools: one for device management, another for endpoint detection, a third for compliance reporting. That fragmentation slows every phase of response.

Iru combines MDM and endpoint security in a single platform, which changes the operational reality of incident response for Apple-first IT teams in a few specific ways.

During the identification phase, Iru provides real-time device health and compliance visibility across your entire Apple fleet. Rather than querying multiple tools to determine whether a device was online, what OS version it ran, and whether its EDR agent was active during a compromise window, that information is available in a single view. Device telemetry through the Apple Endpoint Security framework gives Iru's detection capabilities kernel-level visibility into process execution, file events, and network connections.

During containment, the same platform that manages your devices can execute remote lock, wipe, Lost Mode activation, and configuration profile deployment without switching tools or waiting for a separate MDM admin to act. For a P1 incident where minutes matter, this matters.

For eradication and recovery, Iru's compliance baselines and pre-built configuration profiles let you verify a device is clean and correctly configured before it returns to the production environment. The platform's alignment with CIS Benchmarks for macOS means your post-incident verification can reference an established standard rather than ad-hoc checks.

For teams with formal compliance requirements, Iru Compliance maps control evidence to frameworks including SOC 2, ISO 27001, and HIPAA, which means your incident response documentation and device compliance posture can feed directly into your audit evidence rather than living in a separate spreadsheet.

Building an Incident Response Framework That Actually Holds Up

The NIST and SANS frameworks give you the structure. The real work is filling that structure with specifics: who does what, on which systems, using which tools, within what time constraints, and with what escalation paths.

For Apple-first and mixed environments, that specificity requires understanding macOS forensics, MDM-powered containment, and Apple platform security behaviors that generic IR guides do not address. Organizations that invest in preparation and build platform-specific playbooks before an incident resolve incidents significantly faster than those working from generic templates.

Iru gives IT and security teams the unified platform to detect, contain, and recover from incidents across Apple devices without stitching together disconnected tools. If you want to see how MDM-integrated endpoint security changes your incident response capability in practice, Book a demo.

Frequently asked questions

What is an incident response framework?

An incident response framework is a structured methodology that defines how an organization detects, responds to, and recovers from cybersecurity incidents. The two most widely adopted frameworks are NIST SP 800-61, which uses four phases, and the SANS PICERL model, which uses six phases. Both cover the same core activities with different levels of granularity between steps.

What is the difference between NIST and SANS incident response frameworks?

NIST combines containment, eradication, and recovery into a single phase, while SANS separates them into three distinct steps. NIST's four-phase structure suits smaller teams or faster-moving environments. SANS's six-phase structure is better for organizations that want clear phase handoffs, detailed documentation at each step, or formal compliance audit trails for frameworks like SOC 2 or ISO 27001.

What should be included in an incident response plan?

A complete incident response plan includes: CSIRT roles and contact information, asset inventory procedures, severity classification criteria, communication and escalation paths, phase-specific response procedures, platform-specific playbooks for high-probability incident types (ransomware, credential compromise, lost device), evidence collection and chain-of-custody guidelines, regulatory notification timelines, and a post-incident review process.

How does MDM help with incident response for Apple devices?

MDM platforms enable remote containment actions on managed Apple devices including remote lock, remote wipe, Lost Mode activation, and configuration profile deployment. These capabilities mean your team can isolate a compromised Mac or iPhone in seconds without requiring physical access or end-user cooperation, which is especially important for remote workforces. MDM also provides real-time device health data that accelerates the identification and triage phases.

How often should you test your incident response framework?

At minimum, conduct a tabletop exercise annually that walks your CSIRT through a simulated incident scenario. CIS Controls v8 Control 17 recommends this as a baseline safeguard. Higher-maturity organizations run tabletops quarterly and supplement with live-fire red team exercises or purple team exercises that test detection and response against real attack techniques.

What are the most common gaps in incident response for Apple environments?

The most common gaps include: no macOS-specific forensic procedures (Unified Log collection, persistence location audits), EDR tools that do not use the Apple Endpoint Security framework and therefore have incomplete telemetry, missing MDM-based containment actions in playbooks, no procedure for handling lost or stolen iPhones or iPads separately from macOS incidents, and inventory gaps where personal or unmanaged devices can access corporate resources without triggering IR visibility.