Incident management and corrective actions

Introduction

We have procedures in place for recording and following up on deviations and disruptions, and for reporting and handling security events, security incidents, and data breaches. Deviations are analyzed to determine their cause (root cause where applicable) and followed up with corrective measures, including effectiveness checks to prevent recurrence. Where relevant, we secure evidence through guidelines for the identification, preservation, and chain of custody of digital evidence.

Detailed explanation

Disruptions & corrective actions

Deviations can arise from internal or external audits, customer complaints, or process disruptions. They may indicate non-compliance with ISMS requirements or with relevant standard requirements (such as ISO/IEC 27001, ISO/IEC 27701 and NEN 7510).

The procedure is broadly as follows:

• Record and register the deviation (e.g., in ticketing systems such as Jira or Trengo).

• Discuss and assess with those involved.

• Determine the cause (root cause where applicable).

• Determine and implement corrective measures.

• After a period of time, evaluate whether the solution is effective.

The registration supports evaluation, continuous improvement, and annual monitoring of disruptions and evaluation (e.g., as part of management review).

Types of disruptions (distinction in classification)

Within this procedure, we distinguish between different types of events:

• Disruption (event): event that may affect the functioning of the ISMS (e.g., audit deficiency, critical procedure not followed).

• (IT) incident: disruption in information systems or information flows (e.g., bug), usually handled through the regular IT incident process.

• Information security incident: event that poses a threat to secure business operations and information security.

• Privacy incident/data breach: specific type of security incident in which personal data has been compromised.

For security incidents and data breaches, the specific incident procedure also applies (see below).

Security incidents & data breaches (fast, consistent, and learning-oriented)

We have a procedure in place for the fast, effective, and consistent handling of:

• Information security events: possible compromise of confidentiality, integrity, or availability (CIA).

• Information security incidents: CIA has actually been compromised.

• Data breaches: breach involving personal data.

Detection and reporting can originate from log files, reports, and signals from stakeholders (such as customers or suppliers). All employees and relevant external parties are required to report suspected weaknesses, events, or incidents so that registration and further analysis can take place.

External reporting and coordination expectations (chain context)

Where required by law, regulation, or contractual agreements, external coordination and reporting steps are ensured. We take into account that stakeholders (e.g., customers in the healthcare sector) may have additional incident reporting requirements. In addition, customers may be subject to regimes such as NIS2 or DORA; in such cases, additional expectations may apply regarding the reporting of (potential) incidents and escalation to competent authorities.

Additional steps in the event of data breaches

In the event of a data breach, additional steps apply. The Data Protection Officer (DPO), together with the Security Officer, takes immediate action. Further detailed operating instructions are available via the internal intranet to guide handling, assessment, and potential reporting obligations.

Evidence handling (digital forensics and chain of custody)

When evidence may be relevant (e.g., in the case of possible legal or disciplinary follow-up), it is important to secure as much relevant evidence as possible during (suspected) incidents and data breaches without altering or overwriting it.

Our evidence handling guidelines (based on ISO/IEC 27037, among others) describe:

• identification of possible sources of evidence (logs, metadata, screenshots, emails, network data, temporary memory/buffers)

• careful collection (methodical, preservation of original data and metadata, documenting who/what/where/when)

• preservation and secure storage (restricted access, encryption where appropriate)

• chain of custody (recording who had access and what actions were performed)

• analysis and reporting (systematic, reproducible, and, where necessary, understandable to non-technical stakeholders)

In doing so, we ensure that overwriting of backups and logs is prevented as much as possible so that evidence and reconstruction remain possible.