Annex B. Technical and Organisational Measures (Article 32 of Regulation (EU) 2016/679)

Introduction

This Annex describes the technical and organisational measures that CodeDesign S.r.l. (hereinafter the "Provider") adopts pursuant to Article 32 of Regulation (EU) 2016/679 in order to ensure a level of security appropriate to the risk in the processing of personal data carried out on behalf of the Customer.

The measures are described by function and by effect. The Provider does not set out implementation details, names of internal systems, addresses, components or configuration parameters whose disclosure would reduce the effectiveness of the measures themselves. Further information is made available to the Customer in the manner and within the limits of Article 4.8 of Annex A.

This Annex describes the state of the measures as at the date of the version. It may be updated by the Provider provided that the overall level of security is not reduced, in accordance with Article 12.5 of the Conditions and with section 15 below.

1. Organisation of security

1.1 Roles. The Provider has formally assigned the following responsibilities:

• a) Information security manager: assessment of the security risks, verification of the effectiveness of the measures, proposal and verification of the corrective actions.
• b) Data protection contact person: coordination of data protection matters, qualification and handling of breaches from a legal perspective, keeping of the breach register, relations with the supervisory authority, monitoring of the privacy@codedesign.it mailbox.
• c) Incident management manager: taking charge of the reports, technical containment, collection and preservation of the evidence, reconstruction of the scope of the event, coordination of the restoration.
• d) Management: decision on the notifications to the supervisory authority and on the communications to data subjects when the Provider acts as controller, approval of the resources for the corrective actions.

1.2 Data protection officer. The Provider has not designated a data protection officer pursuant to Article 37 of the Regulation, having assessed that the conditions for it do not apply. The assessment is reviewed at least annually. The contact point remains the privacy@codedesign.it mailbox.

1.3 Management system. The Provider has started the adoption of an information security management system compliant with the ISO/IEC 27001:2022 standard and the related certification process is under way. As at the date of this Annex the certification has not been obtained. The Provider does not declare that it is certified and will inform Customers if it is obtained, updating this Annex.

1.4 Review. The measures described in this Annex are reviewed at least annually, after every personal data breach classified as medium or high risk and after every significant change to the architecture of the Service.

2. Access control and authentication

2.1 Centralised identity. Access to the platform takes place exclusively through a centralised identity management system, separate from the application. Users' credentials are not stored by the application.

2.2 Verification of the email address. The default authorisation policy of all the application interfaces requires, in addition to authentication, that the user's email address be verified. Access is denied in the absence of that requirement.

2.3 Two-factor authentication. A second authentication factor is available by means of a one-time code sent to the user's email address, configurable on the identity system.

2.4 Validation of the sessions. Access tokens are validated in depth: verification of the audience, verification of the issuer against an explicit list, verification of the duration and of the expiry, verification of the signature with rejection of unsigned tokens, limited clock tolerance. Negative outcomes are logged with the reason for the rejection, without the token ever being logged.

2.5 Application access keys. The access keys issued to the Customer for the automated use of the Service are generated with high entropy, are kept at rest exclusively in the form of a cryptographic hash and are shown in clear text only once, at the time of creation. A key without declared scopes does not allow authentication on any channel. Each key may be limited to specific Digital employees. The keys have their status and expiry verified at each use.

2.6 Separation of the privileges of the keys. An application key may under no circumstances obtain platform, system or organisation privileges, and is subject to an explicit list of operations that are always denied, including the management of the subscription, the modification of the credits and the management of the quotas. Where a request carries both a user's identity and an application key, the user's authorisation profile always prevails.

2.7 Granular permissions and fail-closed behaviour. Authorisation is based on atomic permissions resolved by the system, not on the subscription plan. Each interface explicitly declares the permission required and denies access in the absence of a declaration or of the permission. No profile other than the platform administrator may create or modify role definitions, and therefore cannot grant itself privileges higher than those it holds.

