Skip to main content
QMSQMS
QMS
  • Welcome to your QMS
  • Quality Manual
  • Procedures
    • GP-001 Control of documents
    • GP-002 Quality planning
    • GP-003 Audits
    • GP-004 Vigilance system
    • GP-005 Human Resources and Training
    • GP-006 Non-conformity, Corrective and Preventive actions
    • GP-007 Post-market surveillance
    • GP-008 Product requirements
    • GP-009 Sales
    • GP-010 Purchases and suppliers evaluation
    • GP-011 Provision of service
    • GP-012 Design, Redesign and Development
    • GP-013 Risk management
    • GP-014 Feedback and complaints
    • GP-015 Clinical evaluation
    • GP-016 Traceability and identification
    • GP-017 Technical assistance service
    • GP-018 Infrastructure and facilities
    • GP-019 Software validation plan
    • GP-020 QMS Data analysis
    • GP-021 Communications
    • GP-022 Document translation
    • GP-023 Change control management
    • GP-024 Cybersecurity
    • GP-025 Corporate Governance
    • GP-050 Data Protection
    • GP-051 Security violations
      • Templates
    • GP-052 Data Privacy Impact Assessment (DPIA)
    • GP-100 Business Continuity (BCP) and Disaster Recovery plans (DRP)
    • GP-101 Information security
  • Records
  • TF_Legit.Health_Plus
  • Licenses and accreditations
  • External documentation
  • Procedures
  • Records
  • Procedures
  • GP-051 Security violations

GP-051 Security violations

Definitions​

  • AWS: Amazon Web Services
  • AEPD: Spanish Data Protection Agency (Agencia Española de Protección de Datos)
  • EC2: Elastic Compute Cloud
  • GPDR: General Data Protection Regulation
  • SSH: Secure Shell protocol
  • VPC: Virtual Private Cloud

Security breaches​

Data security violations, or security breaches, are defined in the GPDR in a very broad way, and include any incident that causes the accidental or unlawful destruction, loss or alteration of personal data transmitted, stored or otherwise processed. form, or unauthorized communication or access to such data.

However, for personal data protection purposes, only those security violations that entail a violation of compliance with this regulation would be noteworthy: this is because, although personal data violations are a type of security incident, Not all security incidents are necessarily personal data breaches.

Thus, we can highlight that personal data violations can be classified:

  1. Breach of confidentiality: when there is an unauthorized or accidental disclosure of access to personal data.
  2. Violation of availability: when there is an accidental or unauthorized loss of access or destruction of personal data.
  3. Integrity breach: when an unauthorized or accidental alteration of personal data occurs.
  4. Resilience breach: when it is not possible to quickly restore the availability and access to personal data in the event of a physical or technical incident.

This classification is not exclusive, in such a way that it can lead to the security violation being a combination of the previous ones. This classification also serves as the basis for risk prevention (risk analysis).

To proceed to examine the existence of a security breach, it will be necessary to take into account the circumstances surrounding it, since, for example, an incident that prevents the availability of the data for a certain time constitutes a security breach, which, however, can not require a notification to the control authority or to the affected party, depending on whether or not this lack of availability has an impact on a risk to rights and freedoms, and must be evaluated on a case-by-case basis, taking into account all the possible consequences of a breach.

In addition, it should be noted that, although the loss of data availability may be temporary and may not have an impact on individuals, the fact that there may have been an intrusion into the systems may be considered a possible breach of confidentiality. in this case, notification may be necessary.

For this reason, the standard requires that a record be kept of all security violations that occur in the organization, in such a way that knowledge of their existence can prevent future non-compliance and provide an adapted and efficient response.

When a breach of data security occurs, the data controller must notify the AEPD, unless it is unlikely that the breach poses a risk to the rights and freedoms of those affected. In addition, in those cases where the security breach is likely to entail a high risk for the rights or freedoms of the data subjects, the notification to the supervisory authority must be complemented by a notification addressed to the latter.

The notification of the bankruptcy to the authorities must occur without undue delay and, if possible, within 72 hours after the person in charge becomes aware of it.

