🔉 Technical and Organisational Measures (TOM)

Our Technical and Organisational Measure (TOM) document describes the security controls our organisation implements to protect personal data against risks such as loss, misuse, or unauthorized access. These measures include both technical safeguards (e.g., encryption, access controls, backups) and organisational practices (e.g., policies, training, incident response) to ensure compliance with data protection laws.

It's important to know that we are working with a ISO27001-certified ISMS, which covers the various topics in more detail. If you are interested in more information on our management system for information security, always get in touch.

In the following document we act from the perspective of the contractor working for clients.

Table of Contents

1. Pseudonymisation
   
   

2. Encryption
   
   

3. Guaranteeing confidentiality

   1. Entry monitoring

   2. Access monitoring

   3. Access control

      
      

4. Guaranteeing integrity
   
   

5. Separation control
   
   

6. Guaranteeing availability

   1. System availability

   2. Data availability
      
      

7. Deletion of data
   
   

8. Guaranteeing systems resilience
   
   

9. Procedures for the regular review, analysis and evaluation of the effectiveness of technical and organisational measures

1. Pseudonymisation

The Contractor pseudonymises data in the sense of data protection at various points. The Client transfers e-mail addresses and optionally the names of users or employees. Users can assign themselves a name and assume certain user roles. The user can optionally also set up a profile picture. In technical terms, each user is automatically assigned a unique user ID. This is a ten-digit number that is used in other parts of the system for the technical identification of individual users and which at the same time ensures that the user is represented in the system (for example in technically required logs or interfaces) by this user ID.  The relationship between the user name, e-mail and this user ID is stored encrypted in the database and access to it is available only to a few members of staff holding the relevant permissions (see Access concept).

In addition, we also appliy anonymisation procedures where appropriate (eg to track user behaviour in the app), so that clients can process or evaluate data without being able to trace it back to individual users.

2. Encryption

The platform sends the users an invitation to use the service through a link in the form of an e-mail. This link takes the user to a website. Once there, the user must create their own password during the login process which, together with their e-mail address, allows them to access the service as part of a classic registration process (within an app or on a website). When the password is being created, the user is shown whether the password is "Weak", "Moderate" or "Reasonably good". The aim is to point the user towards using a password that is as secure as possible. 

The strength of the password is communicated in various levels from "Weak" and "OK" to "Reasonably good". This is evaluated using an algorithm, which analyses the strength of a password based on various criteria. The minimum length of the password is 6 characters.

From the moment it is assigned, the password is only stored in encrypted form in the Client's database. Encryption based on the "PBKDF2“ (Password-Based Key Derivation Function 2)" standard is used for this. PBKDF2 is a standardised function for deriving a key from a password that can be used in a symmetrical process. PBKDF2 is part of the Public-Key Cryptography Standards of the RSA Laboratories (PKCS #5)[1], was also published in 2000 by the Internet Engineering Task Force in RFC 2898[2] and was officially recommended in December 2010 by the National Institute of Standards and Technology (NIST).

This encryption makes it much harder for unauthorised third parties to access the passwords. Even employees of the Client do not have any way of viewing the passwords. If a user forgets their password, they can only use the "Forgotten password" function. This generates an e-mail containing a link to create a new password. This e-mail is sent to the user's e-mail address.

Two-factor authentication would be possible from a technical perspective in principle, however the Client has not yet implemented it since it would require a second factor (e.g. a telephone number). 

The user data, e.g. the name and e-mail address, is stored in encrypted form in the database. Only the Managing Director and the Technical Director have the key to disclose it. 

