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.
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.
Preparation is the only phase you execute entirely before an incident occurs. Everything else depends on how well you do this.
A Computer Security Incident Response Team (CSIRT) needs defined roles before an incident, not during one. At minimum, define:
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.
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:
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.
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:
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.
Preparation also means having your tools configured and tested before you need them. At minimum:
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.
Alerts worth triaging come from several layers:
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 |
MacOS generates several platform-specific logs that generic IR guides overlook:
log collect to pull a full archive from a suspect device.If your EDR vendor does not use the Apple Endpoint Security framework as its data source on macOS, your telemetry coverage has blind spots.
Containment stops the bleeding without destroying evidence. There are two containment modes, and you typically execute both in sequence.
Short-term containment is about immediate isolation to prevent spread. Actions depend on severity:
Long-term containment runs in parallel with the investigation and allows business operations to continue:
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:
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.
Eradication removes the threat from your environment completely. Rushing this phase causes re-infection.
Before eradicating anything, confirm you understand how the attacker got in and what they did. Common root causes in Apple endpoint environments:
Attackers targeting macOS commonly establish persistence via:
~/Library/LaunchAgents/ and /Library/LaunchAgents/ (user and system-level persistent processes)/Library/LaunchDaemons/ (system-wide background services).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.
Recovery returns affected systems to normal operation in a controlled, verified way.
Before restoring a device to your production environment:
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
Recovery is not complete until you have audited and rotated all credentials the compromised identity or device could access:
The post-incident review is where organizations actually improve. Treat it as a required deliverable, not optional documentation.
Within five business days of incident closure, run a post-mortem with the full CSIRT. The agenda should cover:
Track these metrics across incidents to measure improvement over time:
Every incident should produce at least one concrete program update:
Your incident response framework does not exist in isolation from your compliance obligations. Several major frameworks have specific IR requirements:
Building your IR framework against these requirements simultaneously is more efficient than retrofitting compliance onto an existing process.
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.
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.