Skip to main content
Review and revision metadata
Review Date: 2026-06-16
Reviewer: Operations Manager

previous version on gdrive

Operational Guide: Incident Ticket Handling

This document defines the mandatory procedure for registering, analyzing, and mitigating security incidents within the myDRE ecosystem. It ensures structured alignment with the ISO 27001:2023 (A.5.24 - A.5.28) incident management lifecycle and satisfies NIS 2 (Article 21(2)(a) & Article 23) regulatory reporting obligations.

1. NIS 2 Significant Incident Framework​

To comply with the NIS 2 directive, anDREa explicitly classifies and mandates specialized handling for Significant Incidents.

Criteria for Significance​

An operational or security event is legally deemed a Significant Incident if it meets any of the following criteria:

  • Operational/Financial Impact: It causes, or has the potential to cause, severe operational disruption to anDREa core services or substantial financial loss.
  • Downstream Impact: It affects, or has the potential to affect, other natural or legal persons (Tenants, researchers, or institutional partners) by causing considerable material or non-material damage.

Statutory Reporting Timelines​

When an incident meets the significance threshold, the Director or designated security lead must execute the following staggered notifications to the national Computer Security Incident Response Team (NCSC) via ncsc.nl/contact and impacted Tenants via our Emergency Contact Channels:


┌────────────────────────────────────────────────────────────────────────┐
│                      NIS 2 REPORTING TIMELINE                          │
├───────────────────┬───────────────────┬────────────────────────────────┤
│ ⏰ T + 24 Hours   │ ⏰ T + 72 Hours   │ ⏰ T + 1 Month                │
├───────────────────┼───────────────────┼────────────────────────────────┤
│ Early Warning     │ Incident Status   │ Final Report                   │
│ Initial alert;    │ Detailed update;  │ Full RCA; comprehensive        │
│ flags malicious/  │ severity & impact │ mitigation analysis &          │
│ unlawful intent.  │ assessment.       │ forensic summary.              │
└───────────────────┴───────────────────┴────────────────────────────────┘

An Intermediate Report must also be compiled and submitted at any point during the lifecycle upon explicit request by the CSIRT.

2. Ingestion Channels & Ticket Creation​

Incidents enter the anDREa ecosystem through designated ingestion streams and must be triaged within Zoho Desk immediately:

Zoho Desk Routing​

  • Direct Monitoring alerts: Automated infrastructure events route to the Azure Alerts department.
  • Security Defenses: Identified threats or security anomalies route to the Security-related incidents department.
  • Support Escalations: Local Research Support Teams flag and transfer relevant triage tickets from their respective localized departments.

Email & Chat Ingestion​

  • Security Mailbox: Messages arriving at security@andrea-cloud.com must be forwarded to securitytickets@mydre.zohodesk.eu to automatically generate an audit-ready tracking ticket. Ingestion points include:

  • Automated Microsoft Defender for Cloud alerts.

  • System monitoring telemetry and heartbeats.

  • Direct security disclosures from external researchers or Tenants.

  • Google Chat Stream: Alerts identified within the internal SECURITY Google Chat room must be manually copied into a new ticket within the Security-related incidents department.

3. Registration & Root-Cause Analysis (RCA)​

Every verified incident must be logged and evaluated using the centralized Risk & Issue Template to ensure forensic tracking and compliance auditability. The evaluation must capture the following elements:

Operational Assessment Metrics​

  • Incident Profile: A comprehensive technical description of the incident, bug, or vulnerability.
  • Temporal Markers: The exact timestamp when the anomaly was first observed and when it was formally reported.
  • Blast Radius: The total volume of affected accounts or Workspaces. Document the duration the vulnerability or defect was live in the production environment (e.g., hours, days, or weeks).
  • Functional Implications: The precise impact on the myDRE environment (e.g., disruption to VM orchestration, data availability degradation, or threat of data exfiltration).
  • Classification & Priority: Categorization of the event as Low, Medium, or High based on operational impact and urgency.
  • Risk Matrix Integration: Direct mapping of the incident to known threat vectors inside the Compliance and Risk Matrices. If the vulnerability is novel, it must be added to the matrix and mapped to existing or newly drafted security controls.

4. Corrective Action Plans (CAP)​

To close the incident loop and satisfy auditor verification, the ticket must define a clear path to resolution:

  • Remediation Strategy: Detail the specific steps required to resolve the issue. When necessary, decouple the fix into a short-term workaround (containment) and a long-term architectural fix (eradication).
  • Implementation Schedule: Define target deadlines for deploying the CAP.
  • Residual Risk Calculation: Assess the remaining platform risk posture following CAP deployment. The finalized state must be driven down to Low or non-existent to formally close the incident cycle.
note

Auditor Verification Note: Historical incident records, communication trails, and post-incident analysis reports are locked and restricted to authorized security personnel to maintain forensic integrity (Reference Ticket: #4480).