For Internet-based and system-internal communication between clients and server components (e.g. between servers and apps), the Client uses only the secure HTTPS standard which is verified using an SSL certificate from one of the largest and most well-known providers of such certificates, Comodo (https://ssl.comodo.com/).

From a technical perspective, the Client's data is stored in a MySQL database operated by the cloud service provider AWS (of if you choose from german vendor Hetzner Cloud).

The cryptographic functions of MySQL support encryption, hashing and compression.  All of the data stored on AWS is protected by server-side encryption. AWS generates unique keys for each Amazon Glacier archive and then encrypts it with AES-256. The key is then encrypted with the help of a primary key using AES-256 and stored in a secure location. The master key is changed regularly. Only the Managing Director and Technical Director have access to the key.

The database service provider Amazon Web Services (AWS) also creates backup copies of all the data as part of its routine backup process (see Point 6.2. Data availability). This data is also only stored in encrypted form. 

For clients using Hetzner cloud server similar security measures are implemented.

3. Guaranteeing confidentiality
   
   

   3.1. Entry monitoring

The Client's premises are located in a mixed-use area of Berlin Kreuzberg (Germany). The building itself is owned by the Berlin Metal and Plastics Guild. The plot of land, which is surrounded by a fence, is only accessible via an access road from Köpenicker Strasse. This access road is closed after the office closes and at weekends. 

The business division is situated on the second floor in the building's second courtyard. The business division can also be accessed via the building entrance, through the courtyard and up the staircase. Access can also be gained via the lift. However, a key is required to use this lift, and this key is held by only two people (the Managing Director and Office Manager). 

The side wing has an emergency exit leading to a fire escape, through which the business division can be exited in the event of a fire, however it cannot be used to access the division since the safety doors can only be opened from the inside. All access doors to the building are open during business hours. After closing time and at the weekend, they are closed. Access to the building is also secured by a gate, which is closed from 8 p.m. onwards.

Visitors use the bell on the door to the business division, at the bottom of the staircase. The door is opened manually by an employee. Any unauthorised or unnoticed access to the business division is therefore impossible. Visitors only enter the office spaces when accompanied by a member of staff.

There are no keys held by persons external to the company and the office door is secured with a code. This code is changed on a monthly basis. The offices are cleaned outside office hours by permanently employed staff. Deputisation is arranged internally so that no cleaning staff from outside the company access the office spaces.

All employees have been made aware through data protection training that they are obliged to protect personal and confidential data against unauthorised access and to not leave external personnel unsupervised.

All doors and windows are burglar-proof. The external doors are burglar-proof and fitted with double locking cylinders. The locking cylinders are protected against drilling and removal.  The door to the business division is made from steel and is secured with an access code. The doors are also closed with a locking cylinder after the office closes. The code is changed monthly, preventing former employees from accessing the premises, for example.

The business facilities themselves do not contain any servers or other document storage devices on which sensitive user data could be kept. The Contractor stores the data from its platform on the cloud infrastructure provided by Amazon Web Services. AWS has implemented the following technical and organisational measures in order to protect the AWS facilities from unauthorised physical access. Currently, these measures include: 

• the data centres, servers, network equipment and host software systems (physical components of the cloud network) are accommodated in nondescript buildings. 

• The buildings of AWS and Hetzner are protected by physical security measures in order to prevent unauthorised access both to the outer perimeter (e.g. fence, walls) and to the buildings themselves. 

• Access to the server locations is managed via electronic access controls and secured by alarm systems that trigger an alarm if a door is broken open or held open. 

• Access rights are approved by an authorised individual and withdrawn within 24 hours after an employee's or supplier's record is deactivated. 

• All visitors must carry ID and register themselves and are always accompanied by an authorised member of staff.

• Access to sensitive areas is monitored by video surveillance. 

• Trained security officers patrol the AWS and Hetzner data centres and the immediate surroundings 24 hours a day, 7 days a week.

2. Access monitoring

The Contractor has implemented the following technical and organisational measures to protect the systems and data of tchop from authorised access. Currently, these measures include: 

• the principle of minimum necessary rights always applies. Every user is given only the access rights they need to carry out their contracted activities. User accounts are always initially given the least access rights possible. To grant access rights beyond the minimum entitlement, suitable authorisation must be provided. 

• User and administrator access to the cloud storage network, which stores all relevant data, is based on a role-based access rights model. Each user is given a unique ID in order to ensure that all system components can only be used by authorised users and administrators. 

• User access to the Contractor's services is only activated once the HR department has created a corresponding record in the HR system. 

• The employees' login passwords for relevant services are secret and are not stored in plain text in any location. Every user has the option to change their password in the individual system areas and application programs themselves. Employees are regularly instructed through data protection training in the need to use password conventions and are also obliged to comply with these. All passwords are made up of letters, numbers and at least one special character and are changed regularly. The password conventions, i.e. at least 8 characters, upper and lower case letters, digits and special characters and their validity is requested where possible by the operating system or applications.

• The workstation computers do not store any personal data or data requiring protection; all data is stored by the service providers in the cloud. The technicians' and employees' laptops contain only temporarily encrypted customer details that are required for development purposes.

• A password-protected screensaver is enabled on all workstations, which switches on automatically after a period of max. 15 minutes elapses. This prevents any unauthorised use during the employee's absence.

• Access rights to the tchop IT system are removed within 5 minutes of an employee's record being deactivated in the HR management system. This includes both access to the relevant company e-mail account and all other accesses. Security-relevant accesses are kept secure by the management team (see the principle of minimum rights above). If an employee leaves, all accesses are disabled or blocked by the administrator.

• The Internet is accessed via a router with an integrated firewall and dynamic content filter. Configuration of the local firewall is possible only by an authorised group of people. The router configuration can be changed via remote access for maintenance purposes, for essential security updates, for instance, to change the authorised group of individuals, for VPN accesses, and so on. The rights to change the router configuration are held by only a limited number of individuals (two people: the Managing Director and the Technical Manager). Every change to the router configuration is logged with a name and time stamp so that it is possible to trace at all times what changes were made to the router configuration by whom and when. 

• Additional firewall devices are configured so that they restrict access to the data processing environment and amplify the security of the computing clusters.

• Firewall guidelines (i.e. configuration files) are transferred and uploaded to the firewall devices automatically every 24 hours. 

• Communication within the network is carried out using SSH encryption ("public key") provided by a bastion host which restricts access to the network devices and other cloud components and logs all activities on the network for security audits.

  
  

  3. Access control

The Contractor has implemented the following technical and organisational measures to grant and control access rights for employees and freelance staff who are collaborating with tchop. Currently, these measures include: 

• user and administrator access to the various service business accounts, and especially the cloud providers business account, which is created with the initial login, are based on a role-based access rights model. For everyday work, IAM users have been set up that have only limited rights and which are used by the relevant software developers for their day-to-day work. IAM users have their own security login data. Unrestricted access to the data in the cloud providers account ("root" access) is available only to the managing directors (only two people) at the tchop office. This root access information is not used for day-to-day development work.

• Access to the relevant system components and services (including monitoring) are protected by IP whitelisting, i.e. the employees' IP addresses are kept on file. Only accesses using approved IP addresses are permitted.

• Access to user data in the database is only possible via the AWS access and control system; direct access from outside is not possible.

• The granted access rights to all relevant systems are reviewed at least quarterly by the Technical Director. 

• All laptops are fully encrypted to protect confidential and personal data.

• The creation, deletion and altering of user IDs, login information and other identifying characteristics is logged along with a time stamp. 

• Data can only be copied in the context of data backup and for specially regulated cases of data sharing, e.g. essential data exchange with customers.

• Together with its service providers, the Contractor has drawn up an incident response plan, which sets out the following in the event of a data incident: Roles, responsibilities, communication and contact strategies for the risk scenario; specific procedures as a defined response to specific incidents; coverage and addressing of all important elements of the system.

  
  The access control to the cloud providers business account and the relevant IAM users is implemented through a comprehensive security concept that is set out in graphic form below:

  
  

4. Guaranteeing integrity

The Contractor has implemented the following technical and organisational measures to ensure that personal data cannot be read, copied, modified or removed without authorisation during electronic transfer or during its transport or storage on data media. Those measures also ensure that it is possible to verify and establish to which organisations personal data is intended to be or has been transmitted via data transfer devices. At the present time, these measures in coordination with the cloud provider encompass: 

• Prevention of unauthorised copying: the measures taken to prevent the unauthorised copying of the physical storage infrastructure per se (e.g. copying of the customer's data through transfer to an external storage medium such as a hard drive) are included in the measures as described above in Points 1 - 3. Furthermore, AWS employees and freelance staff may not connect any personal electronic devices or mobile data media to AWS' information systems. 

• Encrypted communication: tchop uses only HTTPS communication for all data interfaces and websites.  HTTPS stands for "Hypertext Transfer Protocol Secure" and is not an independent protocol in the technical sense. HTTPS refers to the use of HTTP over SSL or TLS. tchop uses an SSL certificate signed by a certification centre. By using this type of certificate, it is possible to ensure that no manipulation of content is possible by third parties during transfer and that no incorrect information about your company can be inserted into your corporate website. 

• User identification: for the repeated identification of administrators and editors with access to tchop's back-end, browser cookies with a validity of one year are used for each user. These allow the user to utilise the website or platform the next time they visit directly without having to log in again. The user can easily disable the use of these cookies via the relevant browser settings. The cookies are only used to log in or identify the user and to collect the very limited data described in Annex 1. 

• The native apps store the relevant data of the user who has logged in to them so that they can be displayed and used in the context of the user profile in the app. Usage data is not captured or forwarded. Only the data absolutely required for basic functionality is stored and made available for the relevant native application. Users should protect access to this data on their telephone using relevant access controls (codes, passwords, etc.). This is the user's responsibility and cannot be supervised or influenced by the Contractor.

• Use of an API token: the querying of content by native apps is always associated with an authorisation key. This ensures that the system can verify a user's access to content at any time and deny it in case of doubt, so that the native apps no longer have access to content and the user is logged out of the service (if he/she has been deleted and left the company, for example).   

• Decommissioning of storage media: if the lifespan of a storage medium has ended, AWS carries out a special decommissioning process to ensure that customer content does not fall into the hands of unauthorised persons. All decommissioned magnetic storage media are de-magnetised and then physically destroyed in accordance with the standard industry procedures and applicable data protection legislation. 

• Secure access points: AWS has a limited number of access points to the cloud. These customer access points are known as API end points and are used to provide secure HTTP access (HTTPS). tchop is able to communicate securely through these with its own storage or data processing instances on the providers platform. 

• Connections to the AWS network through the Contractor's employees: Employees access the network through SSH encryption "(public key") using a Bastion host. The Bastion host restricts access to network devices and other cloud components.
  
  

5. Separation control

The Contractor has taken the following technical and organisational measures to ensure that data collected for different purposes is processed separately:

• Separation of the system and database: the technical architecture is based on a modular approach that flexibly and efficiently connects various services and system elements through secure data interfaces. The overall system is therefore less complex and adaptations and improvements to one part of the system have a less critical impact on other areas. With this type of "micro-services" architecture, complex application software is compiled from independent processes, which communicate with each other using language-independent programming interfaces. The services themselves are largely decoupled and accomplish a small task. The database is an isolated, virtualised service and is completely separate and independent from other parts of the system containing the application logic. This allows a modular setup of application software and ensures that the principle of functional separation is complied with comprehensively and consistently. Only the data absolutely needed is exchanged between the components. 

• Separation of databases: in order to offer particular protection to the user-related data in the database (name and e-mail address), this data is separated from the database containing all of the platform content. This allows separate protective measures such as special encryption of the database with the user data and also makes unauthorised access harder.

• Separation of user roles: the Contractor endeavours to process personal data as little as possible or only where it can have a direct benefit to the Client in the context of the order. tchop therefore makes a distinction between two different types of user: 1. Customer administrators and editors, and 2. Users of the content and/or native apps. Users of the service are frequently a large group of people such as customers, employees and interest groups. 

To support administrators and editors with the use of the platform's content management system in the browser, some data is collected that shows how the user is interacting in functional terms with the platform (for details, see the annex entitled "Subcontractors", Working with Intercom.io). Usually, this user group involves a small number of selected individuals. The data is used exclusively to support and help these users to make the most efficient use possible of the tchop platform. 

With regard to the content use of the service or native apps (e.g. what users read), the collection of personal data is deliberately eschewed for all user groups.

• Separation of the testing and live environment: the Contractor has a different server environment which allows the development and testing of new functions and a separate live server environment. All servers are, as described, virtualised servers in the cloud that are provided via AWS and Hetzner. The separation of the testing and live environment allows secure and reliable development work. It allows a developer to develop a new version of software in the testing environment. Testers are then able to test in this environment in order to subsequently install the software in the live environment (a process known as release management. In the event of an error, an instance of the live environment can be mirrored onto a testing environment in order to be able to carry out investigations there without disrupting the live environment. 

• Separation of the company network: as already described under the first point, tchop's company network, along with the company-internal database and key corporate functions, is completely separate from all customer and personal data. The only functionality used on the same platform (albeit as a separate e-mail address) is the Google Suite e-mail infrastructure (see annex entitled "Subcontractors"), which employees use. Support enquiries from the Client's employees are dealt with via a dedicated support e-mail address (support@tchop.io). Enquiries to this e-mail address are forwarded to selected Contractor employees for processing and replies. The support process is fundamentally structured so that it can be handled as an individual process independently from normal e-mail communications. 

• Client-enabled server and database environment: the cloud environment used by tchop is a virtualised, multi-client environment. AWS and Hetzner have set up processes of security management and security checks, which allows the data of individual customers to be separated. Systems are designed so that customers cannot access physical hosts or instances that do not belong to their account. This is made possible through filtering in the context of virtualisation software. The Hypervisor is regularly checked by internal and external teams of experts for new and existing weak points and potential vulnerability to attack.

• Authorisation and rights concept: as already set out in detail in Point 3, the rights to the various services and the AWS database are strictly separated. Employees are only ever given the access rights they absolutely need for their work. 

  
  

6. Guaranteeing availability

Various security and backup mechanisms have been implemented for tchop's IT systems that ensure high availability and control of the system and database. These are described below.

6.1. System availability

The availability of the entire tchop platform is covered through an extensive monitoring system based on the "Grafana" open source framework (https://grafana.com). This allows the entire development team to spot and analyse changes, overloads and problems early on. Various values are constantly measured, from the CPU load to the memory state, from various database parameters (enquiries, processor utilisation) to various system-internal variables relating to the data interfaces and associated services (e.g. the "integrations").

The tchop development team also uses various tools for error analysis and for rapid, efficient troubleshooting (a process known as bug fixing). The widely available Sentry system (https://sentry.io) is also used to provide notifications and analyses of error sources and causes to the tchop technology team in real time as they occur. Errors can therefore be detected immediately at technical level and resolved. The system also helps directly with the cause analysis process and therefore makes resolving problems easier. 

In the event of a system failure of the application section, the "Rancher Security System" emergency system (https://rancher.com) kicks in automatically on the server side and normally restores the failed system within 5-10 seconds. Conversely, the tchop platform itself would not be affected by a failure of the Rancher system.

Access to the monitoring system is protected both by a rights and access concept and by IP whitelisting, i.e. only employees can access it and view relevant information. Personal data is not collected or processed in the monitoring systems described. 

tchop overall also follows a test-driven development approach on the basis of continuous integration. With this model, the software build, integration, testing and the reporting of all changes takes place immediately after each stage is added to the base code. Thanks to tests and reports on potential defects and conflicts in the base code, these can be identified and resolved directly more easily.

As part of a CI process, developers share their code and testing by feeding the changes into a shared version control repository after the completion of each small merge task. An automated build system takes the latest version of the code from this shared repository and takes care of the build, testing and validation of the entire master branch. To do this, tchop uses a modern version management system known as Git (https://en.wikipedia.org/wiki/Git). For the provider's software code, tchop uses Github (https://github.com) and the Gitlab platform for the server-side software code (https://gitlab.com).

The development team uses build definitions to ensure that each commit to the master branch triggers the automatic build and test processes. Since errors are spotted at an earlier stage of the development cycle as a result of this type of implementation, the costs associated with their resolution are lower. Automated tests during every build ensure improved test coverage as well as a consistently high build quality. Developers also reduce risks as well as recurring manual processes to a minimum, and teams benefit from better project transparency.

As a result, the Contractor is able to efficiently and continuously ensure that the entire system is made available again in the shortest possible time and the susceptibility to errors can be kept low.

6.2. Data availability

The responsibilities for data backup and securing of all the content of the tchop database is regulated through an agreement with AWS and Hetzner, our cloud service providers. The Contractor does not have its own local servers for data storage. The product "Amazon Related Database Service" (https://aws.amazon.com/rds/?nc1=h_ls) is used for the database. This service provides cost-effective and adaptable capacities and automates time-consuming administrative tasks such as hardware provision, database setup, the uploading of patches and backups.

Both AWS and Hetzner ensure a high availability of 99.9% for all data and can in all cases switch to a separate backup instance so that data remains available and secure. Over the last year of operation, the actual availability stood at around 99.999%.

Amazon RDS is available for various types of database instance - optimised for working memory, commons or I/O - and offers various database engines to choose from. tchop uses the world's most popular open source database MySQL (see https://aws.amazon.com/rds/?nc1=h_ls). "Amazon RDS for MySQL" relieves tchop of the time-consuming database administration tasks such as backups, software patching, monitoring, scaling and replication so that the developer team can focus entirely on developing applications.

The relevant security measures as defined by the GDPR are implemented by Amazon. Amazon RDS creates and stores automated backups of the entire tchop database instance. Once a day, Amazon RDS creates a snapshot for the volume so that the entire instance is backed up, rather than just individual parts or components.

Amazon RDS stores the automated backups of the database in accordance with the retention period for backups. During this retention period, the Contractor's database can be restored to a backed up point in time if required. It is also possible to back up the entire database manually, if necessary. 

The automated backups and manual database snapshots are stored by tchop in the Amazon RDS backup memory. This takes place in the EU region (Frankfurt). The backup memory corresponds to the sum of the database memory for all instances in the region. Within the EU region (Frankfurt), the data itself is also stored.

Automated backups are carried out daily during the standardised time window for the backup. For the EU region used (Frankfurt), this period is from 20:00–04:00 UTC. If the backup requires more time than available during the time window, it is continued after the end of the time window until it is complete. The backup time window must not overlap with the weekly maintenance window for the database instance.

During the automated backup time window, I/O storage processes can be temporarily paused until the backup process begins (normally just a few seconds). In the case of multi-AZ provisions, longer latency times can occur for a period of a few minutes during a backup. For SQL servers, with multi-AZ provisions, I/O activity is temporarily suspended during the backup process.

The retention period for backups can be defined as between 1 and 35 days. The backups of the entire tchop database are each stored for seven days.

All backups are encrypted. The failure of central system components leads to an automatic notification via e-mail. In an emergency scenario, the exact sequence of the backup or restoration of the live system is described (see also above, "Rancher Security System").

Professional anti-virus software is installed on all employee laptops to protect against malware. Detected malware is reported to the admin console. Incoming e-mails are also checked for malware by the provider, Google. 

9. Deletion of data

tchop offers various measures for retrieving, correcting, deleting or blocking customer-related data. Client-side editors and administrators can remove users from the user administration suite themselves at any time. At this point, the employee's user-related data (e-mail address, name, registration status) on the relevant AWS services or database is deleted or rendered illegible or unusable. With the deletion of this primary record, any links to the data and any copies of it are deleted. Encrypted data backups are the exception to this. In these backups, the record may be present for a maximum of 14 more days until it is overwritten and deleted by the next automated backup. 

Further processing of this customer data after deletion is then no longer possible. If the user is re-added with the same e-mail address after deletion, they are treated like a new user by the Contractor.

Alternatively, the Client can ask the Contractor to delete specific data. In this case, the Contractor follows an agreed deletion routine known to all employees. This takes places in three stages and must be agreed in writing with the Client:

1. Definition of the data to be deleted (this can be individual users or entire channels or accounts)

2. Agreement of the exact deletion period (immediately or on a specific date)

3. Verification of the obligation to retain the data in question 

In each case, all of the personal data communicated by the Client (e-mail addresses, names) and all captured data associated with this will be deleted within a period of 14 days after the end of the order.

Personal data is essentially never printed out at tchop and therefore never exists in paper form.

Laptops that are no longer required by employees are destroyed prior to disposal by mechanically drilling through the computer's storage medium, in cooperation with the Metal Guild of Berlin (tchop's landlord).

10. Guaranteeing systems resilience

The Contractor's entire IT system is designed and built so that it is very resilient. The Contractor processes data from a range of clients and accordingly ensures that the entire system is never impaired, even with larger orders. The platform is designed for a large number of updated, new content and a large number of users. The load from the system's perspective can increase significantly due to various factors and the system is prepared for this as follows:

• Number of requests: increased demand on the system, when requests can increase to an unusual extent either intentionally or unintentionally. The system has been designed in tests to handle up to 2,000 requests per second.  The actual access numbers, even during peak periods, represent only a fraction of this as things currently stand. From a technical perspective, it is possible in the future to increase this resilience further should there be a recognisable need for this.

• Increased numbers of accesses by "clients": access to the data interface is protected by a token so that only clients with this token are able to access data or content. Moreover, only logged-in users are able to call up content in the apps and access the system. The system is therefore in principle protected against unexpectedly high numbers of access by clients or apps. It is also possible at any time to delete individual tokens and therefore to restrict the access of certain clients again. 

• Targeted denial of service attacks: the Contractor also discusses the implementation of tools like "AWS Shield" in order to be prepared in future for potential attacks on the database and system. To date, however, these attacks have not represented any above-average danger that would justify such a measure.
  
  

11. Procedures for the regular review, analysis and evaluation of the effectiveness of technical and organisational measures

The Contractor's entire IT system is constantly being developed, improved and adapted to current and future product and security requirements. The requirements in terms of data protection and privacy play a key role in this. tchop takes the protection of personalised customer data very seriously and is constantly searching for optimised, efficient ways to improve its protection further. The company strives to implement a practical combination of tried-and-tested and innovative technologies in an appropriate manner.

The efficiency of the measures described in this document is constantly being reviewed in order to uncover any weaknesses early on and to optimise the entire system on the basis of new information, new technologies and rising demands. As part of this continuous process, the following measures are just some of the ones being implemented:

• Vulnerability management and penetration tests: the analysis of vulnerabilities is an iterative, repetitive process. The internal review of the system's own security architecture is carried out in special, quarterly sprints (2 x 2 weeks, i.e. one calendar month) using both automated and manual processes. The process of these reviews generally takes place in three stages, and is repeated even several times if required in order to be able to integrate new information into the other phases:

• Collect information

• Identify security gaps

• Evaluate security gaps

A team of at least two developers, a supervisor and a manager from the technical management team works, among others, on the following questions: What technical vulnerabilities does the system, infrastructure or special platform applications have? How effective are the existing security measures at preventing or detecting attacks? What damage can an attacker cause if they exploit vulnerabilities and bypass the security mechanisms? What new technical developments and requirements are there both from a technical and regulatory perspective? The results of this quarterly sprint are discussed between the technology managers and management board in special workshops and the quality and quantity of the outcomes are evaluated.

• Review of further services on the cloud providers platform: tchop backs up all data with the cloud service provider Amazon Web Services and Hetzner. AWS offers products that supplement existing AWS services and enable tchop to improve the security architecture in an efficient manner. This provider offers external services, tools and suppliers for vulnerability control and analysis, but also for the long-term improvement of the security and control of the company's system (see e.g. https://aws.amazon.com/security/partner-solutions/?nc1=h_ls). These services are constantly being reviewed and regularly evaluated by the technology directors in order to verify what additional contribution they are able to make to the subject of data protection and the security of the IT system. 

  
  

• Annual, external analysis: in addition to the internal improvement of the architecture and security measures, an external expert is commissioned at the end of each year with checking the tchop platform and making proposals on how to improve the architecture with specific measures. The results are discussed in a joint workshop with the technology directors and managing directors in order to come up with specific measures and options for implementation. 

  
  

Last Update: 15th of April 2025