Examples of bankruptcies: the loss of a laptop, unauthorized access to an organization's databases (even by its own staff), or the accidental deletion of some records are security breaches under the GDPR and must be addressed as the Regulation establishes. In the first two examples, the pseudonymization or encryption of the information can be decisive when making decisions about whether or not it is necessary to inform the control authority (or even the interested parties).

In certain cases, the lack of notification to the control authority or to the interested parties, as the case may be, of a data breach, may be considered as a lack of security, of measures or inadequacy of the existing ones.

Communication of the security breach to the AEPD​

Deadline for notification​

  • Without undue delay.
  • Maximum of 72 hours since the record has been made.
  • After 72 hours, a reasoned justification must be attached.

Obligation to notify the violation​

It is mandatory for Legit.Health, whenever the security breach may cause damage or harm to the interested parties or third parties in the course of data processing, such as:

  • Loss of control over personal data.
  • Restriction of rights.
  • Discrimination.
  • Identity theft.
  • Financial losses.
  • Unauthorized reversal of pseudonymization.
  • Reputational damage.
  • Loss of confidentiality of data subject to professional secrecy.
  • Any other significant economic or social damage to the natural person.

It is recommended to consult immediately with our DPO by phone or email any security breach in order to determine whether or not it is mandatory to notify the AEPD, as well as to consult the improvement measures to be adopted.

Reasons for not reporting the violation​

  • When it is unlikely that the violation of personal data constitutes a risk to the rights and freedoms of the interested parties.
  • This improbability must be based on the principle of proactive responsibility: being able to demonstrate compliance with all treatment principles: Legality, Limitation of purposes, Minimization of data, Accuracy, Limitation of the period of conservation, Integrity and Confidentiality.

Notification content​

  • The nature and context of the violation.
  • The possible effects and consequences of the violation.
  • The corrective measures adopted or proposed by Legit.Health to remedy and mitigate the effects caused.
  • When it is possible:
    • The categories and number of interested parties affected.
    • The categories and number of records affected.
    • If it is the case, the identity and contact details of the Data Protection Officer (if applicable) or other contacts to obtain more information.
    • If it is not possible to provide all the information in one communication, it will be notified in stages without undue delay.

A written model is provided as Annex 8 to the Spanish Data Protection Agency, which is accessible from the "Documentation" - "Documents" panel.

Communication of the security breach to the interested party​

Deadline for notification​

  • Without undue delay.

Obligation to notify the violation​

  • It is mandatory for Legit.Health , when it is likely to present a high risk to the rights and freedoms of the data subject.
  • When Legit.Health is required by the Spanish Data Protection Agency.

It is recommended to consult immediately with our DPO by phone or email any security violation in order to determine whether or not it is mandatory to notify the interested party, as well as to consult the improvement measures to be adopted.

Reasons for not reporting the violation​

  • When appropriate technical and organizational protection measures have been adopted to make the data unintelligible to unauthorized persons and these have been applied to the affected data.
  • When subsequent steps have been taken to ensure that a high risk to the rights and freedoms of the data subject is no longer likely.
  • When it involved a disproportionate effort. In this case, you can opt for a public communication that is equally effective to inform the interested party.

Notification content​

  • A description of the nature of the violation.
  • The possible consequences of the violation.
  • The corrective measures adopted or proposed by the RT to remedy and mitigate the effects caused.
  • If applicable, the identity and contact details of the DPO or other contacts for further information.

Casuistry of security violations​

A written model is provided as Annex 9 to the Spanish Data Protection Agency, which is accessible from the "Documentation" - "Documents" panel.

A security breach can occur when, for any reason, whether intentional or not, the security of the data is breached or it is anticipated that it may entail a HIGH RISK for the rights and freedoms of natural persons.

Unauthorized data access​

  • Order of the treatment without the corresponding contract.
  • Indiscriminate access to printers, photocopiers, etc.
  • Unauthorized access to confidential information. For ex. to payroll data, resumes, liens, video surveillance images, etc.
  • Unauthorized access to computer systems.

Unauthorized data communication​

  • Illicit transmission of data to a RECIPIENT.
  • Violation of professional secrecy.
  • Publication of images without the authorization of the INTERESTED PARTY.
  • Sending mass emails without hiding the recipients (blind copy).
  • International data TRANSFER without being subject to an EU Sufficiency Decision or adequate data protection guarantees.

