The Processor implements a defence-in-depth approach, based on multiple complementary layers of technical and organizational security measures, including encryption at rest and in transit, role-based access control and strong authentication, network and environment segregation, continuous monitoring, vulnerability management and incident response, training and awareness, confidentiality agreements, and Subprocessor due diligence processes.

§ 1Technical Measures

Encryption

1. At Rest: All stored Personal Data, including User Content, are encrypted at rest using recognized cryptographic algorithms (AES-256), with full management of the cryptographic key lifecycle via the cloud provider’s Key Management Service (“KMS”) with Hardware Security Modules (“HSMs”) and automatic key rotation.
2. In Transit: All data communications, both internal (between the nodes used by the Software) and external (between the Authorized User and the Software, and between the Software and Subprocessors), are protected by up-to-date cipher suites (TLS 1.2 or higher).

Access Control

1. Access Management Policy: The Processor maintains an internal access management policy operating on two complementary levels:
2. Internal identity and access management: governs the complete lifecycle of identities of internal staff (employees, contractors, and Subprocessors) with access to the Processor’s infrastructure and information systems, including:
3. Full user lifecycle: onboarding, profile creation and modification (role changes, with immediate revocation of prior access rights), and deactivation, access being blocked with effect from the date and time on which the employment or engagement ends;
4. Hierarchical approval matrix: all access rights are formally approved by the CTO, with extraordinary and super-administrator access rights reserved for approval by the CEO;
5. Temporary access with automatic expiry (time-to-live), configured at the time of assignment;
6. Segregation of duties and unique user identification (named, non-transferable accounts).
7. Platform access management: governs the access control model for the Controller’s Authorized Users, including the specific controls described in the following paragraphs (Multi-factor Authentication, Named Accounts, Periodic Access Reviews, Session Management, and Credential Policies).
8. Role-Based Access Control (RBAC): Access to Personal Data and User Content is restricted to authorized personnel and, in each case, only to the extent strictly necessary for the performance of their functions and the proper operation of the Software.
9. Multi-factor Authentication (MFA): Optional for Authorized Users without privileged access, although MFA may be enforced by the Controller’s identity provider in an SSO context; mandatory for internal staff with privileged or platform administration access rights.
10. Named Accounts: Restriction on the use of generic or shared accounts, requiring formal justification, registration, and time-limitation for any exception. The access architecture is based on individual named accounts with personal, non-transferable credentials.
11. Periodic Access Reviews: A formal process applicable both to the Processor’s internal staff and to Authorized Users, to ensure that each user retains only the permissions strictly necessary for the performance of their current functions. The frequency and scope of reviews relating to Authorized Users may be configured to meet the Controller’s specific requirements.
12. Session Management: Session expiry requirements and simultaneous session controls are implemented at the technical level and are adaptable and configurable to meet the Controller’s specific requirements.
13. SSO Integration: The platform supports integration with the Controller’s corporate identity provider via standardised federation protocols (e.g., SAML 2.0, OIDC), allowing the delegation of authentication of Authorized Users to the Controller’s identity provider.
14. Credential Policies: Password complexity and rotation policies are managed at the identity provider level.

Infrastructure Security

1. Network and Environment Segregation: Cloud-native network security architecture with logical isolation between environments and a default-deny policy. The infrastructure includes stateful filtering firewalls, native DDoS protection, anti-spoofing mechanisms at the network layer, and traffic logging. Direct Internet connectivity is restricted to the application layer, authentication services, and file storage.
   • Production, development, and test environments are properly segregated.
2. In the Virtual Private Cloud (VPC) deployment model, where contracted by the Client, the Software is deployed in the Client’s own cloud infrastructure, and benefits from the inherent isolation of that model. In this scenario, the Processor may configure network access controls tailored to the Client’s specific requirements, and other network security measures (e.g., VPNs) are the responsibility of the Client as the operator of its own infrastructure.
3. Wireless Network Security: Corporate wireless networks use current-standard encryption, with segregation between the corporate network and the guest network.
4. Physical Security: The Service infrastructure is hosted in the cloud provider’s data centers, which hold recognized security certifications (e.g., ISO 27001, SOC 2) and provide 24/7 surveillance, physical access control, fire protection, redundant power supply systems, and secure hardware disposal procedures.
5. Asset Management: Infrastructure assets involved in the provision of the Service are managed and inventoried automatically using the cloud provider’s tools.
6. Secure Information Exchange and Data Leakage Prevention: The exchange of documents or sensitive information with authorized third parties takes place exclusively through secure collaborative tools with encryption in transit. Data leakage prevention controls are applied. Access to information is restricted to what the relevant functions require (RBAC); personnel are bound by confidentiality obligations; documents stored on collaborative platforms may not be shared with recipients outside the organization without the express authorization of the information asset owner or administrator; and the channels used are encrypted in accordance with the sensitivity of the information transmitted and applicable contractual requirements.