2.8 Access on behalf of a user. The feature by which the Provider's personnel operate on behalf of a User of the Customer is permitted only to expressly enabled profiles, cannot be activated by the mere declaration of the requester, requires higher privileges in order to operate on administrative profiles and is recorded in the audit log, together with the attempts denied.

2.9 Authorisations towards the connected services. The OAuth authorisations towards the services connected by the Customer are obtained with the authorisation code flow with Proof Key for Code Exchange (PKCE) and with a state parameter that is signed and verified with a constant-time comparison. The renewal of the tokens takes place in a single flow with a distributed lock.

2.10 Short-lived tokens. The sessions of the real-time transcription features and the test sessions of the voice agents use tokens of limited duration, single-use for the test sessions, with a verified signature. In the absence of the signing key no token is considered valid.

2.11 Custody of the tokens on the client side. The Customer's portal keeps the access token exclusively in memory, without writing it to the browser's local storage. The mobile application keeps the credentials in the secure storage of the operating system and applies a coordinated sign-out with deletion of the keys. The secondary portals do not expose any token to the browser, keeping the session on the server side in encrypted form.

3. Separation of data between Customers

3.1 Perimeter. The unit of separation is the application environment of the individual Customer. Every resource, request, credential and log is referred to that environment, and the user's membership of the environment is verified on every request.

3.2 Nature of the measure. The separation is achieved by means of explicit application controls in the services, supplemented by a single access verification rule applied as defence in depth. The Provider transparently declares that these are application controls safeguarded by automated regression tests and not a structural separation at the level of the data store.

3.3 Automated tests. Continuous integration runs, at every change, tests that verify: that each interface declares the permission required, with an explicit and reasoned list of the only exceptions allowed; that it is not possible to access resources belonging to other Customers; that the limitations on the privileges of the application keys are respected. Failure of those tests prevents the change from being integrated.

3.4 Soft deletion. The main entities of the data model are subject to soft deletion with a global filter, so that a deleted record is never returned by ordinary queries.

3.5 Separation of the Digital employees. Each Digital employee of the Customer runs in a dedicated container, with its own storage volumes, with the knowledge base mounted read-only and with a separate workspace. The local archive with conversations, memory and transcripts resides in the volume of the individual container.

3.6 Internal channel of the Digital employees. The calls from the container towards the central services are authenticated with a derived credential, verified with a constant-time comparison and bound to the identity of the Digital employee, with a consistency check against the orchestration system and with protection against the exchange of identity between different Digital employees.

3.7 Separation in observability. Every query on technical logs and traces must contain the reference to the Customer's environment, failing which it is rejected, and the user's membership of that environment is verified. For non-administrative profiles the technical fields that might contain fragments of content are removed from the results.

3.8 Resellers. The privileges granted to a reseller operate only on the resources linked to the reseller by an explicit relationship recorded in the system. The status of reseller can be modified only by the platform administrator and the modification is recorded in the audit log.

4. Encryption

4.1 Encryption of data in transit

• a) All communications between the clients and the platform take place over a channel encrypted with the TLS protocol, with mandatory redirection of unencrypted traffic outside the development environments.
• b) The metadata of the identity system are retrieved exclusively over an encrypted channel.
• c) The temporary links by which the files are made available are issued read-only, exclusively over an encrypted channel, with an expiry of no more than one hour.
• d) The connections to the incoming and outgoing mail servers configured by the Customer take place over an encrypted channel, with a protected negotiation.
• e) The mail accessed by the mobile application is transmitted exclusively over an encrypted channel with verification of the server's certificate, with no exception: an invalid certificate results in the connection being refused.
• f) The cross-origin access policy does not allow the transmission of session credentials, so that no cookie can be sent from a third-party origin.

4.2 Application-level encryption of data at rest