data alteration​

  • Malicious data modification.
  • Data falsification.
  • Inefficient recovery of backup copies.

Loss of information​

  • Lost or forgotten media.
  • Theft or theft of information.
  • Uninstalling computer applications.
  • For transportation reasons.
  • Company reorganization.
  • data destruction
  • Do not use a paper or digital media shredder.
  • Fire, flood or other causes beyond the control of the company.

Lack of security measures​

  • Antivirus, antispam, antimalware, antiransomware, fireware, encryption, pseudonymization, etc.
  • Identification and authentication to access computer systems.
  • Security mechanisms to access furniture or departments with personal data.
  • Provision of data in view of unauthorized persons (reception, monitors, tables, etc.).

Controls​

Review API events logs looking for suspicious actions​

Each account created in AWS has a log of the actions performed by the users of the account. These logs are stored in Cloud Trail of AWS:

https://eu-west-3.console.aws.amazon.com/cloudtrail/home?region=eu-west-3#/dashboard

The logs can be filtered by user, date, service and IP. So it is possible to identify suspicious actions.

Cloud Trail also offers the possibility of seeing insights of the actions performed in the last 90 days. AWS CloudTrail Insights helps AWS users identify and respond to unusual activity associated with API calls by analyzing CloudTrail management events.

https://eu-west-3.console.aws.amazon.com/cloudtrail/home?region=eu-west-3#/insights

Responsable​

Gerardo Fernández Moreno

Periodicity​

Each two weeks.

Criteria for acceptance​

The logs are reviewed and no suspicious actions are detected:

  • Each user is connecting from the expected IP.
  • Users are performing the expected actions.

List of unexpected actions:

  • Changing other user's credentials.
  • Creating new users with administrator permissions.
  • Accessing resources that are not part of the project.
  • Deleting critical resources as buckets, databases or EC2 instances.

Review defined security groups​

The security groups are a set of rules that allow or deny access to the resources of the project. The security groups are defined in the VPC of AWS and can be found in the following link:

https://eu-west-3.console.aws.amazon.com/ec2/home?region=eu-west-3#SecurityGroups:

Each resource should only have the minimum required security groups attached, so the access to that resource is limited to only the IP's that are necessary.

Responsible​

Gerardo Fernández Moreno

Periodicity​

Each 6 months.

Criteria for acceptance​

All the resources in AWS have the minimum required security groups attached. An example of an unacceptable result would be finding a resource with:

  • IP's that don't need to have access to the resource.
  • A too wide range of ports open.
  • Old IP's that are no longer used.

EC2 instances have their packages updated to last version​

In order to prevent security vulnerabilities, the EC2 instances should have their packages updated to the last version.

Responsable​

Gerardo Fernández Moreno - All instances related to the application. Alfonso Medela: All instances related to the data science team.

Periodicity​

Each month.

Criteria for acceptance​

All the EC2 instances show the following message when are accessed by SSH:

0 updates can be applied immediately.

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

  • Author: Team members involved
  • Reviewer: JD-007
  • Approver: JD-001
Previous
SP-050-003 Data sharing
Next
Templates
  • Definitions
  • Security breaches
  • Communication of the security breach to the AEPD
    • Deadline for notification
    • Obligation to notify the violation
    • Reasons for not reporting the violation
    • Notification content
  • Communication of the security breach to the interested party
    • Deadline for notification
    • Obligation to notify the violation
    • Reasons for not reporting the violation
    • Notification content
  • Casuistry of security violations
    • Unauthorized data access
    • Unauthorized data communication
    • data alteration
    • Loss of information
    • Lack of security measures
  • Controls
    • Review API events logs looking for suspicious actions
      • Responsable
      • Periodicity
      • Criteria for acceptance
    • Review defined security groups
      • Responsible
      • Periodicity
      • Criteria for acceptance
    • EC2 instances have their packages updated to last version
      • Responsable
      • Periodicity
      • Criteria for acceptance
All the information contained in this QMS is confidential. The recipient agrees not to transmit or reproduce the information, neither by himself nor by third parties, through whichever means, without obtaining the prior written permission of Legit.Health (AI LABS GROUP S.L.)