International data-transfer mechanism

Permafrost is operated by DuneCodeForge Ltd, incorporated in the United Arab Emirates, and our sub-processors are based in the United States. Operating the Service therefore moves personal data across borders. Rather than name the regime generically, the table below states the exact instrument that authorizes each class of transfer.

The instruments above are the standing basis for every cross-border hop. Where a sub-processor is certified under the Data Privacy Framework we may additionally rely on that adequacy decision, but the SCCs / IDTA remain in force regardless so a change in DPF status never leaves a transfer uncovered.

The EU Standard Contractual Clauses come in four modules; the right one depends on the role each party plays in a given data flow. We select per agreement:

Module One — controller to controller

Not our standard posture: we act as a processor for customer data, not an independent controller of it.

Module Two — controller to processor

The customer (controller) instructs us (processor) to read and analyze their tenant. This is the primary module for customer personal data reaching us.

Module Three — processor to processor

Our onward transfer to a sub-processor (hosting, database, email) that processes on our behalf under the same instructions.

Module Four — processor to controller

Not applicable to the Service's data flows.

The executed module for each sub-processor is recorded in that sub-processor's data-processing agreement and is provided with the signable DPA package on request.

A transfer-impact assessment — the case-by-case analysis the SCCs and UK IDTA require, weighing the destination's legal regime and the supplementary measures in place (encryption in transit, tenant isolation, zero standing write access, no customer-cloud credentials at rest) — is available to customers and their counsel on request. Email support@permafrostepm.com to receive it under your DPA.