#Danish Cloud Position and Supervisory Response

DIS-DK-001 v1.0.0, Last Modified On 01 August 2026, Tier: Public

Written for the Danish hospital's databeskyttelsesrådgiver. It answers the question that decides a Danish deal (can we lawfully run a hyperscaler-hosted system operated from India?) and it answers the follow-up question, which is harder and which most vendors do not anticipate.

---

#Applicability

---

#1. The short answer

---

#2. What the Danish cloud guidance actually requires of a controller

The Danish supervisory authority publishes cloud guidance that is unusually specific for a European authority. Its load-bearing requirements on a Danish controller, and where Pensieve Labs answers each:

Requirement 5 is the one that shapes architecture rather than paperwork. It is why Pensieve Labs's Danish design holds data in an EEA region under EEA-held keys, resolves support views pseudonymously by default, and treats plaintext access as break-glass. A Danish deployment built any other way puts the whole weight on the assessment of Indian law, which does not support it.

---

#3. The residual criticism, and why it is about Pensieve Labs

When the Danish examination of municipal cloud use closed, what remained was not a finding against the cloud, against the provider's contract, or against the destination being outside Denmark. What remained was a finding against the controllers' documentation, on three points:

1. A sub-processor verification deficit. The controllers had not documented how they satisfy themselves that the provider's sub-processors actually meet the obligations flowed down to them.
2. No assessment of transfers to third-country sub-processors. Transfers to sub-processors located outside the EEA (India named explicitly among them) had not been assessed.
3. No assessment against the four European Essential Guarantees for those destinations, and no standing process for keeping the lawfulness documented as contracts change.

Translate that into Pensieve Labs's position. In a Danish deployment Pensieve Labs is not the hyperscaler. Pensieve Labs is the Indian sub-processor whose absence of documentation Danish public authorities were just criticised for. Every Danish security review from here asks the same three questions, and a vendor that has not anticipated them loses ten to twenty-five days answering them from a standing start.

Pensieve Labs's answer, item by item:

The honest framing for a Danish buyer. A hospital that has read the coverage of the municipal case and is handed a completed India assessment plus an evidenced verification programme is being handed exactly the thing its public-sector peers were faulted for not having. That is a differentiator, and it is the reason Pensieve Labs publishes the assessment rather than supplying it on request.

---

#4. Where the data actually is

There is no cloud region in Denmark for the infrastructure Pensieve Labs uses. A data-centre building located in Denmark is not a cloud region, and a vendor implying otherwise should be asked for the region identifier.

The full statement is DIS-EU-008; this section exists only so a Danish reader does not have to open two documents to answer the first question their director will ask.

---

#5. CPR numbers: the Danish-specific point

The Danish civil registration number is regulated by Section 11 of databeskyttelsesloven and sits outside Article 9. It is not special-category data, but its processing by a private entity is restricted: lawful where required by law, where the data subject has given explicit consent, or where unique identification is decisive and required.

For Pensieve Labs this has two concrete consequences:

1. The CPR number is the patient identifier throughout Danish healthcare, including in the national FHIR profiles. Pensieve Labs processes it in every Danish deployment. The lawful basis is the hospital's, flowing from the treatment purpose, and the hospital's own record of processing should cite Section 11 expressly. DPA-EU-001 Annex IV-1 records this so the hospital does not have to draft it.
2. Pseudonymisation of the CPR mapping is the single most effective supplementary measure Pensieve Labs can offer a Danish controller. The mapping between the CPR number and the internal record identifier is held under a key the hospital controls, so an India-resident support session sees pseudonymous records. It is cheap built early and painful retrofitted, and Pensieve Labs has built it that way.

The identifier model is not one number per patient. The Danish national profiles reflect the CPR number together with replacement identifiers issued nationally and regionally for people who do not hold one. A system built on the assumption of a single national identifier fails on the first tourist, the first newborn and the first unidentified emergency admission. Pensieve Labs models multiple identifier namespaces natively; STM-DK-002 Section 6 states the conformance position.

---

#6. The transfer question does not disappear in DM-3 or DM-4

Under no model does EEA hosting make offshore access invisible to the Danish supervisory authority, and Pensieve Labs will not claim that it does.

---

#7. DM-2: the shared-platform question a Danish buyer will ask

A shared multi-tenant platform that reaches Danish national services on behalf of several hospitals attracts a question that Pensieve Labs must be able to answer in writing before the platform touches those services: how are one hospital's national-service credentials isolated from another's?

The answer is in DIS-GL-032 (multi-tenancy isolation) and DIS-GL-025 (credential custody), and the Danish-specific statement is in STM-DK-002 Section 5. Pensieve Labs does not offer DM-2 into Denmark for a deployment that consumes national services until that statement is executed and current. DM-1 is the recommended Danish model, and it is also the fastest.

---

#8. What a Danish hospital should ask for, and get in one download

Delivered within five business days of a request, as one download, with a version stamp on every item. Removing this from the critical path is worth ten to twenty-five days on a Danish deal on its own.

---

#9. Limitations

9.1 This is not Danish legal advice. It is Pensieve Labs's reading of published Danish supervisory guidance and decisions. [A Danish controller carries its own assessment. The supervisory authority does not pre-approve architectures, and Pensieve Labs does not represent that it has been reviewed by one.]

9.2 The supervisory position can change. A new decision, new sector-specific cloud guidance, or a judgment affecting Article 46 transfers reopens REP-GL-021 under its own triggers.

9.3 Pensieve Labs holds no certification. Nothing here substitutes for one and nothing here claims to. WPR-GL-005 states the position.

9.4 The Danish assurance material is in English. Translation of the core pack into Danish is a real, routinely underestimated cost and is a market-entry line item, not a per-deal one. The contract itself is accepted in English by Danish counterparties as a matter of routine.

---

#10. Related documents

---

#11. Change history