• a) The Provider applies application-level encryption with the AES 256-bit algorithm in GCM mode, with a versioned envelope, a random initialisation vector and an authentication tag. A key of non-compliant length is refused for use and a failed decryption generates an error without the data ever being returned.
• b) The following are protected with that encryption: the credentials and access keys of the services configured by the Customer, the credentials of the mailboxes and of the workflows, the signing secrets of the channels and of the webhooks, the credentials and tokens of the connectors activated by the Customer, the connection strings to the Customer's document archives, as well as the transcripts, the lists of participants and the results of the meetings processed by the mobile application.
• c) Transparency clarification. The application-level encryption referred to in point b) does not extend to the content of the chat conversations or to the documents uploaded to the knowledge libraries, which are protected by the access controls described in sections 2 and 3 and by the encryption at rest of the underlying storage referred to in paragraph 4.3.

4.3 Encryption at rest of the infrastructure

The encryption at rest of the storage media is provided by the infrastructure providers according to their terms of service. The Provider does not declare that measure as verified by itself and does not assume it as its own contractual commitment until it obtains the written attestation of the cloud infrastructure provider and of the dedicated server provider.

4.4 Backups

The backups of the Digital employees are encrypted at source, before transmission to the remote archive: without the encryption key the copies cannot be used.

5. Management of secrets

5.1 Centralised store. The credentials and secrets necessary for the provision of the Service are kept in a dedicated store, organised by separate scopes, with the value encrypted at the time of writing in accordance with paragraph 4.2.

5.2 Master key. The master encryption key is unique, does not reside in the source code or in the versioned configuration files and is kept in the key store of the cloud infrastructure provider, from which it is made available to the application as a protected setting.

5.3 Resolution at the time of use. Secrets are resolved only at the moment when they are needed and with fail-closed behaviour: a reference that does not resolve generates an error and never produces an empty value. The configurations transmitted to the Digital employees contain exclusively references to the secrets, never the values.

5.4 Non-retrievability. The values of the secrets are never returned by the programming interfaces of the platform: the exclusion is imposed by construction by the response serialiser and does not depend on the individual developer. The store of secrets available to the Customer is write-only: the values entered can no longer be read back.

5.5 Logs. The values of the secrets are masked in the technical logs, including when resolved at the time of use, and do not appear in the start-up logs of the Digital employees.

6. Logging and monitoring

6.1 Audit log of administrative operations. The Provider maintains a log of administrative operations that records for each operation: date and time, actual author, any person who acted on behalf of a user, environment and organisation concerned, category and type of action, object concerned, details and source address. The operations covered include, among others, those on roles and permissions, users and memberships, credits and quotas, domains and groups, grants on resources and support tickets, as well as access on behalf of a user.

6.2 Access to the log. Consultation of the log is protected by a dedicated permission. The view relating to an individual Customer is always filtered on that Customer's environment.

6.3 Retention. The entries of the audit log are retained for 24 months and then automatically deleted.

6.4 Transparency clarification. The audit log covers administrative and configuration operations. The Provider does not declare an immutable log or a log of access to Customers' content.

6.5 Observability. The platform produces traces, metrics and technical logs with an observability system, enriched with the reference to the Customer's environment. Access is subject to the controls in paragraph 3.7.

6.6 Content excluded from the logs. The coding rules prohibit the logging of secrets, tokens and extended user content, and are safeguarded by the review of the changes.

6.7 Operational alerts. The Provider maintains automatic alerts on the events relevant to continuity and security, including the negative outcome of the periodic restore checks and the repeated restart of the services, with notification to a monitored mailbox.

6.8 Public status page. The Provider publishes a status page for the Service, fed by internal probes and by probes towards the upstream providers, with notifications by email, a subscription channel and internal notices. As a security choice the page does not expose the name or the number of the Customers' Digital employees.

7. Backups and continuity

7.1 Environment of the Digital employees

7.1.1 Versions. The object storage that hosts the copies keeps the non-current versions for 30 days, as protection against accidental deletions.

