Sub-processors

Sub-processors

This Sub-processors page identifies third-party providers that may process personal data or customer data on behalf of Etalyon Sàrl-S, operating Squillify ("Squillify", "we", "us", or "our"), in connection with the Squillify platform, APIs, dashboard, microskill execution services, billing, authentication, support, telemetry, file handling, security, and related services.

This page is a draft and is not effective until published as active by Squillify. It is intended for legal, privacy, security, procurement, and operational review before launch.

1. Purpose

This page explains:

• which third-party providers may process customer data on behalf of Squillify;
• why those providers are used;
• what categories of data they may process;
• where processing may occur;
• what transfer mechanism may apply;
• whether the provider is confirmed, planned, or pending confirmation;
• how customers are notified of changes;
• how this page relates to the Data Processing Agreement.

2. What is a sub-processor?

A sub-processor is a third party engaged by Squillify to process personal data on behalf of Squillify's customers where Squillify acts as processor.

Examples may include providers used for:

• cloud hosting;
• managed databases;
• object storage;
• authentication;
• payment processing;
• email delivery;
• monitoring;
• logging;
• customer support tooling;
• analytics;
• security operations.

Not every third-party provider is necessarily a sub-processor in every context. A provider may act as:

• Squillify's sub-processor;
• Squillify's independent controller;
• the customer's directly appointed provider;
• a provider used by a customer-configured external endpoint;
• an external service used by a specific microskill.

The role depends on the provider, service, configuration, and processing context.

3. Current status

The sub-processor list is being finalised ahead of launch.

Entries marked Pending confirmation indicate details that must be confirmed before the relevant provider begins production processing of customer personal data or before this page becomes active.

No active version of this page should contain:

• Pending confirmation;
• Pending legal confirmation;
• unknown processing regions;
• unknown transfer mechanisms;
• unknown legal entity names;
• missing provider policy links;
• missing provider DPA or data processing terms where applicable.

4. Sub-processor list

The structured sub-processor table is defined in this document's frontmatter and should be rendered by the Trust Center using the following columns:

The page may display provider categories during draft/prelaunch. Before publication as active, production providers should be identified by actual provider name and legal entity where possible.

5. Provider statuses

Squillify may use the following statuses:

6. Required information before active publication

Before this page becomes active, Squillify must confirm for each production sub-processor:

• provider name;
• legal entity;
• service used;
• purpose;
• categories of data processed;
• whether the provider processes Customer Personal Data;
• processing region;
• storage region;
• backup region where applicable;
• transfer mechanism where applicable;
• provider privacy policy link;
• provider DPA or data processing terms link;
• security or trust page link where useful;
• whether the provider is used at launch;
• whether the provider is optional or required;
• whether the customer can disable the related feature.

7. Sub-processor authorisation

Where Squillify acts as processor, the Data Processing Agreement provides general authorisation for Squillify to engage sub-processors, subject to the terms of the DPA.

Under GDPR Article 28, a processor must not engage another processor without the controller's prior specific or general written authorisation. Where general written authorisation is used, the processor must inform the controller of intended changes concerning addition or replacement of sub-processors and give the controller an opportunity to object.

The DPA describes the customer notice and objection process.

8. Change notifications

Squillify may notify customers of material changes to sub-processors through one or more of:

• this page;
• dashboard notice;
• email notice;
• Trust Center update;
• release notes;
• contractual notice;
• support communication.

Unless a separate agreement says otherwise, customers with a DPA may object to a new sub-processor on reasonable data protection grounds within the period specified in the DPA or notice.

If no period is specified, the draft DPA currently uses a 30-day objection period.

9. Customer objections

If a customer objects to a new sub-processor on reasonable data protection grounds, Squillify will use reasonable efforts to resolve the objection.

Resolution may include:

• providing additional information;
• clarifying the provider's role;
• confirming region or transfer mechanism;
• offering a workaround where available;
• delaying use for that customer where practical;
• disabling an optional feature where practical;
• allowing termination of affected services in accordance with the DPA or Terms.

Squillify is not required to provide a custom infrastructure stack, custom provider exclusion, or dedicated environment unless agreed in writing.

10. International transfers

A sub-processor may process personal data outside the European Economic Area.

Where personal data is transferred outside the EEA, Squillify will use a transfer mechanism required by applicable data protection law, such as:

• adequacy decision;
• Standard Contractual Clauses approved by the European Commission;
• provider data processing terms;
• supplementary measures where required;
• EU-only processing configuration where available.

Transfer mechanisms must be confirmed before this page becomes active.

