1. INTRODUCTION
There are several regulatory frameworks that include the obligation to notify security breaches, and in the case we are addressing, the GDPR.
For efficient management of security breaches, the data controller must implement Internal Security Policies, which will include, in addition to incident response procedures, action plans, and other mechanisms to manage incidents.
The GDPR defines a personal data breach as any security breach that results in the accidental or unlawful destruction, loss, alteration, unauthorized disclosure, or access to personal data transmitted, stored, or otherwise processed.
In the event that MARFEEL SOLUTIONS, S.L., hereinafter MARFEEL, acts as a data processor, it must also establish similar procedures for managing incidents related to these data processing activities on behalf of third parties, ensuring proper communication with the data controllers.
2. RESPONSIBLE PARTIES FOR MANAGEMENT AND NOTIFICATION
This internal management procedure is understood as a proactive responsibility measure. The individuals listed below will participate in and collaborate on the management of the security incident.
The individuals authorized to manage incidents and security breaches affecting data within the organization are as follows:
Position: CEO
Contact Information: xavi.beumala@marfeel.com
Position: Systems Director
Contact Information: joan.tomas@marfeel.com
Position: DPO
Contact Information: dpo@marfeel.com
Therefore, in the event of detecting an incident or security breach affecting personal data in accordance with the provisions of this protocol, the individual(s) listed in this section should be contacted immediately, and in any case, always within the same day the security incident was identified.
Once the incident has been reported to one of the individuals listed in this section, the Investigation Committee will be convened, consisting of the CEO, Systems Director, and the DPO as permanent members, as well as any staff members called by the permanent members of the Committee who can provide technical support and collaborate in investigating the security breach. The purpose of the Committee is to determine whether it constitutes a security breach, whether it needs to be reported to the supervisory authority, and what measures should be implemented to mitigate or contain the incident immediately, as well as action plans to prevent future breaches.
3. PHASES IN SECURITY BREACH MANAGEMENT
I. Detection and identification of the incident
II. Collection and analysis of information related to the breach
III. Classification of the security breach
IV. Investigation, communication, and coordination of the involved internal/external parties.
V. Response plan
VI. Breach notification
VII. Security breach logging
I. Detection and Identification of the Incident
The detection of security incidents or breaches must be established as an ongoing procedure, enabling the identification of mechanisms to detect events that constitute security incidents. The situations considered security incidents and the alert systems that MARFEEL will use to detect incidents should be specified.
The identification of a security incident may occur through internal or external sources:
Internal sources:
- Physical controls such as intrusion detection, video surveillance, access control and registration to specific areas, etc.
- Clean desk policies, screen locking, user and password access, etc.
- Procedures for environmental damage or natural disasters.
- Cybersecurity:
- Alerts generated by antivirus, antimalware, firewalls
- Excessive memory or disk usage on servers and equipment
- Network traffic anomalies or spikes at unusual hours
- Intrusion detection/prevention system alerts
- Event correlation system alerts
- Log analysis of connections through corporate proxies or blocked connections in firewalls
- Server and application log analysis with unauthorized access attempts
- Data Loss Prevention (DLP) tool log analysis
External sources: Incidents arising from external treatments performed by third parties to provide a service to the data controller or processors, by a client, or through communication to third parties (data sharing), both private and public entities (INCIBE, CCN), Law Enforcement Agencies, or even information published on public sources, social media, or news outlets.
The analysis carried out during detection will determine whether we are dealing with a security incident, its nature, type, and whether personal data has been affected, thus constituting a personal data breach as described in the GDPR, as well as the level of risk MARFEEL is facing.
II. Collection and Analysis of the Breach
It is particularly important to determine whether a security breach has indeed occurred, in which case it is essential to assess the potential harm the incident may cause to the rights and freedoms of the affected individuals, determining as accurately as possible the severity of the consequences for the individuals involved.
- Threat type
- Context or origin of the threat (internal or external)
- Security category of the affected systems and data
- Profile of affected users
- Number and type of affected systems
- Impact of the incident on the company and on the rights and freedoms of the affected individuals
- Legal and regulatory requirements
- Attack vector or method (path through which the incident occurred)
Managing the security breach will require determining the potential danger of the incident and estimating the potential impact on individuals.
Any user who becomes aware of a security breach affecting MARFEEL’s data, or who suspects one has occurred, must report it immediately via email to the persons indicated in Section 2 of this protocol, i.e., the Data Protection Officer or the General Director at the following email address: hello@marfeel.com. If possible, the attached form in this protocol as Annex I.pdf (47.4 KB) should be completed when reporting the Security Breach.
Subsequently, the company’s management, along with the DPO and IT department, will carry out a detailed analysis of the incident, which will be documented using the template provided in Annex II.pdf (104.6 KB) (breach analysis template). For illustrative purposes, an example of a security breach analysis is attached in Annex III.pdf (58.0 KB)
Assessment of the Danger of the Security Breach:
The danger will depend on the following factors:
- Category or level of criticality regarding the security of the affected systems:
Following a generic classification, we can distinguish between:
- Critical (affects valuable data, large volume, and in a short time)
- Very High (can affect valuable information in a considerable amount)
- High (can affect valuable information)
- Medium (can affect a significant amount of information)
- Low (little or no ability to affect a significant amount of information)
- Nature, sensitivity, and categories of the affected personal data:
- Low-risk data: contact data, educational, family, professional, biographical
- Behavioral data: location, traffic, habits, and preferences
- Financial data: transactions, positions, income, accounts, invoices
- Sensitive data: health, biometric data, data related to sexual life, etc.
- Readable/unreadable data: data protected through pseudonymization (e.g., encryption or hashing)
- Volume of personal data: expressed in quantity (records, files, documents) and/or time periods (one week, one year, etc.)
- Ease of identification of individuals: how easily individuals can be identified based on the data involved in the breach.
- Severity of consequences for individuals:
- Low: Individuals will not be affected or may face inconveniences that will be easily overcome (data re-entry, mild irritation, etc.)
- Medium: Individuals may experience significant inconveniences, but can overcome them with difficulty (additional costs, denial of access to commercial services, stress, minor physical ailments, etc.)
- High: Individuals may face serious consequences, but should be able to overcome them, though with considerable difficulty (misappropriation of funds, blacklisting by banks, property damage, job loss, health deterioration, etc.)
- Very High: Individuals may face significant or even irreversible consequences that cannot be overcome (social exclusion, financial difficulties such as substantial debts or inability to work, long-term psychological or physical ailments, death, etc.)
- Special characteristics of the individuals: If the breach affects individuals with special characteristics or needs.
- Number of affected individuals: Within a specified range, for example, more than 100 individuals.
- Special characteristics of the data controller (the entity itself): Based on the entity’s activity.
- Profile of affected users, their position in the entity’s organizational structure, and consequently their access privileges to sensitive or confidential information.
- Number and type of affected systems.
- Impact the breach may have on the organization: From the perspectives of information protection, service delivery, legal compliance, and/or public image. This will be related to the category or criticality of the affected services and individuals. We distinguish between the following impacts:
- Low (limited harm)
- Medium (severe harm)
- High (very severe harm)
- Legal and regulatory requirements: Notification of the breach to the supervisory authority and any other notification obligations, such as communication to Law Enforcement in case of a crime.
III. Classification of Security Incidents:
In this phase, each security breach affecting personal data will be identified based on classic security criteria, using all information provided by detection means and any additional information collected:
a) Breach of Confidentiality: Unauthorized disclosure or access to personal data.
b) Breach of Integrity: Unauthorized alteration of personal data.
c) Breach of Availability: Accidental or illegal destruction or loss of personal data.
IV. Investigation, Communication, and Coordination of Internal/External Involved Parties
It is important to have a clear plan in place for how to handle a security incident, who will be responsible for each task, and how incidents will be escalated to the appropriate internal or external teams. In some cases, the response might rely mostly on external resources (as is the case for small and medium-sized businesses), but in others, it will be primarily internal. In either case, communication and coordination among teams must be smooth and efficient.
V. Response Plan
The data controller must develop action policies for managing incidents. The response plan must include immediate actions for containment, aiming to minimize the damage caused by the incident. For example, if a computer is infected, it should be disconnected from the corporate network immediately, or if information has been wrongly disseminated online, it should be removed. These measures also provide time to develop an appropriate solution without the pressure of time constraints.
During the response phase, the incident will initially be contained, then the situation will be eradicated, and recovery actions will be completed.
5.1. Containment of the Incident
5.2. Eradication
5.3. Recovery
5.4. Collection and Custody of Evidence
5.5. Communication / Resolution Report (Internal / External)
5.1. Containment of the Incident
At the initial stage of the response phase, MARFEEL will apply suitable containment measures to control or limit the initial consequences of the incident while facilitating the development of a global response strategy. These measures may be immediate or progressively applied depending on the progress of the incident resolution. Some measures will be simple and can be applied by the user, while others, more complex, should be applied by the Security Officer, IT Officer, or CTO.
Examples of containment measures that MARFEEL may apply, depending on the incident:
- If possible, prevent access to the source of the disclosure: domains, ports, servers, the source, or the recipients of the disclosure. Depending on the attack vector, prevent access to the origin: domains, connections, computers or remote connections, ports, patches, software updates (antivirus, IDS, etc.), block traffic, disable devices, servers, etc.
- Suspend logical and physical credentials with access to privileged information. Change all privileged user passwords or ensure users change them securely.
- Clone the system, create a bit-by-bit copy of the hard drive containing the system, and then analyze the copy using forensic tools.
- Isolate the system used to reveal the data for later forensic analysis.
- If data has been sent to public servers, request that the owner (or webmaster) remove the disclosed data.
- If it is not possible to remove the disclosed data, provide a full analysis to the relevant department (Legal, Compliance, HR, etc.) or whoever performs such functions in the company.
- Monitor the dissemination of the leaked documents/data on various websites and social networks (Facebook, Twitter, etc.) as well as the comments and reactions from internet users.
5.2. Eradication
To resolve the effects of the incident, eradication measures are necessary. The data controller, through the Security Officer, IT Officer, or CTO, must set a deadline for implementing eradication measures.
After applying the eradication measures, their functionality will be checked, and their effectiveness in eradicating the incident will be evaluated.
The measures applied may be permanent or temporary to ensure that the vulnerability has been eliminated, and the security incident will not recur in the future.
Examples of eradication measures:
- Define the disinfection process, based on signatures, tools, new versions/updates of software, etc., and test it. Ensure that the disinfection process works properly without damaging services.
- Verify the integrity of all data stored in the system using methods like hashing to guarantee that files have not been altered, paying special attention to executable files.
- Review the correct planning and updating of antivirus engines and signatures.
- Run antivirus scans on the entire system, hard drives, and memory.
- Gradually restore connections and privileges, with special attention to the gradual access to remote or unmanaged machines.
5.3. Recovery
The recovery phase’s main goal is to restore the service after confirming the effectiveness of the contingency and eradication measures taken. This phase will also incorporate periodic controls that allow for monitoring processes to prevent security incidents based on the same cause and reduce the risk of recurrence.
Stages:
i. Select a future strategy based on the risk MARFEEL is willing to accept.
ii. Implement the measures based on the strategy chosen by MARFEEL.
iii. Verify recovery by ensuring that the situation is restored to the pre-incident state and implement additional periodic controls to prevent future incidents of the same nature or origin.
5.4. Collection and Custody of Evidence
For evidence to be used in third-party proceedings (litigations or administrative procedures), it will be necessary to systematically collect and preserve such evidence.
In this regard, MARFEEL will collect information related to the incident based on:
i. The need to use the information by MARFEEL during the breach detection phase.
ii. Establish a chain of custody to ensure proper classification and archiving of the evidence.
5.5. Communication / Resolution Report
The incident resolution and response process must be documented and recorded. The report should include at least the following information:
i. Scope and impact of the incident.
ii. Existing preventive controls.
iii. Response actions taken regarding different alternatives considered for resolving the breach.
iv. Actions taken to prevent future breaches.
v. Impact on the incident resolution of the response actions taken.
vi. Actions defined for follow-up.
This report may share information and be linked or merged with the Internal Incident Register.
VI. Breach Notification
6.1. Notification to the Supervisory Authority
In the event of a personal data security breach, the data controller must notify the competent supervisory authority without undue delay and, where possible, no later than 72 hours after becoming aware of it, unless it is unlikely that the breach would pose a risk to the rights and freedoms of individuals.
If notification is not possible within 72 hours, an indication of the reasons for the delay must be provided, and information can be provided in phases without further undue delay.
The data controller must communicate to the supervisory authority along with information about the corrective security measures adopted to control the potential contingencies produced, specifically:
i. Information on the nature of the breach.
ii. Identification of the affected data, approximate number of affected individuals, categories, and approximate number of affected records.
iii. Corrective measures taken.
iv. Possible consequences.
v. Whether notification to the supervisory authority is necessary.
vi. Contact details for further information.
The data controller will notify the individual without undue delay if the breach is likely to result in a high risk to their rights and freedoms, allowing them to take necessary precautions. The notification must describe the nature of the personal data security breach and provide recommendations for the affected individual to mitigate any potential adverse effects. Notifications to individuals must be made as soon as reasonably possible and in close cooperation with the supervisory authority, following their guidance or that of other competent authorities, such as law enforcement.
Similarly, it must be verified whether adequate technological protection has been applied, and appropriate organizational measures taken to promptly determine if a breach has occurred and to inform both the supervisory authority and the individual without undue delay. It must be verified that the notification has been made without undue delay, considering, in particular, the nature and severity of the breach and its adverse effects on the individual.
This notification may result in an intervention by the supervisory authority in accordance with the functions and powers established by the Regulation.
6.2. Notification to the Data Subject
When the breach of personal data security is likely to pose a high risk to the rights and freedoms of individuals, the data controller will notify the data subject without undue delay.
The notification to the data subject will describe the nature of the breach in clear and simple language and must contain at least the following information:
The notification must include, at a minimum:
i. Communicate the name and contact details of the data protection officer or another contact point where further information can be obtained;
ii. Describe the possible consequences of the breach of personal data security;
iii. Describe the measures adopted or proposed by the data controller to address the breach, including, where applicable, measures taken to mitigate any negative effects.
However, the communication to the data subject will not be necessary if any of the following conditions apply:
i. The data controller has implemented appropriate technical and organizational protection measures, and these measures have been applied to the personal data affected by the breach, particularly those that make the data unintelligible to anyone not authorized to access them, such as encryption.
ii. The data controller has taken further measures to ensure that the high risk to the rights and freedoms of the data subject is no longer likely to materialize.
iii. It would involve a disproportionate effort. In this case, a public communication or similar measure will be used to inform the data subjects in a way that is equally effective.
If the data controller has not yet communicated the personal data breach to the data subject, the supervisory authority, after considering the likelihood of the breach resulting in a high risk, may require the controller to do so or may decide that any of the above conditions apply to not require notification.
If the breach has been resolved or mitigated in a way that no longer constitutes a significant risk, the notification to the individual will not be necessary, and the controller will determine the appropriate steps in the notification process
6.3. Exceptions to Notification
Notification to the Supervisory Authority will not be required when the data controller can provide evidence that the personal data security breach does not pose a risk to the rights and freedoms of individuals.
Additionally, communication to affected individuals will not be necessary when: a. The controller has implemented appropriate technical and organizational measures, such as ensuring that the data is unintelligible to unauthorized persons or machines before the personal data security breach occurs (for example, through the use of state-of-the-art data encryption, data minimization, data anonymization, access to test environments without real data, etc.). b. For instance, notification may not be required if a mobile device is lost and the personal data it contains is encrypted. However, notification may still be required if this was the only copy of the personal data, or if the encryption key in the possession of the controller was compromised. c. The controller has taken post-breach protective measures to fully or partially mitigate the potential impact for the affected individuals and ensures that there is no longer a risk of the high-risk scenario materializing. For example, by identifying and immediately implementing measures against the individual who accessed the personal data before they could use it. d. When notification to the affected individuals would involve disproportionate technical and organizational effort. For example, if contact details were lost as a result of the breach, or if a new system or process would need to be developed to make the notification, or excessive internal resources would be required to identify the affected individuals. In such cases, the notification will be made publicly through the channels established by the controller.
VII. Internal Incident Register
Another obligation for the data controller is the record-keeping requirement established by Article 33 of the GDPR, which mandates the creation of an Internal Incident Register, as shown in Annex IV.pdf (36.1 KB)
The data controller must document any personal data security breach, including facts related to it, its effects, and the corrective measures taken. This documentation will allow the supervisory authority to verify compliance with the provisions of this article.
In relation to a personal data security breach, the controller must record the following information:
- Type of incident
- Time when the incident occurred
- Person who made the notification
- Effects resulting from the notification
- Effects of the incident
- Corrective measures applied
The incident register will be kept up to date by MARFEEL at all times.