7.1.2 Automatic check. An automatic check carried out every 6 hours performs a real restore of a Digital employee on a rotating basis from the remote archive and compares the cryptographic hashes of the restored data. A negative outcome generates an alert; at regular intervals a confirmation that the check itself is working is generated in any event.

7.1.3 Restore test. The most recent real restore test, carried out with a simulated loss of the volumes, was passed on 10 July 2026, with a measured restore time of approximately 15 minutes, the identity of the restored data verified by cryptographic hash and the service reactivated at the first attempt.

7.1.4 Perimeter. The following fall outside the perimeter of the backups, as a documented choice: the meeting recordings captured by means of the automatic participant, the application code and the caches of the workspaces.

7.2 Environment of the cloud platform

The backups of the database and of the file storage of the cloud platform are those provided for by the managed services of the infrastructure provider. The Provider does not declare, as at the date of this Annex, recovery time and maximum data loss objectives for that environment: the objectives will be declared and assumed as a commitment when the related configuration has been verified and documented.

8. Retention and deletion of the data

8.1 Automatic deletions. The Provider carries out the following automatic deletions or anonymisations:

8.2 Voice conversations. The retention of the voice conversations is configurable by the Customer for each agent. A nightly process applies a double criterion, considering both the expiry communicated by the voice provider for the individual conversation and the period configured by the Customer, and applies whichever of the two expires first. The deletion entails the effective removal of the audio file from the archive and the clearing of the transcript, of the summary, of the analysis, of the caller's telephone number and of the reference to the audio, with a further attempt in the event of an error. A residual technical row remains, without personal data, kept for the sole purpose of avoiding duplication at the import stage and of demonstrating that the declaration of artificial nature was made.

8.3 Mode without retention. The Customer may activate a mode in which the voice conversation is recorded without content from the moment of acquisition.

8.4 Deletion at the Customer's initiative. The deletion of a document entails the removal of the file from the archive, the removal of the related search indexes and the soft deletion of the record. The deletion of a library entails the deletion of the documents it contains. The deletion of a User entails soft deletion in the platform and effective deletion on the identity system, with a record in the audit log.

8.5 Transparency clarification. For the chat conversations and for the documents in the knowledge libraries no automatic deletion period is provided: they are retained for the duration of the Contract, can be deleted at the Customer's initiative in accordance with paragraph 8.4 and are deleted at the end of the Contract in accordance with Article 10 of Annex A.

8.6 Deletion at the end of the Contract. Article 10 of Annex A applies in full, governing the choice between return and deletion, the periods of 60 and 90 days and the blocking of access in the intervening period.

9. Secure development

9.1 Protected branches and review. The main branches of the code accept changes exclusively by means of a pull request subject to review. Direct writing is not permitted.

9.2 Automated checks. On every pull request continuous integration carries out the restore of the dependencies, the compilation in release configuration and the execution of the test suite, with minimum privileges assigned to the runner. A dedicated check prevents the integration of changes that lack the documentation of the impact for the user.

9.3 Release without static credentials. The release into production takes place by means of a federated identity towards the infrastructure provider, without static credentials stored in the continuous integration system. The new version is published in a test environment and promoted to production only after verification, with the possibility of an immediate return to the previous version.

9.4 Coding rules safeguarded by automated tools. The Provider uses its own static analysis tools that prohibit generic exception handling in the services, prohibit the silent suppression of errors and require the protection of risky calls. The manual construction of error responses is prevented at compilation time.

9.5 Security regression tests. The suite includes dedicated tests on: coverage of the permission check on every interface, impossibility of accessing resources of other Customers, list of the operations denied to the application keys, single display of the keys, limitation of the keys to individual Digital employees, encryption of the data at rest, retention and deletion of the voice conversations, verification of the webhook signatures, protection against requests towards internal network resources, use of the Proof Key for Code Exchange and of the signed state in the authorisations, isolation of the execution of the scripts and pseudonymisation features.

9.6 Isolated execution of the scripts. The scripts defined by the Customer in the automations are executed in an isolated environment, without access to external resources and limited by recursion depth, memory, time, number of instructions and duration of the search expressions.

