Reporting Security Incidents
When and how to report security incidents — internal escalation, regulatory requirements, and law enforcement notification
Responding to a security incident is only half the job. Knowing when, how, and to whom you must report the incident is equally important – and in many cases, legally required. This guide covers internal escalation, regulatory obligations, and law enforcement notification for Mac administrators managing Apple device fleets.
Internal Reporting Chain
Every incident should flow through a defined internal escalation path. The speed and breadth of notification depends on severity.
Standard Escalation Path
Helpdesk / Mac Admin (initial detection)
↓
Security Team (investigation and triage)
↓
CISO / Security Lead (severity assessment)
↓
IT Leadership / CTO (operational impact)
↓
Executive Management (business impact)
↓
Legal Counsel (regulatory and liability assessment)
Escalation by Severity
| Severity | Notify Within | Who to Notify |
|---|---|---|
| Critical | 15 minutes | Security team, CISO, IT leadership, legal, executive management |
| High | 1 hour | Security team, CISO, IT leadership |
| Medium | 4 hours | Security team lead |
| Low | Next business day | Security team (via ticket) |
Tip: Do not wait for a complete investigation before escalating a Critical or High severity incident. Notify with what you know, clearly labeling unknowns, and provide updates as the investigation progresses.
When External Reporting Is Required
External reporting obligations are triggered by specific conditions, not by the severity label alone. You must report externally when:
- Personal data (PII) has been exposed or exfiltrated – Triggers data breach notification laws
- Protected health information (PHI) is involved – Triggers HIPAA breach notification
- The organization operates critical infrastructure – Triggers CIRCIA reporting requirements
- Contractual obligations exist – Customer contracts, cyber insurance policies, or vendor agreements may require notification
- Law enforcement involvement is warranted – Criminal activity, nation-state threats, or significant financial loss
Regulatory Requirements
GDPR (EU / EEA Data)
If your organization processes data of EU/EEA residents, GDPR Article 33 requires notification to the relevant supervisory authority within 72 hours of becoming aware of a personal data breach. If the breach poses a high risk to affected individuals, they must also be notified directly.
HIPAA (Healthcare Data)
Covered entities and business associates must notify:
- Affected individuals – Within 60 days of discovery
- HHS Secretary – Within 60 days (if 500+ individuals affected) or annually (if fewer than 500)
- Media – Within 60 days if 500+ individuals in a single state/jurisdiction are affected
State Breach Notification Laws
All 50 U.S. states have breach notification laws, each with different definitions of personal information, notification timelines, and reporting requirements. Key variations:
- Timeline – Ranges from “as expeditiously as possible” to specific day counts (e.g., 30, 45, 60 days)
- Triggers – Some states require notification for any unauthorized access; others require evidence of actual harm
- Attorney General notification – Many states require notifying the state AG in addition to affected individuals
Important: Consult your legal counsel to determine which state laws apply based on where affected individuals reside, not where your organization is headquartered.
CIRCIA (Critical Infrastructure)
The Cyber Incident Reporting for Critical Infrastructure Act requires critical infrastructure entities to report:
- Substantial cyber incidents within 72 hours
- Ransomware payments within 24 hours
Reports are filed with CISA (Cybersecurity and Infrastructure Security Agency).
Reporting to Government Agencies
CISA (Cybersecurity and Infrastructure Security Agency)
Report incidents at cisa.gov/report or call 1-888-282-0870. CISA can provide technical assistance and threat intelligence, and your report helps protect other organizations facing the same threat.
FBI Internet Crime Complaint Center (IC3)
File reports for cybercrime (ransomware, business email compromise, fraud) at ic3.gov. IC3 reports feed into FBI investigations and national threat tracking.
Apple Product Security
If the incident involves a previously unknown macOS or iOS vulnerability, report it to Apple Product Security at apple.com/support/security/ or email product-security@apple.com. Include technical details, reproduction steps, and any proof-of-concept code.
Incident Report Template
Use this template for both internal documentation and as the basis for external reports.
| Section | Content |
|---|---|
| Incident ID | Unique tracking number |
| Date/Time Detected | UTC timestamp |
| Date/Time Reported | UTC timestamp |
| Reported By | Name, role, contact info |
| Affected Systems | Hostnames, serial numbers, MDM device IDs |
| Affected Users | Usernames, departments |
| Incident Type | Malware, unauthorized access, data breach, phishing, etc. |
| Severity | Critical / High / Medium / Low |
| Timeline | Chronological sequence of events |
| Root Cause | How the incident occurred |
| Data Impacted | Types and volume of data affected |
| Containment Actions | Steps taken to isolate and stop the threat |
| Eradication Actions | Steps taken to remove the threat |
| Recovery Actions | Steps taken to restore normal operations |
| Indicators of Compromise | IPs, domains, file hashes, file paths |
| Lessons Learned | What worked, what failed, what to change |
| Prevention Measures | Policy or technical changes to prevent recurrence |
Communication Best Practices
What to Communicate
- Factual timeline of events (what happened, when)
- What data or systems were affected
- What actions have been taken to contain and remediate
- What steps are being taken to prevent recurrence
- Who to contact for questions
What NOT to Communicate
- Do not speculate about attribution or motive before the investigation is complete
- Do not admit fault or liability – Let legal counsel review all external communications
- Do not share technical indicators publicly before coordinating with law enforcement (this can tip off the attacker)
- Do not discuss the incident on unsecured channels (Slack messages on a compromised device, unencrypted email)
- Do not communicate directly with the attacker without guidance from legal and law enforcement
Document Retention
Retain all incident-related documentation according to your organization’s retention policy and any applicable regulatory requirements:
- Incident reports and evidence – Minimum 3 years (longer for regulated industries)
- Chain of custody logs – Same retention as associated evidence
- Communication records – All internal and external incident communications
- Forensic images and artifacts – Until legal counsel confirms they are no longer needed
Store retained documents in a secure, tamper-evident location with access controls and audit logging.
Next Steps
- Follow the complete response workflow: Mac Admin Incident Response Checklist
- Align your fleet with compliance frameworks: CIS Benchmarks for macOS