Security Events

For the purpose of information security in Agile Lab's systems, the Company adopts the following policy and stipulates that the dedicated CSIRT (Computer Security Incident Response Team), appointed due to, and in accordance with, NIS2 Directive, which also performs the functions of Business Continuity Officer in accordance with ISO 22301, constitutes the "Incident Response Team" functional to this policy. It is composed of representatives from the main technical and operational areas of the Company.

This procedure pertains to any event that is potentially capable of causing a breach, loss, and/or alteration of information stored in Agile Lab's computer systems and/or managed by Agile Lab on behalf of its clients, including but not limited to:

• Malware and DDoS attacks
• Unauthorized access
• Internal violations
• Unauthorized privilege escalation
• Theft or loss of devices

If the incident is potentially capable of constituting a "data breach" as defined in Article 35 of the GDPR, the Incident Response Team will inform the Legal Representative of the Company, the Lead link of the Legal and Internal Compliance Circle and the DPO to initiate the corresponding procedure.

Assessment and Decision

Within 24 hours of the event, the Incident Response Team will provide the Compliance Team with a report on the relevant incident and the possible technical actions.

The incident closure report is an internal document that provides a summary of the following information:

• Date and time of incident closure report communication
• Detected events that led to the opening of the incident record
• Date and time of incident management record opening
• List of investigations conducted to detect and circumscribe the perimeter within which the security breach of ICT (Information and Communication Technology) was identified
• List of damages suffered
• References to evidence substantiating the identification of the damages, without attaching the evidence itself
• Detailed list of ICT assets that have suffered damages (systems, devices, technology chains, applications, etc.)
• Summary of observed SLAs (Service Level Agreements) during the incident management process and possible justification for any delays caused

Once the ICT assets affected by the event and the associated attack category have been identified, ICT security operators assess the impact of the violation on the ICT assets and/or the information assets of Agile Lab. They use the following evaluative scale:

• Severe: Indicates a violation of ICT security policies that results in permanent and irreversible damage to ICT assets and/or Agile Lab's information assets
• Relevant: Indicates activities associated with the detection of ICT security violations that result in temporary and reversible damage to ICT assets and/or Agile Lab's information assets
• Significant: Indicates activities associated with the detection of attempted ICT security violations that do not pose a direct threat to ICT assets and/or Agile Lab's information assets. This category includes anomalous user behaviors and applications that do not require specific containment measures, except for monitoring to prevent or contain any subsequent attacks
• False positive: Indicates theoretically malicious events that do not result in any ICT security violation in the specific context under examination. If events are identified as false positives, the alarm classification process is terminated, and the possibility of filtering such events from the tracking systems should be considered to avoid overburdening incident management activities with repetitive operations. Otherwise, the alarm is classified, and all subsequent activities related to alarm or incident management are carried out

The Compliance Team is responsible for determining whether an incident has occurred and indicating the remedial actions to be taken.

The criticality assessment of the ICT asset, expressed on a three-value scale (High, Medium, Low), includes analytical activities aimed at evaluating the criticality of the context in which security violation events have been detected. The criticality value of the asset can be derived from the classification of the provided service, determined through appropriate Risk Assessment activities performed on ICT assets, or based on evaluations of the information processed by the systems.

Detection and Reporting

In the event of a potential incident, the Compliance Team of the Company must be immediately notified, no later than 5 hours, at compliance@agilelab.it, which will verify the activation of this procedure.

The above will be recorded in the Data Breach Register maintained by the Company.

Responses

The Incident Response Team will monitor the execution of incident remediation actions, if necessary, and provide written updates to the Compliance Team on a periodic basis.

Lessons Learned

Within 30 days of the incident, the Compliance Team will assess possible improvements and implementations to internal procedures to prevent the recurrence of the same incident.

NIS2 Incident Management and Notification Obligations

• Any event that may significantly affect the availability, integrity or confidentiality of network and information systems used by Agile Lab for the provision of services must be treated as a NIS2 Security Incident, even if no personal data is involved
• In the event of a potentially NIS2-relevant incident, the Internal Computer Security Incident Response Team (Internal CSIRT) must activate the NIS2 notification workflow and immediately inform the Compliance Team
• Where required under NIS2, Agile Lab shall ensure notification to the competent authority/CSIRT Italia as follows:
  • Early Warning within 24 hours of becoming aware of the incident
  • Incident Notification within 72 hours, including the initial impact assessment and mitigation actions
  • Final Report within one month
• When Agile Lab acts as a supplier or Processor, it shall notify the client without undue delay to enable the client to fulfil its own NIS2 regulatory obligations

Communication Flows to the Parent Company

• All incidents classified as Severe, Relevant, all GDPR personal data breaches, and all events that may constitute significant NIS2 incidents must be reported without delay to the Parent Company through the designated communication channels
• The Internal CSIRT shall provide periodic updates to the Parent Company until the incident is fully resolved and shall supply any documents, technical assessments or audit-related information requested
• The Parent Company may request additional verification activities, forensic analysis or corrective measures as part of its supervisory role

Internal Notification Timeframes (NIS2 + Governance)

• Any potential security incident must be reported to the Compliance Team immediately and in any case no later than 5 hours
• Such internal notification activates both the general Incident Management Procedure and, when applicable, the NIS2 notification workflow

Incident Recording

• All NIS2-relevant security events must be logged in the Security Incident Register, alongside GDPR data breaches recorded in the Data Breach Register
• The entry must include the rationale for NIS2 classification, expected impact and containment actions taken

Integration to the "Lessons Learned" Section - NIS2 and Group Oversight

• Within 30 days of incident closure, the Compliance Team shall assess the adequacy of the NIS2 controls applied and identify preventive or corrective actions
• Where required, the Lessons Learned Report shall be communicated to the Parent Company for alignment and supervisory purposes