9.7 Error contract. The error responses returned to the clients do not contain execution traces or internal details: they are returned in a standardised format with a correlation identifier useful for support.

9.8 Transparency clarification. The Provider does not declare, as at the date of this Annex, the automatic execution in continuous integration of dependency vulnerability analysis, of secret scanning or of third-party static security analysis of the code.

10. Protection against abuse and improper use

10.1 Rate limiting of the requests. The application interfaces are protected by rate limits, with a standardised response and an indication of the waiting time. Separate policies are provided for the chat widget with an instantaneous limit and a daily budget per Customer, for the authenticated user and for anonymous traffic, as well as configurable rules for each individual path and for each individual Customer.

10.2 Processing limits. The jobs executed asynchronously are subject to a concurrency limit per Customer, which cannot be exceeded. The consumption of the Service is subject to a quota, with fail-closed behaviour when it is exceeded.

10.3 Validation of the origin of the widget. The chat widget accepts requests only from declared and verified origins. The absence of the origin results in refusal.

10.4 Integrity of the incoming communications. All the webhooks received from external providers are subject to verification of the signature, with a constant-time comparison. For the voice channel the verification includes refusal in the absence of the secret and protection against the replay of the same request based on the time reference.

10.5 Outgoing communications. The webhooks sent towards the Customer's systems are signed, so that the recipient can verify their authenticity.

10.6 Protection against requests towards internal resources. The addresses that the platform contacts at the Customer's request are subject to a check that refuses the request when even a single resolved address belongs to reserved, internal or service ranges of the infrastructure. The check is repeated at every new attempt to send.

11. Protective tools available to the Customer

11.1 Region of residence of the voice data. The selection of the European region of the voice provider, with effect on the calls and transcripts of one's own environment, is available to Customers on the Enterprise Plan; for the other plans the global region applies. For the shared voice subscriptions made available by the Provider the global region applies in any event. The features reserved to the Enterprise Plan are available where provided for in the commercial proposal accepted by the Provider, pursuant to Article 2.3 of the Conditions; the plans are described in the price list published at https://evolus.ai/en/pricing.

11.2 Routing of the requests to the models and limitation of the providers. The following are available to Customers on the Enterprise Plan, where provided for in the commercial proposal accepted by the Provider pursuant to Article 2.3 of the Conditions: the definition of the list of inference providers permitted for one's own environment, which is applied by the system and prevails over the preferences set at the level of the individual feature; the European routing of the requests to the models, by means of the European Union endpoint of the routing service; the routing solely to zero-retention endpoints. For the other plans, global routing and the inference providers on the list published on the sub-processors page, at https://evolus.ai/en/subprocessors, apply.

11.3 Retention of the voice conversations. For all plans the Customer may configure the retention period for each voice agent and may activate the mode without retention, in accordance with paragraphs 8.2 and 8.3.

11.4 Pseudonymisation and masking. The platform makes available features for the pseudonymisation of personal data and for the masking of documents. The masking of documents in PDF format is achieved by means of rasterisation, so that the masked text is no longer present in the file produced. A pseudonymisation block can be used within the automations defined by the Customer.

11.5 Protections that cannot be disabled. The Digital employees apply protections that cannot be disabled by the Customer or circumvented by means of instructions, concerning the explicit confirmation of the user before significant actions, verification of the identity of the recipient, verification of the authenticity of the sender and the declaration of artificial nature. The voice channel also applies a set of rules that cannot be disabled, protecting the personal data of employees, internal communications, economic data and opinions.

11.6 Declaration of artificial nature. The declaration of artificial nature is reapplied by the system to the outgoing communications, cannot be removed by the Customer and proof of it is retained. The Provider carries out a periodic compliance check on the communications generated.

