Technical and Organisational Measures(TOMs) and Technical Solution Description

Version 1.0, April 2025

1 Purpose of this document

The purpose of this document is to describe key technical and organisational measures (TOMs) to comply with the requirements resulting from Art. 32 of the General Data Protection Regulation (GDPR), to ensure the security of personal data and other data in Fidify‘s services.

1.1 Measures implemented across the group

The TOMs outlined in this document are implemented in all Fidify group companies that develop and provide its software and services. The measures taken fulfil the requirements regarding confidentiality, integrity, availability, risk assessment, review and resilience according to Art. 32 GDPR.

1.2 Summary of measures per Art 32 GDPR

Fidify has – at a minimum – implemented the following measures according to Art. 32 GDPR:

1. access control and access review on least-privilege policy and per customer’s instruction.
2. data encryption during transfer/transport and at rest.
3. regular, verified backups and restores
4. regular security tests (penetration tests and vulnerability analysis)

2 Product/Service introduction

Fidify and its group companies provide SaaS (Software-as-a-service) services used to collect and analyse KYC data from Customer’s customers and end-users.

For example, Fidify’s platform is specifically designed to handle the documentation needs of KYC processes, reducing manual work and ensuring compliance at every step.

1. Corporate document management: Efficiently gather and manage company registration documents.
2. Digital document submission: Enable users to upload and review identity documents quickly.
3. Secure repository: Safely store and access business-critical documents anytime.
4. Comprehensive record-keeping: Maintain a complete, auditable trail of document handling for compliance.

In addition to the SaaS services, Fidify also provides professional consulting services through a team of in-house consultants skilled within customer experience (CX) and employee experience (EX).

3 Risk management

Fidify’s services are considered a “high risk” service. Our platform is specifically designed to handle document management tasks required for KYC processes, ensuring that sensitive information is processed securely and in compliance with regulatory standards. Any data 4

uploaded to the platform, including personal or corporate documents, is always controlled by the customer.

All exceptions or identified risks are managed through a defined risk management process. Security risks are reported or detected through proactive monitoring, and the resulting risk register serves as a key driver for Fidify’s ongoing risk mitigation and elimination efforts. This process is overseen by Fidify to ensure that potential risks are effectively addressed.

4 Privacy controls

Privacy controls are described in the Fidify group company’s privacy policies:

fidifygroup.com/doc/PrivacyPolicy.html

5 Resilience

5.1 Change management

Fidify updates the SaaS platform continuously and all updates are made available to all customers. Significant features or changes that are significant are communicated to customers prior to deployment. Fidify uses a well-defined Secure Development Lifecycle (SLDC) including mandatory manual and automated testing before release.

5.2 Hardened configuration standard(s)

All servers are automatically managed in Google Cloud Platform Services (GCP). Google Cloud Platform Services has high security rating. Fidify only deploys its service to Google West Europe (Belgium, EU). Access to production environment is limited by the principle of least privilege and only individual, named and identified users can access it Multi-Factor Authentication.

Development, Test, and Production Environments are separated.

5.2.1 Regular, documented validation of configuration

The development and operations team uses an automated tool to perform regular, documented validation of the configuration for all servers and infrastructure changes. Any exceptions to the standard require CTO approval. An end-of-support procedure is in place and considered in risk assessments.

5.3 Vulnerability management

5.3.1 Patching

Fidify patches its core software frameworks as soon as possible when a new long time support (LTS) version is available. We do not take in use beta versions in production but keep with latest LTS version. Patch planning is done along normal development/operations planning process. This process occurs in 2-week sprint cycles where planning meeting starts new sprint.

5.3.1.1 Regular patching

Regular patching of production environment is done continuously for those patches that do not cause any interruptions to system use, patching window for patches that can cause down within maintenance window or communicated planned outage. 5

Acceptance criteria for patching is our automated and manual tests, typically new software version patch is kept in TEST environment for several days minimum before applying the patch to production.

5.3.1.2 Emergency patching

