Security Measures

This page was last modified April 20, 2023.

Mindler implements technical and organisational measures to ensure an appropriate level of security and the protection of Personal Data, taking into account the nature, scope, context and purpose of the processing, and the risks for the rights and freedoms of natural persons.

Mindler may update or modify these security measures from time to time provided that such updates and modifications do not result in the degradation of the overall security of the Service.

1. Measures for ensuring ongoing confidentiality, integrity, and availability and resilience of processing systems and services.

1.1 Confidentiality

Confidentiality is ensured by using encryption on application level and encryption at rest, on database level, enabled. 

Roles and permissions, as described in section Security Levels section, manages accessibility to this data. 

Most services use BankID where possible, which makes password management within Mindlers domain obsolete. The password policy describes how password services should be implemented in a secure way in the cases where BankID is not a valid approach. For markets that do not use BankID our goto solution is similar services, such as AWS Cognito. 

Additionally, Mindler requires sub-processor to sign confidentiality provisions.

1.2 Integrity

In order to ensure data integrity AWS multi account strategy is implemented.

The data interface with the journal system is unidirectional. This means that it is only possible to insert data into the journal system, but no service is pulling out any data in order to minimize the scattering of sensitive data. 

Data sync services insert data about the booking that the journal system needs, e.g start time, the name and national identity of the patient. It’s a requirement  that these services use authentication before any data can be interchanged.

In order to ensure data integrity audit logs on application level are in place for all actions with journal data. For data integrity from developers audit logs on database level are in place for all actions with journal data.

For services that Mindler builds the database audit logs are piped to another AWS audit account where users have read-only access. This ensures that no developer can hide their traces by deleting logs. 

For third party medical storages, such as WebDoc or Medicore, the same type of mechanisms are ensured through technical reviews before any integration is built. 

In order to ensure data integrity from administrators or psychologists a journal cannot be changed after it is signed. This is implemented on application level.

1.3 Measures for Service Availability

When doing deployments the general approach is to roll through, rather than roll back. In the system there is a monolithic API that is deployed on elastic beanstalk with autoscaling. Whenever a new deployment is executed the instance rolls over to the new version with zero downtime. In case it seems too risky to roll through, a rollback can be done to a previous version through the AWS console or the deployment system. 

For microservices it’s much easier since they are smaller components that are released independently. Should there be any issues with a micro service it will only affect a small portion of the system.

Services in the system are capable of running independently, with partial downtime. If the API should go down, it is still possible to work with the journal system, vice versa. The same is true for ongoing video calls. A video call will be unaffected by issues in the journal system. 

In order to improve this even further the development team has a clear strategy to split up applications into micro services for improved resilience.

1.4 Measures for data resilience

All production databases have automatic snapshots that are taken once a day. The retention time is 35 days, which is the maximum daily restore availability AWS offers at the time of writing this document. 

Restoring backups are practiced about every 6 months and at least every year. These activities are logged with participants with executed and coming practices. Documentation is updated after each exercise. In case of employee churn practices can take place more often. 

1. Measures for internal IT and IT security governance and management

Mindler maintains a risk-based assessment security program. The framework for Mindler’s security program includes administrative, organizational, technical, and physical safeguards reasonably designed to protect the Services and confidentiality, integrity, and availability of Customer Data. 

Security is managed at the highest levels of the company.

Information security policies and standards are reviewed and approved by management at least annually and are made available to all Mindler employees for their reference by request.

2. Measures for user identification and authorization.

Mindler employees are required to use unique user access credentials and passwords for authorization.

Multiple factor authentication is required throughout the system. Mindler follows the principles of least privilege through role-based and time-based access models when provisioning system access. Mindler’s personnel are authorized to access Customer Data based on their job function, role, responsibilities and seniority. Access is promptly removed upon role change or termination.

3. Measures for ensuring physical security of locations at which personal data are processed.

Mindler’s headquarters and office spaces have a physical security program to monitor the overall office security.

The Services operate on Amazon Web Services (“AWS”) and Google Cloud (“GCS”) and are protected by the security and environmental controls of Amazon and Google, respectively.

Further information about AWS security is available at https://aws.amazon.com/security/ and http://aws.amazon.com/security/sharing-the-security-responsibility/.

For AWS SOC Reports, please see https://aws.amazon.com/compliance/soc-faqs/. Detailed information about GCS security is available at https://cloud.google.com/docs/tutorials#security.

4. Measures for certifications/assurance of processes and products

Mindler’s conducts third-party audits to address compliance with the security framework and penetration testing. 

Mindler implements the security framework towards ISO27001 and NEN7510 certifications.

5. Measures for ensuring limited data retention

Mindler operates under a strict data retention principle balanced with the obligations arising from the regulated nature of the service provided.

6. Measures for ensuring accountability

Mindler has adopted measures for ensuring accountability, such as implementing Data protection policies across the business, maintaining documentation of processing activities, recording and reporting Security Incidents involving Personal Data, and appointing a Data Protection Officer.

7. Measures for allowing data portability and ensuring erasure

Mindler will provide assistance to the Customer as may reasonably be required under Applicable Data Protection Laws to respond to requests from individuals to exercise their rights under Applicable Data Protection Laws (e.g., rights of data access, rectification, erasure, restriction, portability and objection).

8. Regulatory testing

Mindler has unit testing in place in all applications. These tests are reviewed by at least one other developer in code reviews. Before releases all tasks, as tracked, that are being released are manually tested by Quality assurance (QA). Some tests are fully automated and others semi-automated. 

9. Yearly penetration testing

Once every year a penetration test is executed by an external company. The goal of the pen-test is to identify vulnerabilities in the service that can be exploited in order to gain access to the system data or permissions. 

10. For transfers to sub-processors, also describe the specific technical and organisational measures to be taken by the sub-processor to be able to provide assistance to the controller and, for transfers from a processor to a sub-processor, to the data exporter

When Mindler engages a sub-processor under this Agreement, Mindler and the sub-processor enter into an agreement with data protection terms substantially similar to those contained herein. Each sub-processor agreement must ensure that Mindler is able to meet its obligations to the Customer. In addition to implementing technical and organisational measures to protect personal data, sub-processors must

a) notify Mindler in the event of a Security Incident so Mindler may notify the Customer;

b) delete data when instructed by Mindler in accordance with the Customer’s instructions to Mindler;

e) process data in a manner which conflicts with the Customer’s instructions to Mindler.

Summary

Mindler has implemented formal information security policies and procedures to address the services that they provide that describe the physical access to the data center, logical access, incident management, change management, and business continuity. Mindler communicates critical control roles and responsibilities through written policies and procedures including security, acceptable use, and privacy policies which describe the requirements for all employees with respect to maintaining data security and reporting company policy violations. 

All policies and procedures governing Mindler are reviewed and approved at least annually by the Company’s Management team. Mindler employees are required to review and acknowledge the relevant Company policies and procedures on hire. Employees receive yearly security and compliance awareness training to address specific and current security topics.