Incident Response Policy
Last updated: 2026-04-28
This page describes how MIR detects, classifies, contains, and communicates security and operational incidents. It is designed to support customer obligations under GDPR Article 33, the EU Digital Operational Resilience Act (DORA), the NIS2 Directive's supply-chain provisions, and similar regulatory regimes.
Customer notification commitment. For any incident classified as Sev 0 or Sev 1 affecting customer data or service availability, MIR will issue an early-warning notification within 24 hours of confirmed detection, a confirmed-incident notification within 72 hours, and a final post-incident report within 30 days.
1. Severity classification
MIR classifies incidents using a four-tier scale. Classification is decided by the on-call engineer at first response and reviewed by the security lead within one business day.
| Severity | Definition | Examples | Customer notification |
|---|---|---|---|
| Sev 0 | Confirmed compromise of customer data, full service outage, or material breach of contractual or regulatory obligation. | Database compromise, partner credential leak, signed-attestation forgery, full multi-region outage exceeding RTO. | Early warning within 24 hours; confirmed notification within 72 hours; final report within 30 days. |
| Sev 1 | Suspected compromise, material partial outage, or significant degradation of customer-facing functionality. | Single-node compromise contained, prolonged degraded API performance, anomalous access pattern under investigation, sub-processor incident affecting MIR. | Early warning within 24 hours; confirmed notification within 72 hours; final report within 30 days. |
| Sev 2 | Operational issue with limited customer impact, or precautionary investigation that may or may not produce a finding. | Non-customer-facing internal alert, brief regional latency spike, contained vulnerability report under remediation, low-confidence anomaly under triage. | Notification only if investigation concludes customer impact occurred; in that case, escalated to Sev 1 with full timeline. |
| Sev 3 | Routine operational anomaly, false positive, or minor process deviation. | False alert, capacity event handled by autoscaling, customer-self-service issue. | Reported in monthly operations summary if recurring; otherwise tracked internally only. |
2. Notification timeline and channels
2.1 Early warning (within 24 hours of confirmed detection)
For every Sev 0 and Sev 1 incident, MIR issues an early-warning notice to affected customers' designated security contacts. The early warning includes:
- Date and time of detection
- Preliminary severity classification
- Affected systems and a high-level description of customer impact
- Containment status (active, contained, resolved)
- Next-update commitment time
2.2 Confirmed notification (within 72 hours of confirmed detection)
The confirmed notification provides the information needed to support the customer's own regulatory obligations:
- Confirmed nature and scope of the incident
- Categories of personal data affected, if any (per GDPR Article 33(3))
- Approximate number of data subjects and records affected
- Likely consequences of the incident
- Measures taken or proposed to address the incident and mitigate adverse effects
- Contact details for further coordination
2.3 Final post-incident report (within 30 days)
The final report includes the full timeline, root cause analysis, remediation steps already taken, and structural changes implemented to prevent recurrence. The final report is shared with affected customers' security and compliance contacts under the confidentiality terms of the master services agreement.
2.4 Notification channels
Notifications are sent via the following channels, in order of priority:
- Customer's designated security contact email (set in the partner dashboard)
- Customer's billing/admin email if no separate security contact is set
- An incident page accessible to authenticated partner administrators
- For active outages, a status page accessible without authentication
Customers are responsible for keeping their designated security contact email current. MIR notifies the most-recently-known contact and is not liable for failures of notification reaching out-of-date addresses.
3. Customer cooperation
During an active Sev 0 or Sev 1 incident, MIR will, at no additional charge:
- Provide a single point of contact for the duration of the incident
- Provide structured incident updates at intervals committed in the early warning
- Cooperate with the customer's own incident-response and forensic processes, including providing relevant audit logs, evidence trails, and access logs subject to applicable confidentiality and other-customer privacy
- Coordinate with the customer on regulator notification timing where MIR's notification to the customer is the trigger for the customer's own regulatory clock
4. Regulator and CSIRT cooperation
MIR cooperates with relevant supervisory authorities and CSIRTs, including:
- EU Data Protection Authorities for GDPR-reportable incidents affecting EU data subjects
- National CSIRTs in EU Member States for incidents within scope of NIS2
- European Supervisory Authorities (ESAs) for incidents affecting EU financial-sector customers under DORA
- The UK Information Commissioner's Office for incidents affecting UK data subjects
- State and federal authorities in the United States as required by applicable law
Where a regulator requests information from MIR that relates to a specific customer, MIR will, where legally permitted, notify the customer in advance and coordinate the response. Where MIR is legally prohibited from notifying the customer, the customer's master services agreement and DPA govern the disclosure.
5. Vulnerability disclosure
Security researchers and customers may report vulnerabilities to security@mirregistry.com. MIR commits to:
- Acknowledge receipt within 2 business days
- Provide an initial triage assessment within 5 business days
- Coordinate disclosure timing with the reporter, with a target of 90 days from initial confirmation
- Credit the reporter, where they wish to be credited, in the resulting changelog or post-incident report
MIR does not pursue legal action against good-faith security researchers who follow responsible disclosure practices and do not access, modify, or destroy customer data beyond what is necessary to demonstrate the vulnerability.
6. Continuous improvement
Every Sev 0 and Sev 1 incident triggers a documented post-incident review, including root cause analysis, remediation tracking, and a structural-change recommendation reviewed by MIR's leadership. Themes from incident reviews inform MIR's annual security program and are summarized in MIR's annual security and resilience self-assessment, available to customers on request under confidentiality terms.
7. Contact
Active or suspected incidents: security@mirregistry.com (24/7 monitored)
Privacy-specific incidents and data subject requests: privacy@mirregistry.com