In case of critical vulnerability detected / announced by vendor where impact caused by waiting for regular patching window is considered as high, emergency patching window is scheduled. Decision whether to implement patch(es) in emergency patching window is done by Fidify CTO.

5.3.1.3 Exceptions in patching

In case of need for exception of patch, it must be approved by development team via Fidify CTO.

5.3.2 Vulnerability scanning

OWASP Code and dependency Vulnerability scanning is performed regularly for each software build. In addition 3rd party penetration testing and security audit done by human resources is done minimum once per year.

Any validated findings that could be found and are critical/high vulnerabilities will be mitigated immediately and permanent fix for them will be developed. Lower security issues are also prioritized over functionality in order to keep system security high.

Report(s) regarding last performed security testing, scanning + intrusion testing are saved. Reports are available upon request.

Fidify is committed to perform regular internal vulnerability scans and for internally found vulnerabilities we strive to follow fixing schedule as follows

1. Zero-day vulnerability: As soon as possible
2. Critical Risk: 30 days
3. High Risk: 90 days
4. Medium Risk: No time limit

5.4 Log management and Audit trails

Below is defined how user access is logged.

5.4.1 Operating system

Logs inside Fidify operation system are configured according to industry best practices.

5.4.2 Application

Fidify logs all events in centralized logging system which is located in EU.

As an example, a log file typically includes:

1. Date + timestamp
2. Level, “warning, error, info”
3. Host
4. Service
5. Content (actual text of the log)

Application logs are not deleted at all, for reviewing the data in case of incidents. We also do not log sensitive data there (see chapter Personal data in logs). Access to logs is only 6

granted to selected operations personnel and they require 2-factor authentication and personal users.

Fidify logs user activities like login and data export or uploads. All services log their actions in info level logs and should there be warnings or errors, those are also stored.

5.4.3 Time synchronization

All integration servers have time synchronization type set to synchronize with domain controller in UTC time.

5.4.4 Personal data in logs

Personal data are not put into our logs, we use an internal user id instead of usernames, email etc. mail.

6 Personal data protection

6.1 Encryption at rest and pseudonymisation

In accordance with Fidify’s Information Security Policy, all Restricted KYC data is encrypted at rest using industry-standard cryptographic algorithms and secure libraries.

User-created passwords are protected using one-way BCrypt hashing, which incorporates:

1. A unique, per-user salt to protect against rainbow table attacks
2. At least 1024 iterations to slow down brute-force attempts
3. Irreversibility, ensuring passwords cannot be decrypted back to their original form

Access to customer data is strictly role-based, limited to personnel with a legitimate need as defined in our access control policies.

All KYC data stored at rest is encrypted using AES with a minimum key length of 256 bits. Where supported by the cloud provider, we further limit access by restricting visibility of managed instances to authorized provider personnel only.

Additionally, uploaded files are encrypted using a hybrid encryption approach:

1. Files are encrypted client-side with AES-GCM, and the AES key is then encrypted using ECDH-derived symmetric keys.
2. The ECDH shared secret is established using the user’s private key and the portal’s public key.
3. HKDF with HMAC-SHA256 is used to derive the final key used to encrypt the AES key.
4. The encrypted payload includes a salt, IV, ciphertext, and authentication tag, all Base64-encoded for safe transmission and storage.

This layered encryption approach ensures that only the intended user and portal can access encrypted files, providing both confidentiality and integrity across platforms (iOS, Android, and Web).

6.2 Encryption in transit

All communication to and from Fidify services, external services and users are through HTTPS protocol. 7

7 Confidentiality

The following sections describe the levels and nature of access that will be provided to users based on the sensitivity of the data and users legitimate business need to access personal data.

7.1 Admin rights management

Access to servers is managed by Fidify, personal accounts are always used. Usage of shared accounts is not allowed and privileges are given on the principle of least privilege.

Normally, only senior members have access to servers but temporarily elevated privileges can be given for time limited efforts. In this case, access is only given to a specific environment (test, stage, prod).

