A.5.26 Response to Information Security Incidents
1. Overview and Lifecycle Strategy
anDREa ensures that all security events, anomalies, and suspected data breaches affecting the myDRE platform are responded to in accordance with documented procedures. This policy guarantees a coordinated response to minimize operational disruption, protect sensitive health and research data, and meet rigorous international compliance standards.
The response framework explicitly enforces seven distinct operational phases:
- Identification: Continuous detection of security anomalies via automated monitoring or user reporting.
- Reporting: Escalation of suspected incidents through defined communication paths.
- Assessment: Triage and classification of threat severity, blast radius, and regulatory impact.
- Containment: Execution of proactive isolation mechanisms to mitigate active exploits or exposure.
- Eradication: Root-cause removal of the underlying vulnerability or threat vector.
- Recovery: Safe, verified restoration of affected system environments to baseline operations.
- Lessons Learned: Post-incident forensics and structural optimization of the ISMS.
Related Operational Procedures
This policy operates in direct conjunction with the following internal frameworks and procedures:
- Data Breach Procedure
- Disaster Recovery Plan
- (Post) Incident Analysis Guidelines
- Contingency Response Plans
- Standard Operating Procedure: Handling Incident Tickets
- User Guide: Reporting Suspected Security Incidents
2. Communication Governance and the "Need-to-Know" Principle
The "Need-to-Know" Principle
All communications follow a strict need-to-know restriction to protect sensitive information and ensure that details are shared only with authorized individuals who require them for decision-making or operational purposes. The Management Team ensures that internal and external status updates are carefully curated to maintain transparency without inadvertently exposing system architecture or expanding the platform's threat surface.
Stakeholder Communication Channels
- Public & Platform-Wide Updates: General system impact notices, availability alerts, or structural incident statuses are displayed globally via the Alerts Banner hosted on the mydre.org login portal.
- Direct Targeted Communications: Highly localized or high-impact updates are disseminated to specific tenant administrators via verified enterprise ticketing streams, secure email channels, or direct phone lines.
- Frequency Dynamics: Update intervals are dynamically scaled based on the incident's operational impact but are strictly aligned with major resolution milestones.
- Regulatory Compliance Reporting: All official notifications to external supervisory authorities, national bodies, or legal entities are processed exclusively by the Director.
Effective April 2025, anDREa's Management Team (MT) collectively fulfills all operational duties of the Security Officer (SO). The Director retains ultimate organizational accountability and responsibility for all security governance tasks.
3. Incident Ingestion and Reporting Channels
Client Detail
Security risks and issues are routed based on who identifies them:
- 1a. (CI)SO Escalation: A (CI)SO can contact anDREa’s Security Officer (SO) directly. Refer to the anDREa Core Contact Information Matrix page.
- 2. End-User Reporting: Users must report any suspected issues to their Local Research Support via the myDRE Support Ticket System.
- 3a & 3b. Local Research Support Escalation: If Local Research Support suspects a data leak or myDRE security issue, they are trained to escalate it immediately to anDREa Management or Support & Ops via:
- A ticket in the Security-related incidents department, or
- Emailing/contacting security@andrea-cloud.com.
Next Steps: The designated handler (Local Research Support or anDREa SO) will gather the required evidence and process the ticket according to the [How to handle incident tickets] procedure.
anDREa Management
1. Intake Channels (1a, 1b, 3a)
Security issues and risks are identified and routed to the anDREa Security Officer (SO) via three main channels:
- Channel 1a ((CI)SO Escalation): A (CI)SO contacts the anDREa SO directly. (See [Contact Information]).
- Channel 1b (Automated Alerts): Monitoring systems automatically post potential risks to the internal security group.
- Channel 3a (Research Support Escalation): If a Research Support Team member suspects a data leak or security issue, they notify the SO via a ticket in the Security-related incidents department or email security@andrea-cloud.com.
Next Steps: For all channels, the anDREa SO will gather the required information following the [How to handle incident tickets] procedure.
2. Assessment & Containment (5a)
In consultation with at least the Director or Operations Manager, initiate the following actions:
- Data Breach Verification: Evaluate the situation using the [Data breach procedure].
- Execute Contingency Blocks: If needed, immediately contain the threat by blocking:
- One or more users / VMs / Workspaces
- One or more Subscriptions / Tenants
- myDRE as a whole
3. Severity Classification & Triage (5b)
In consultation with at least the Director or Operations Manager, determine the priority:
If the issue is a P1 (See [P1 Definition]):
- Scramble the required P1 response personnel.
- Ensure the hotfix is verified and deployed in place.
- Complete a Post Mortem / Lessons Learned review.
- Fill out all regular compliance documentation.
If the issue is NOT a P1:
- Pass the item directly to the Scrum Master for standard prioritization.
Support and Ops detail
1. Support Escalation Path (3b & 4a)
- Local Research Support (3b): Trained to report all suspected security items directly to anDREa Support.
- anDREa Support Triage (4a): If anDREa Support suspects a data leak or a myDRE security issue, they will immediately inform the Security Officer (SO) and gather the necessary evidence following the [How to handle incident tickets] procedure.
2. Severity & Priority Routing (4b & 5b)
For any identified security issue, the route depends on urgency and priority:
- Non-Urgent Items (4b): Automatically passed directly to the Scrum Master for standard grooming.
- Urgent Items (5b): The SO, in consultation with at least the Director or Operations Manager, will determine if it is a Priority 1 (P1) (see [P1 Definition]):
- If YES (P1): 1. Scramble the required P1 response team.
- Ensure the hotfix is verified and deployed in place.
- Complete a Post-Mortem / Lessons Learned review.
- Complete all standard compliance documentation.
- If NO: Pass the item directly to the Scrum Master.
3. Agile Team Triage (6)
- Daily Standup Review: For any non-P1 items passed to the Scrum Master, the team will collectively decide during the Daily Standup whether to develop an immediate hotfix or move the item to the product backlog.
Execution
In consultation with at least the Director or Operations Manager, determine the priority and execution path for the security issue:
5b. Severity Classification & P1 Workflow
If the issue is a P1 (see [P1 Definition]), initiate emergency response:
- Scramble Team: Immediately assemble the required P1 response personnel.
- Verify Hotfix: Ensure the emergency hotfix is validated and deployed in place.
- Conduct Review: Complete a mandatory Post-Mortem / Lessons Learned assessment.
- Document: Complete all standard compliance documentation required for audit trails.
If the issue is NOT a P1:
- Pass the ticket directly to the Scrum Master for standard handling.
6. Daily Standup Triage (Non-P1 Items)
For items passed to the Scrum Master, the team will collectively review the issue during the next Daily Standup to decide the path forward:
- Path A (Hotfix): Develop and deploy a hotfix if the team determines immediate remediation is needed.
- Path B (Backlog): Move the item to the product backlog for standard prioritization and sprint planning.
4. Regulatory Framework: NIS 2 Significant Incident Reporting
To comply with statutory NIS 2 obligations, anDREa explicitly flags and escalates "Significant Incidents." These require mandatory reporting to the competent authority (CSIRT / NCSC-NL) and any affected clients.
Criteria for Significance
An incident must be treated as a Significant Incident if it meets either of the following conditions:
- Operational/Financial Impact: It causes, or is capable of causing, severe operational disruption to anDREa services or substantial financial loss.
- Third-Party Impact: It affects, or is capable of affecting, clients or users by causing considerable material or non-material damage.
Mandatory Reporting Timeline
┌────────────────────────────────────────────────────────┐
│ [STAMP] INCIDENT DETECTED │
└───────────────────────┬────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────┐
│ 1. EARLY WARNING (Within 24 Hours) │
│ ────────────────────────────────────────────────────── │
│ • Submit initial notification to CSIRT / NCSC-NL │
│ • State if a malicious or unlawful origin is suspected │
└───────────────────────┬────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────┐
│ 2. INCIDENT NOTIFICATION (Within 72 Hours) │
│ ────────────────────────────────────────────────────── │
│ • Update initial warning parameters │
│ • Deliver initial severity and impact metrics │
└───────────────────────┬────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────┐
│ 3. INTERMEDIATE STATUS REPORTS │
│ ────────────────────────────────────────────────────── │
│ • Submitted dynamically upon direct request from CSIRT │
└───────────────────────┬────────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────┐
│ 4. FINAL REVIEW REPORT (Within 1 Month) │
│ ────────────────────────────────────────────────────── │
│ • Comprehensive root-cause analysis │
│ • Finalized long-term engineering mitigations │
└────────────────────────────────────────────────────────┘3. Communication & Contact Protocols
- Internal / Client Escalation: For immediate communication adjustments, use the official anDREa Contact Channels.
- Authority Notification: Submit the Early Warning, 72-hour Notification, and ongoing status updates via the NCSC-NL Reporting Portal.
Operational Note: To ensure mandatory compliance tracking, this assessment and timeline tracking are hardcoded as an explicit part of the standard Risk & Issues Template.
5. Operational Response Workflows
Management Team (MT) Intervention Path
Upon ticket instantiation, the MT references the core instructions inside the Issues and Risk Logging, the *Risk & Issues Template, and the internal emergency standard Redbook.
The MT executes the following evaluations in parallel with the Director and Operations Manager:
- Privacy Verification: Execute the Data Breach Procedure to confirm if personal data or sensitive patient files have been exposed.
- Blast Radius Containment: Determine if immediate platform contingency isolation is necessary. Authorized containment mechanisms include:
- Revoking or blocking specific user identities.
- Terminating or isolating specific Virtual Machines (VMs).
- Shutting down isolated myDRE Workspaces.
- Suspending boundaries on full Subscriptions or Client Tenants.
- Executing an emergency lockdown of the entire myDRE platform fabric.
- Priority-1 (P1) Classification: Check the event against our formal P1 Definition. If classified as a P1 emergency, the SO activates the incident response protocol:
- Scramble assigned engineering and management teams for immediate response.
- Oversee the creation, deployment, and live verification of targeted hotfixes.
- Enforce the execution of a formal Post-Mortem.
- If the event does not meet P1 criteria, route the item directly to the Scrum Master for standard triage.
Scrum Master & Engineering Workflows
For non-emergency or regular operational issues routed to the engineering backlog:
- The Scrum Master presents the security ticket to the core development team during the Daily Standup.
- The team evaluates whether an immediate point-release hotfix is required or routes the task appropriately into the standard sprint backlog as an prioritized Product Backlog Item (PBI).
6. (Post) Incident Analysis and Continuous Optimization
Incident Registration
Every validated security incident triggers an entry inside the central Issues and Risk Logging, generating a standardized incident reporting structure.
Root Cause Analysis (RCA) and Action Plans
The finalized incident report documents a rigorous review cycle led by the Management Team:
- Root Cause Identification: An exhaustive forensic analysis outlining the system behavior, configuration flaw, or human element that permitted the event.
- Corrective Action Plan (CAP): Detailed engineering assignments and process controls designed to eliminate the systemic flaw and completely prevent recurrence.
- Lessons Learned Data Capture: Aggregating takeaways and timeline insights to refine general detection and resilience thresholds.
Effectiveness Evaluation
The long-term value of an incident response is evaluated during a mandatory Lessons Learned Review Meeting. Attended by the Management Team and all relevant technical stakeholders, this review uses a structured four-question model:
- What happened? Establish a precise, chronological, and uncontested baseline description of the incident.
- What went wrong? Identify specific control failures, detection delays, or operational bottlenecks within our response cycle.
- How could this have been prevented? Determine what automated rules, policies, or systemic boundaries could have proactively minimized this risk.
- How will we prevent similar issues in the future? Define explicit, long-term preventative controls and assign corresponding PBIs for platform integration.
The outputs of this meeting are formally documented within the lessons learned section of the report.