11.7 Mobile application. The audio of the voice messages is not kept on the Provider's systems beyond the processing, only the measurement of the duration for consumption purposes remaining. The audio of the meetings recorded on the device is placed in an area excluded from the system backups. Access to the camera is excluded from the permissions of the application. The permission requests expressly declare to the user that the content passes through the Provider's systems and the artificial intelligence provider.

12. Providers and sub-processors

12.1 Selection. The Provider selects the sub-processors on the basis of the guarantees offered as regards data protection and information security, and enters into a data processing agreement with each of them with obligations no less onerous than those assumed towards the Customer.

12.2 Public list. The list of the sub-processors is published in versioned form at https://evolus.ai/en/subprocessors, indicating the activity performed, the country of establishment and the legal basis of the transfer, where applicable.

12.3 Changes. Additions and replacements are communicated to the Customer with at least 30 days' notice, with a right to object on reasoned grounds, in accordance with Article 5 of Annex A.

12.4 Transfers. The legal bases of the transfers to third countries and the features that reduce transfers reserved to the Enterprise Plan are governed by Article 6 of Annex A.

13. Management of incidents and personal data breaches

13.1 Documented procedure. The Provider maintains a documented procedure for the management of personal data breaches, which defines the detection and reporting channels, the roles and responsibilities, the operational stages with the related time limits, the criteria for assessing the risk to data subjects, the communication templates and the rules on closure, root cause analysis and verification of the corrective actions.

13.2 Internal reporting. Every person working for the Provider is required to report without delay, and in any event within one hour, any suspicious event, through the dedicated channels and without carrying out preliminary analyses, with a prohibition on altering or destroying the evidence.

13.3 Containment and preservation of the evidence. The procedure provides for standard containment measures, including the revocation of the sessions and authorisations, the blocking of accounts, the isolation of the container concerned, the suspension of the individual feature, the rotation of the secrets, the revocation of the temporary links to the files and the blocking of outgoing communications, as well as the freezing and extraction of the evidence with an integrity check.

13.4 Notification to the Customer. The Provider notifies the Customer of every breach concerning its data within 48 hours of becoming aware of it, regardless of the level of risk, with the content provided for by Article 33, paragraph 3, of the Regulation, and transmits periodic updates until the closure of the case, in accordance with Article 9 of Annex A.

13.5 Breach register. The Provider keeps a register of personal data breaches documenting the circumstances, the effects, the measures adopted, the decisions on the notifications and the related reasons, including the near misses intercepted before they produced effects.

13.6 Review and testing. The procedure is reviewed at least annually and after every breach classified as medium or high risk, and is subjected to a simulation exercise on an annual basis.

14. Personnel

14.1 Confidentiality. The persons authorised to process Customers' data have signed confidentiality agreements, the obligation under which continues after the end of the relationship.

14.2 Authorisation and instructions. Authorisation to process is granted only to the persons who need it for the provision of the Service, for assistance, for maintenance and for security, with written instructions on the manner of the processing.

14.3 Access to Customers' data. Access by personnel to Customers' data takes place by means of the platform's tools, is subject to the controls in section 2 and is logged in accordance with paragraph 2.8 and section 6.

14.4 Training. A programme for training personnel on the protection of personal data and on information security is being adopted within the management system referred to in paragraph 1.3. The Provider does not declare, as at the date of this Annex, that training has already been delivered.

15. Revision of this Annex

15.1 Update. The Provider may update this Annex to reflect the technical and organisational evolution of the measures, provided that the overall level of security is not reduced, pursuant to Article 12.5 of the Conditions.

15.2 Versioning. Each version is identified by a code and by an SHA-256 hash of the text. Previous versions remain accessible to the Customer for the entire duration of the Contract.

15.3 Communication. Updates are communicated in the manner and with the notice periods set out in Article 13 of the Conditions. Updates that entail a reduction of the guarantees give the right to withdraw without penalties in accordance with Article 13.2 of the Conditions.

15.4 Periodic review. The Provider reviews the measures at the intervals set out in paragraph 1.4 and updates this Annex in the event of a substantial change.