7.2 Monitoring

Fidify uses a combination of services to provide logging and monitoring.

Web proxy is used process and log all incoming requests coming to the servers. Additionally, Fidify logs failed login attempts and all API requests. Fidify stores both activity logs and resource logs of operations done in the cloud provider and on the resources in the cloud provider.

Monitoring and logs are restricted to privileged users on different levels depending on need to access them to provide a functional and secure service.

8 Integrity

Data integrity is a wide concept and a set of different measures are taken to ensure it. First, data is validated when it is transferred to Fidify. Second, access and write operations to databases are restricted and, third backups ensure that data can be restored to its original status.

9 Availability

Data availability is ensured through redundancy of most (but not all) of our services. All services are monitored and alerted to product teams for remedy.

10 Ability to restore availability and access to personal data

Below is defined how availability, unauthorized or accidental destruction of personal data is controlled.

10.1 Business continuity and disaster recovery

Business continuity and disaster recovery is described in Fidify’s Business Continuity Plan and Incident Management Procedure which are part of Fidify’s ISMS documentation.

10.1.1 Validation of disaster recovery testing

Disaster recovery tests are performed bi-yearly and results are stored in the Fidify system. 8

10.1.2 Data backup and restore

Database servers are backed up at least with the following configuration:

1. Daily full backups
2. Incremental hourly backups
3. Retention short-term: 7 days

All product and infrastructure data is stored separately and all environments can be recreated in a new region if necessary.

11 Software management and vulnerability management

11.1 Application environment

11.1.1 Dependencies and malware

Dependencies on 3rd party and Open Source Software for application development and runtime are defined in code and scanned during builds before deploy to production. These dependencies are scanned by Github Dependabot, and Google Artifact Registry to detect potential vulnerabilities.

11.1.2 Vulnerability management

Potential vulnerabilities are reported during build and vulnerable build is cancelled. Critical vulnerabilities must be patched in testing and staging environment.

11.2 Employee workstation and mobile devices

Software installation and vulnerability management is defined in Mobile device policy.

12 Communication security

12.1 Network security management

12.1.1 Network controls

Applications environments (testing, staging and production) only include features strictly necessary for application functionality.

12.2 Sessions

Session management varies depending on sensitivity of data. For access to non-PII functions, session expiry is 30 days (of inactivity or logout).

12.3 Information transfer

12.3.1 Agreements on information transfer

Customers can import and export data to/from Fidify UI from/to Excel manually if needed.

12.3.2 Electronic messaging

Communication external from Fidify application to users can be done via e-mail, GSM or

landline phone communications. 9

12.3.3 Confidentiality or nondisclosure agreements

Vast majority of contracts between Fidify group companies and customers are based on

company template/standard terms, not those of the customer, and contain market-standard

confidentiality clauses. For contractor and employees at Fidify group company, a standard

template is used which also contains a market-standard confidentiality clause that includes

protection of all customer data.

13 Physical security

Access to Fidify physical facilities is protected by personal key cards + secret pin. In addition,

sensitive areas such as network, legal documents and internal IT are protected. All access (successful or attempted) is monitored, alerted and logged.

Fidify utilizes Google cloud for server, network and storage infrastructure. Google is certified to the ISO 27001 Standard with its clear focus on e.g. access control, physical security and handling of physical media and devices.

The Google Cloud Security whitepaper which covers physical security:

https://cloud.google.com/security/overview/whitepaper

The Google Infrastructure Security Design Overview which details physical security measures:

https://cloud.google.com/security/infrastructure/design

The “Data Processing and Security Terms” page which includes information about data storage handling:

https://cloud.google.com/terms/data-processing-terms

14 Sub-processors

Fidify engages sub-processors such as data center operators to deliver the services and to process data on Fidify’s and its customers’ behalf. The sub-processor’s data centers are as a

minimum ISO 27001-certified. Documentation of technical and organisational measures of the respective sub-processor are available on request.