Operational Resilience

1. Audit Logs and Monitoring: The Processor maintains an internal policy on log management and auditing, which defines minimum mandatory log fields (including user identifier, date and time, synchronised to a reliable time source, successful and failed access attempts, IP addresses, configuration changes, and use of privileges), at both the application and infrastructure levels. Logs are stored in secure repositories, protected against modification and unauthorized access, with defined retention periods.
2. Continuous Monitoring and Anomaly Detection: Continuous monitoring systems for infrastructure and application logs, with automatic alerts configured for the detection of security events and anomalous behavior. Detected anomalies are subject to review and handled in accordance with the escalation and incident response process.
3. Vulnerability Management: Identification, classification, and remediation of security vulnerabilities, including: periodic scanning across all environments, severity classification based on the value of the affected asset and actual risk, patch management processes, and Software and operating system security updates.
4. Backups and Disaster Recovery: Regular and secure data backup policies and procedures, with encryption of backups (AES-256) and storage in a logically isolated repository. Periodic recovery tests are carried out to ensure data availability and integrity in the event of an incident.
5. Change Management for Application Systems: Formal change control process for information systems, including: a record identifying the change, the responsible party, and the date; impact and risk analysis; pre-deployment approval; and rollback capability. A version control system is used as an auditable record repository.
6. Secure Development: Integration of security checks into the software development lifecycle, including code review, automated security testing, and pre-production deployment validation through automated deployment pipelines.
7. System Hardening: Deactivation of unnecessary services and components, elimination of insecure default configurations, application of baseline security settings, and periodic internal audit of configurations, in accordance with the best practices of the cloud provider used to provide the Service.

Data Protection and Minimization

1. Pseudonymisation and Anonymisation: The use of real data in non-production environments is expressly prohibited; such environments are segregated from the production environment.
2. For analytics involving production environment data (including usage and performance analytics), Authorized Users are referenced by unique identifier (“UUID”) and no direct identification data are used. This amounts to technical pseudonymization. The Processor re-identifies Authorized Users only where strictly necessary for the provision of the Service, for the investigation of a security incident, or on the documented instruction of the Controller, and records each such re-identification.
3. The Controller is contractually responsible, under Clause 8.2(h) of the GTC, for the prior anonymisation of any elements entered into the Software that are subject to disclosure restrictions, in accordance with the GTC.

§ 2Organizational Measures

1. Policies and Procedures: Adoption and implementation of internal policies covering, in particular: information and ICT security; threat and vulnerability management; access management; log management; and security incident management. These policies establish technical and organizational measures to mitigate the risk that information and resources will be altered, lost, disclosed, made unavailable, or accessed without authorization, and they are reviewed periodically to ensure that they remain appropriate and effective.
2. Training and Awareness: Annual cybersecurity and data protection training and awareness plan, adjusted by function and role, available to all employees and Subprocessors with access to Personal Data. The plan covers: Personal Data protection; cybersecurity; legal obligations; incident management; and information security best practices.
3. Confidentiality Agreements: Conclusion of confidentiality agreements (NDAs) with all persons authorized by the Processor to process Personal Data, including employees and contractors, who have access to Personal Data or User Content in the course of their duties.
4. Subprocessor Management: The selection of Subprocessors is based on a best-of-breed approach, supported by pre-contractual due diligence and periodic re-evaluation of service conditions, criteria, and quality. Preference is given to Subprocessors holding recognized information security certifications (ISO 27001 or SOC 2 Type II) or accreditation under equivalent programs, as well as those with data centers located in the European Economic Area, or, where this is not the case, whose Personal Data transfers are carried out under one of the mechanisms provided for in Chapter V of the GDPR (in particular, an adequacy decision, Standard Contractual Clauses, or Binding Corporate Rules).
5. Data Protection Impact Assessments (DPIAs): Conduct of DPIAs for Processing operations likely to result in a high risk to the rights and freedoms of Data Subjects or Authorized Users.
6. Incident Response Plan: A documented procedure defining internal and external detection mechanisms, incident classification and triage, severity categorisation (Risk Matrix), escalation path, the responsible team, and the procedures for notifying the Controller. The plan covers both logical and physical incidents.
7. Privacy by Design and Privacy by Default: Data protection principles are integrated into all phases of the Software development lifecycle (from design to deployment) and reflected in the platform’s default settings, which limit Processing to what is strictly necessary for each specific purpose. In particular, this integration is given effect through the following practices:
   • Minimization by default: Software features are designed to collect and process only the Personal Data essential to the stated purpose, with higher data-exposure options disabled by default;
   • Environment segregation: Development and test environments are logically segregated from the production environment; the use of real Personal Data in non-production environments is expressly prohibited;
   • Security and privacy checks in the development pipeline: Code review, automated security testing, and pre-production deployment validation, including verification of compliance with the principles of data minimization and purpose limitation.