Customers subject to sector-specific obligations must assess whether the provider, region, transfer mechanism, and service configuration are acceptable for their own use case.

11. Platform providers vs skill-specific external services

This page focuses on platform sub-processors used to operate Squillify.

Some microskills may use external services as part of their specific function. Those external services may vary by skill and are addressed in the External Service Use Policy and skill documentation.

A provider may appear both:

• on this Sub-processors page if it processes personal data on behalf of Squillify or customers; and
• in skill-level documentation if it processes data as part of a specific microskill execution.

Customers should review both this page and the relevant skill-level data handling information before using a skill with personal, confidential, sensitive, regulated, or third-party data.

12. Payment processors

Payment processors may process billing and payment-related data.

Depending on the arrangement, a payment processor may act as:

• Squillify's processor or sub-processor;
• an independent controller for certain payment, fraud, tax, or compliance processing;
• both, depending on the activity.

The Billing and Refund Policy and Privacy Policy describe payment-related data handling.

Invoices issued to customers are issued by Squillify or on behalf of Squillify through the billing provider unless a different merchant-of-record arrangement is expressly stated.

13. Authentication providers

Authentication providers may process account identity data, tenant membership metadata, session metadata, authentication events, and security signals.

Customers should not assume that authentication data remains within a single country unless the provider region and configuration are confirmed.

14. Infrastructure and storage providers

Infrastructure, database, and object storage providers may process or store platform data, operational metadata, temporary files, logs, backups, or security data depending on configuration.

Before this page becomes active, Squillify must confirm:

• hosting provider;
• database provider;
• object storage provider;
• primary region;
• backup region;
• encryption configuration where relevant;
• transfer mechanism;
• provider DPA.

15. Monitoring, logging, and support providers

Monitoring, logging, and support providers may process operational metadata, error metadata, support records, security signals, and customer communications.

Squillify's logging practices are designed to avoid permanent raw microskill payload capture as part of normal execution.

Customers should not include unnecessary personal data, secrets, credentials, payment card data, confidential data, or regulated data in support requests.

16. Security review of providers

Squillify should review production providers based on their role and risk.

Review criteria may include:

• provider reputation;
• security documentation;
• DPA availability;
• processing region;
• transfer mechanism;
• access controls;
• encryption;
• incident response commitments;
• sub-processor transparency;
• data retention;
• deletion practices;
• availability and resilience;
• compliance reports or certifications where available;
• contractual fit with Squillify's obligations.

The depth of review may depend on the provider's role and data exposure.

17. Regulated customers

Customers subject to financial-sector, public-sector, healthcare, defence, education, employment, DORA, CSSF, outsourcing, professional secrecy, or similar obligations are responsible for assessing whether Squillify's sub-processors are acceptable for their use case.

Unless expressly agreed in a separate written enterprise agreement, Squillify does not commit to customer-specific provider restrictions, localisation, subcontracting approval workflows, audit rights, regulatory access rights, DORA-specific terms, or outsourcing-specific terms.

18. Customer-configured external providers

Some features may allow customers to configure their own external endpoints, webhooks, APIs, storage destinations, tools, or providers.

Customer-configured providers are the customer's responsibility.

They are not necessarily Squillify sub-processors because the customer chooses and controls them.

The customer is responsible for:

• selecting the provider;
• assessing legality and security;
• obtaining any required approvals;
• configuring credentials;
• managing downstream processing;
• ensuring the provider may receive the data;
• complying with applicable laws and contracts.

Customer-configured external providers are addressed in the External Service Use Policy.

19. Historical providers

Where a provider is removed, replaced, or deprecated, data may remain with that provider for a limited period due to:

• retention obligations;
• backup cycles;
• invoice or billing records;
• security logs;
• support records;
• dispute records;
• legal holds;
• provider deletion cycles.

The Sub-processors page may identify removed or deprecated providers where relevant.

20. Relationship with other policies

This page should be read together with:

• Data Processing Agreement;
• Privacy Policy;
• Security Policy;
• Data Retention Policy;
• External Service Use Policy;
• Microskill Data Handling Policy;
• File Handling Policy;
• AI / Training Use Policy;
• Support Policy;
• Billing and Refund Policy.

If there is a conflict between this page and the Data Processing Agreement regarding processing of Customer Personal Data on behalf of a customer, the Data Processing Agreement controls.

21. Contact

For questions about sub-processors, contact:

• Legal: [email protected]
• Privacy: [email protected]
• Security: [email protected]
• Support: [email protected]

For sub-processor objections under a DPA, contact [email protected].