Full Metal Mac FullMetalMac.com
Incident Response beginner reporting compliance notification escalation

Reporting Security Incidents

When and how to report security incidents — internal escalation, regulatory requirements, and law enforcement notification

Published: Feb 14, 2026 7 min read

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

SeverityNotify WithinWho to Notify
Critical15 minutesSecurity team, CISO, IT leadership, legal, executive management
High1 hourSecurity team, CISO, IT leadership
Medium4 hoursSecurity team lead
LowNext business daySecurity 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.

SectionContent
Incident IDUnique tracking number
Date/Time DetectedUTC timestamp
Date/Time ReportedUTC timestamp
Reported ByName, role, contact info
Affected SystemsHostnames, serial numbers, MDM device IDs
Affected UsersUsernames, departments
Incident TypeMalware, unauthorized access, data breach, phishing, etc.
SeverityCritical / High / Medium / Low
TimelineChronological sequence of events
Root CauseHow the incident occurred
Data ImpactedTypes and volume of data affected
Containment ActionsSteps taken to isolate and stop the threat
Eradication ActionsSteps taken to remove the threat
Recovery ActionsSteps taken to restore normal operations
Indicators of CompromiseIPs, domains, file hashes, file paths
Lessons LearnedWhat worked, what failed, what to change
Prevention MeasuresPolicy 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

Related Articles