Service configuration:
Data Processing

How we handle your data

ME-TA is a Danish data processor under GDPR and Danish law. This page describes where your data goes, who sees it, and what is retained where — under which contractual instrument.

ME-TA's standard DPA. The diagrams and templates on this page represent ME-TA's standard Data Processing Agreement and the architecture it describes. With each sponsor, the standard undergoes modifications to meet specific requirements arising from the sponsor's procurement, regulatory, and operational context. Binding terms arise from the per-engagement Art. 28 contract negotiated and signed with each controller; this page is informational.

TL;DR. A sponsor uploads data through metawebservice.com directly into customer-scoped storage in AWS eu-west-1 (Ireland) under the AWS GDPR Data Processing Addendum. ME-TA operators on company-owned, BitLocker-encrypted PCs run a WinForms client that processes the engagement locally on the PCwork/ (human-actor) and sce/ (machine-only deterministic SAS compute, no AI). Deliverables return to the sponsor through metawebservice.com. Client-work data is stored and processed intra-EEA, and the default transfer path is intra-EEA end to end — no GDPR Chapter V transfer occurs in the standard configuration. The engaged infrastructure sub-processor is AWS EMEA SARL (Luxembourg); the full live register is published at policy.me-ta.dk. Breach-notification commitment: 24 hours to the controller, well inside the 72-hour GDPR maximum.

TL;DR. A sponsor uploads data through metawebservice.com directly into customer-scoped storage in AWS eu-west-1 (Ireland) under the AWS GDPR Data Processing Addendum. ME-TA operators on company-owned, BitLocker-encrypted PCs run a WinForms client that processes the engagement locally on the PCwork/ (human-actor) and sce/ (machine-only deterministic SAS compute). Deliverables return to the sponsor through metawebservice.com. Client-work data is stored and processed intra-EEA, and the default transfer path is intra-EEA end to end — no GDPR Chapter V transfer occurs in the standard configuration. The engaged infrastructure sub-processor is AWS EMEA SARL (Luxembourg); the full live register is published at policy.me-ta.dk. Breach-notification commitment: 24 hours to the controller, well inside the 72-hour GDPR maximum.

AI-assisted production is not part of the base service. It exists only as a per-engagement election, governed by a dedicated AI addendum to the DPA: ME-TA-operated through ME-TA's own client and platform software on EU-region AWS Bedrock or on ME-TA's own self-hosted inference server in Denmark, or sponsor-operated in the sponsor's own approved AI tenant. The inference target is agreed per engagement and stays in the EU on the ME-TA-operated options. The platform carries AI capabilities (AI-knowledge conversion, redaction candidates, a study assistant); under the base service they are not used for the engagement (P22 §22.3.6), and by validated requirement they can reach only those ME-TA-controlled inference paths. In every case: curated operational content only; patient-level data excluded in the standard configuration; no third-party AI tool carries client content; Anthropic is the upstream model author, not engaged as a separate sub-processor on the Bedrock path. See the AI-election section below.

At a glance — four trust boundaries

Before the architecture detail below, the four areas a sponsor's IT and procurement function typically check first. Each is grounded in a named control, not an abstract claim.

Identity

AWS Cognito + customer SSO

Cognito user pool with passwordless sign-in: SAML federation to the sponsor's identity provider, configured per sponsor (P07 §7.11.1), or email one-time codes. Session tokens expire within 60 minutes (P07 §7.2).

With federation elected, sponsor users sign in with their corporate credential — no separate ME-TA password to manage, and account lifecycle stays in the sponsor's IdP.

Network

EU regions only, sponsor-scoped storage

Amazon VPC with private subnets for the data plane; encryption at rest throughout (S3 server-side encryption, Aurora storage encryption, both under AWS-managed keys). Regions: eu-west-1 (storage); AI inference on EU infrastructure when elected.

Amazon VPC with private subnets for the data plane; encryption at rest throughout (S3 server-side encryption, Aurora storage encryption, both under AWS-managed keys). Region: eu-west-1 (storage).

Each sponsor's files are held under a sponsor-scoped storage path, with temporary credentials scoped to one access class of one study. Storage and processing never leave EU regions, and the default upload path is intra-EEA end to end. One disclosed exception exists: an optional client-side accelerated-upload mode (off by default) routes encrypted upload transit via the AWS edge network for throughput; files are stored in the EU in either mode. No Chapter V transfer arises in the standard configuration.

Process

QMS at policy.me-ta.dk

22 effective policies (P01–P22), including AI-usage governance (P22-AI Usage v02, effective 25 AUG 2026); version-controlled; named policy owners; change-control discipline. Covers 21 CFR Part 11, EU Annex 11, ICH E6(R3), GDPR, AI usage.

22 effective policies (P01–P22); version-controlled; named policy owners; change-control discipline. Covers 21 CFR Part 11, EU Annex 11, ICH E6(R3), GDPR.

Audit-traceable; the effective policy set is publicly readable, so reviewers can verify the controls directly rather than request excerpts.

Contracting

GDPR Art. 28 DPA — standard template

Art. 28 obligations, intra-EEA processing, 24-hour breach notification, dedicated AI-specific addendum, sub-processor changes notified before they take effect (30-day objection window).

Art. 28 obligations, intra-EEA processing, 24-hour breach notification, sub-processor changes notified before they take effect (30-day objection window).

The four substantive procurement gates pre-handled in ME-TA's standard template at policy.me-ta.dk. Each sponsor's executed DPA reflects modifications negotiated with the sponsor's legal function to meet that sponsor's specific requirements; ME-TA's standard template is the opening draft.

The statistical backbone: audit-ready by design

Both views of this page rest on the same foundation: a validated, audit-ready statistical computing environment operated by ME-TA statisticians.

Validated compute

Deterministic SCE, validated state

The Statistical Computing Environment runs deterministic SAS under a Validation Master Plan and a signed Validation Report (VMP 1-5.1 v05, VR 1-5.3 v02), with evidence records frozen per release; the current released record is SCE 2026.09.2 (08 SEP 2026). Programs, outputs, and logs carry full versioning in customer-scoped S3, with audit-trail metadata on every artifact. AI inference is outside the validated scope (VMP §5.5); the controls that confine it are inside it.

Designed for 21 CFR Part 11 and EU Annex 11 alignment: attributable, contemporaneous, original, accurate records with a reconstructable history. A clause-by-clause mapping (1-5.4 v01) is maintained; validation records are available under NDA or audit rights. Electronic signatures are deployed but not yet exercised on a production record.

Regulatory frame

GCP-aligned by design

Delivery runs under ME-TA's 22-policy version-controlled Quality Management System at policy.me-ta.dk, designed for alignment with: 21 CFR Part 11 · EU Annex 11 · ICH E6(R3) · ICH E9 · GDPR.

Alignment is stated at design level and evidenced through the QMS and the audit trail, not asserted as a certification.

Statistical expertise

Statisticians deliver, the platform proves it

ME-TA statisticians and statistical programmers produce the deliverables; the SCE wraps their work in versioning, execution logs, and audit metadata.

The service is expert statistics; the environment makes every result reproducible and inspectable.

Deterministic by default — AI only by election

The base engagement runs entirely without AI: human statisticians (WORK) and validated, deterministic SAS compute (SCE), governed by the standard Art. 28 DPA. AI-assisted production is an optional election — governed by a dedicated AI addendum and recorded in the DPA's annex elections. The statistical service and its deliverables are the same either way.

The base service — no AI

WORK + SCE only

The default posture. ME-TA statisticians and programmers deliver through the human and deterministic-compute stages alone; no AI addendum is attached to the DPA.

None of the AI sections on this page apply — the standard DPA alone governs the engagement.

AI election A — ME-TA-operated

ME-TA's own software on Bedrock EU / self-hosted in Denmark

AI drafting and assistance through ME-TA's own client and platform software (Tier 1 under P22 §22.3.3): the Windows client's AI surfaces call ME-TA's self-hosted inference server on ME-TA's own hardware in Denmark; server-side platform capabilities call EU-region AWS Bedrock or the same self-hosted server. Category A content only, under the AWS GDPR DPA on the Bedrock path. No third-party AI tool carries client content: Claude Code is approved for ME-TA's internal platform development only (approved-tools register F161). This is the AI architecture described in the AI sections of this page.

AI drafting and assistance through ME-TA's own client and platform software (Tier 1 under P22 §22.3.3): the Windows client's AI surfaces call ME-TA's self-hosted inference server on ME-TA's own hardware in Denmark; server-side platform capabilities call EU-region AWS Bedrock or the same self-hosted server. Category A content only, under the AWS GDPR DPA on the Bedrock path. No third-party AI tool carries client content: Claude Code is approved for ME-TA's internal platform development only (approved-tools register F161). This is the AI architecture shown in the AI-enabled view of this page.

Fastest path. ME-TA carries the full AI governance surface and produces the audit evidence.

AI election B — sponsor-operated

Your AI tenant, your approved tool

The AI stage calls the sponsor's own approved AI deployment — for example an Azure OpenAI or AWS Bedrock tenant operated by the sponsor, under the sponsor's identity provider. ME-TA operates none of the inference.

If your AI-usage policy permits only tools approved by your own IT, this election satisfies it by construction — the AI-inference sub-processor drops out of ME-TA's chain entirely.

Whenever AI is elected: a human reviews all AI-assisted output before anything returns to the sponsor, and the AI has no write access to sponsor systems — it drafts, humans decide. The elections apply equally to clinical trials and to clinical investigations / performance studies (MDR / IVDR).

Reading this page: the AI-specific detail (data categories and the AI-assisted workflow loop) sits in the purple ▸ panels below.

AI data categories — Category A and Category B (applies when AI is elected)

The diagrams below refer to Category A and Category B. These are ME-TA's two data classes for AI processing, defined in P22-AI Usage §22.4 and used in the same way in every ME-TA DPA. The same vocabulary runs through SVGs 1–4, the sub-processor schedule, and the AI addendum.

Category A — permitted to AI

Curated operational content

SAPs, protocols, investigator brochures, table/listing/figure shells, SAS/R programs, define.xml, dataset specifications, SOPs and QMS templates, regulatory correspondence (FDA, EMA, notified bodies), reviewed context files, blank CRF templates.

No patient-level data; no trial-subject identifiers. The day-to-day work products of statistical programming and regulatory writing.

Category B — excluded from AI

Patient & study-integrity data

Patient-level clinical data (including completed CRFs), randomisation codes, unblinding information, unblinded interim or final results, trial-subject PII (name, DOB, address, hospital/national ID), customer-proprietary data without sponsor-DPA AI permission, US PHI under HIPAA.

A leak here would be a clinical-integrity or compliance event. Excluded from the AI leg in the standard configuration. Where an engagement provides for a capability that must read protected content (redaction, anonymisation), Category B may be processed on ME-TA-controlled inference only, under P22 §22.4.3: confinement to Tier 1, human authority over the result, and cover in the DPA.

Elevated-sensitivity content is a sub-class of Category A where a leak would carry material competitive harm to the sponsor — for example, device-specific failure analyses, post-market surveillance root-cause investigations, or trade-secret methodology. Routes through the same AI inference architecture as other Category A content; additional review gates can be agreed per engagement, and uncertain classifications escalate to the CEO (P22 §22.4).

Standard configuration vs per-engagement. ME-TA's standard offering is the classification above. Sponsors who require a different split — for instance, AI use on a Category-B-class data set under their own DPA and risk-control framework — can have a per-engagement configuration; that is negotiated as a sponsor-specific modification to the standard DPA, not by changing the categories themselves.

How a sponsor engagement runs

The base engagement is four steps — deterministic and human-driven throughout. With an AI election in place, program development is augmented by the AI-assisted loop in the panel below; the data boundaries and the human review gate are identical in both.

The engagement is four steps: deterministic and human-driven throughout, with the human review gate before anything returns to the sponsor.

  1. 1
    WORK · Ireland storage

    Sponsor uploads engagement data

    Datasets, protocol, investigator brochure, SAP, CRF templates, prior submission files — all uploaded by the sponsor through metawebservice.com directly into customer-scoped storage in AWS eu-west-1 (Ireland).

  2. 2
    WORK · operator PC

    ME-TA statisticians develop the statistical programs

    Human work in the WORK stage on the ME-TA-owned, BitLocker-encrypted operator PC — programs, specifications, drafts. Full data access by the engagement-assigned human; nothing leaves the intra-EEA chain.

  3. 3
    SCE · local validated compute

    Programs execute on the SCE

    The SAS programs run on the Statistical Computing Environment — validated, deterministic, no AI present. Full datasets are used here. Outputs and logs are produced.

    The SAS programs run on the Statistical Computing Environment: validated and deterministic. Full datasets are used here. Outputs and logs are produced.

  4. 4
    WORK → sponsor · human review

    Human reviews outputs; sponsor receives deliverables

    The ME-TA data processor reviews the outputs in the WORK stage. Approved deliverables are returned to the sponsor through metawebservice.com.

The AI-assisted loop — seven steps (AI elections A / B only)

With an AI election in place, the engagement runs as seven steps from sponsor upload to sponsor deliverable. Steps 4–6 are the SCE ↔ AI iteration loop; the loop runs as many times as the work requires, and only step 7 returns un-redacted material to a human. The data flow in SVG 1 below is this same workflow rendered visually.

  1. 1
    WORK · Ireland storage

    Sponsor uploads engagement data

    Datasets, protocol, investigator brochure, SAP, CRF templates, prior submission files — all uploaded by the sponsor through metawebservice.com directly into customer-scoped storage in AWS eu-west-1 (Ireland). Lands in the WORK stage; nothing has moved to AI yet.

  2. 2
    WORK stage → AI stage · reviewed promotion per DPA

    ME-TA reviews files and promotes them to the AI stage according to the DPA

    A ME-TA data processor reviews the sponsor's upload and promotes files to the AI stage according to what the per-engagement DPA permits. Typical promoted content: dataset metadata (the schema, not the data itself), redacted confidential documents, specifications, regulatory correspondence — i.e., Category A files per P22 §22.4. The DPA scopes which files may be promoted; ME-TA the data processor performs the review and the promotion. Discretionary human act — no file enters AI without it.

  3. 3
    AI · EU inference

    AI drafts SAS programs

    The AI stage drafts SAS programs from the promoted Category A specifications, on the agreed EU inference target. Client-side inference sends prompt content from the operator PC to ME-TA's self-hosted server in Denmark over authenticated TLS; server-side conversion and redaction send document content from eu-west-1 to the same server, or to EU-region Bedrock, which stays inside AWS EU regions. No conversation history is retained across invocations (INF-05-API).

  4. 4
    SCE · local validated compute

    SAS programs execute on the SCE

    The SAS programs run on the Statistical Computing Environment — validated, deterministic, no AI present, no human in the loop during execution. Full datasets are used here. Outputs and logs are produced.

  5. 5
    SCE stage → AI stage · context return

    Logs and redacted outputs returned to AI as context

    Log files and redacted outputs flow back to the AI stage as context for the next iteration.

  6. 6
    AI · iterate

    AI updates SAS programs — repeat from step 4

    AI revises the SAS programs based on the redacted logs and outputs. Steps 4 → 5 → 6 loop until the programs run clean and produce the expected deliverables.

  7. ↻ steps 4 → 5 → 6 repeat until clean
  8. 7
    WORK → sponsor · human review

    Human reviews un-redacted outputs; sponsor receives deliverables

    The ME-TA data processor reviews un-redacted outputs in the WORK stage — full data access by a human, no AI present at this step. Approved deliverables are returned to the sponsor through metawebservice.com.

Election differences: under AI election B, step 3 (and step 6) run against the sponsor's own AI tenant instead of ME-TA's inference path — everything else is identical. With no AI elected, this loop does not run at all; the four-step base workflow above is the whole engagement.

1. Where your data goes

A sponsor's data follows a deterministic path from upload through ME-TA's three-stage architecture and back to the sponsor as deliverables. Every box and arrow below is under contractual coverage of the AWS GDPR DPA or ME-TA's own QMS controls. The AI stage and the Bedrock leg exist only when an AI election is in place (election A shown; under election B the inference target is the sponsor's own tenant; with no AI elected, those elements are absent and the diagram reduces to WORK ↔ SCE ↔ S3).

A sponsor's data follows a deterministic path from upload through ME-TA's two stages (WORK and SCE) and back to the sponsor as deliverables. Every box and arrow below is under contractual coverage of the AWS GDPR DPA or ME-TA's own QMS controls.

End-to-end data flow — sponsor → AWS EU → ME-TA operator → AWS EU → sponsor
SPONSOR ZONE browser · sponsor personnel AWS EU — under AWS GDPR DPA AWS EMEA SARL (Luxembourg) — eu-west-1 Ireland (storage / auth) · EU inference (when elected) ME-TA OPERATOR ZONE Denmark · ME-TA-owned, BitLocker-encrypted PC · WinForms client runs work/ sce/ ai/ locally B1 — Sponsor user browser · SAML SSO / OTP B2 — metawebservice.com web edge · API eu-west-1 · no file content B3 — Amazon S3 eu-west-1 · AES-256 · customer-scoped all versions · full audit trail B4 — Aurora metadata · audit trail programs · logs B5 — Cognito auth optional — AI election A only B7 — EU inference target AWS Bedrock, EU regions · text-only Anthropic Claude (model author · not in data path) stateless · no retention · no training or ME-TA self-hosted server, Denmark (see note) WinForms client (meta-cli + stage runner) three stages on the operator's PC · files local · BitLocker AES-256 full-disk encryption WORK stage human-actor · full data programs · drafts · outputs meta-cli sync ↔ S3 SCE stage machine-only · SAS deterministic compute no AI invoked here AI stage ME-TA client software · if elected own harness (Tier 1) · Cat A only → self-hosted server (DK) B9 — local AI-tool caches if any, on the operator PC purged at engagement close (P22 §22.3.5) A1 HTTPS / auth A3 direct upload (pre-signed) A13 download deliverable A6 meta-cli sync A7 push outputs A8 job A9 out automated redaction ME-TA reviews & promotes per DPA (Cat A files only) A10 prompt text → inference A11 ← completion text (model reply) TXT Text-only inference channel · prompt and completion text only A12 cache Client-work data stored and processed intra-EEA — no Chapter V transfer in the standard configuration SPONSOR ZONE browser · sponsor personnel AWS EU — under AWS GDPR DPA AWS EMEA SARL (Luxembourg) — eu-west-1 Ireland (storage / auth) ME-TA OPERATOR ZONE Denmark · ME-TA-owned, BitLocker-encrypted PC · WinForms client runs work/ sce/ locally B1 — Sponsor user browser · SAML SSO / OTP B2 — metawebservice.com web edge · API eu-west-1 · no file content B3 — Amazon S3 eu-west-1 · AES-256 · customer-scoped all versions · full audit trail B4 — Aurora metadata · audit trail programs · logs B5 — Cognito auth WinForms client (meta-cli + stage runner) two stages on the operator's PC · files local · BitLocker AES-256 full-disk encryption WORK stage human-actor · full data programs · drafts · outputs meta-cli sync ↔ S3 SCE stage machine-only · SAS validated deterministic compute full audit trail A1 HTTPS / auth A3 direct upload (pre-signed) A13 download deliverable A6 meta-cli sync A7 push outputs A8 job A9 out Client-work data stored and processed intra-EEA — no Chapter V transfer in the standard configuration

End-to-end data flow. The three inter-stage control gates (human-gated promotion, SAS-file submission, automated redaction) are described in the narrative bullets below — this diagram answers "where does data physically go?" only.

End-to-end data flow. The WORK to SCE gate (SAS job submission and results return) is described in the narrative bullets below; this diagram answers "where does data physically go?" only.

Reading the diagram

The three inter-stage control gates

Each transition between stages inside the WinForms client is controlled — by humans, by structural design, or by an automated filter. None of these controls is shown on the diagram above (which answers only "where does data go?"); they are stated here in prose:

  • WORK → AI is reviewed promotion per DPA. ME-TA, acting as data processor, reviews each upload and promotes files to the AI stage according to what the per-engagement DPA permits — typically Category A files per P22 §22.4 (dataset metadata, redacted documents, specifications, regulatory correspondence). Promotion is a discretionary human act; no file enters AI without it.
  • AI → SCE carries SAS files. The AI stage authors statistical code (programs, macros, listings, table specs) and submits them to SCE for deterministic execution. No AI runs inside SCE — only the code does.
  • SCE → AI passes through automated redaction. Log files are submitted as context only where free of patient-level values; a log that may embed data values is treated as Category B until confirmed otherwise (P22 §22.3.3). Output files pass through an automated redaction step during context conversion; no third-party redaction service is in the data path. Only the redacted version reaches AI. Original outputs, redacted outputs, programs, and logs are all synced to customer-scoped S3 with full versioning and audit-trail metadata per the QMS retention policy, independently reconstructable on audit. The structural guarantee is on AI's input scope (only redacted reaches AI), not on storage location.

The WORK ↔ SCE gate

The single inter-stage transition in the base service is controlled: the WORK stage submits SAS programs to SCE for deterministic execution, and results return to WORK for human review. Programs, outputs, and logs are synced to customer-scoped S3 with full versioning and audit-trail metadata per the QMS retention policy, independently reconstructable on audit.

2. Who actually sees your data

Each row below is an actor in or around the data flow. Each column is a class of data. A cell shows the maximum visibility under normal operations; least-privilege controls in our QMS reduce actual visibility further per engagement role.

Actor visibility matrix
Trial data (Category B) (patient-level) Cat A operational Operational content Cat A elevated-sensitivity Elevated sensitivity content AI (if elected) prompts/completions Audit metadata User account info Aggregate platform metrics Sponsor user (controller) their own session their own engagement none ME-TA operator (engagement-assigned) their own session their own actions own none ME-TA admin / DPO metadata only* metadata only* metadata only* none AWS (EMEA SARL) sub-processor encrypted bytes only encrypted bytes only encrypted bytes only in transit only none encrypted bytes only none Anthropic upstream model author — not engaged as a sub-processor none none none none none none none Ancillary sub-processors Microsoft 365 · email · device mgmt · admin only none none none none none limited contact data none full visibility (within engagement scope) metadata-only / encrypted-bytes-only / scoped none structural denial * ME-TA admin / DPO visibility into clinical content is gated by customer-admin authorisation per P07 §7.10 and P21 §21.8. ME-TA personnel do not readily have access to customer content unless the customer has granted access.

* ME-TA admin / DPO visibility into clinical content is gated by customer-admin authorisation per P07 §7.10 and P21 §21.8. ME-TA personnel do not readily have access to customer content unless the customer has granted access. Engagement-specific contractors, approved by the customer per P17, act within the ME-TA operator row. Ancillary sub-processors (Microsoft 365 for workforce email and documents, Intune device management and Defender endpoint protection on operator PCs) see endpoint telemetry and contact data only; the full register is at policy.me-ta.dk (P21 §21.11).

3. What is retained where

What is kept, where it is kept, how long, and under which contractual instrument.

Retention picture — by location, with country, duration, and governing instrument
Client-work data: stored & processed intra-EEA · No Chapter V transfer in the standard configuration Location What is retained Country Duration (solid = fixed · hatched = variable) Governing instrument 5y 10y 15y 20y 25y AWS eu-west-1 (Ireland) S3 — submission-bound clinical data 🇮🇪 Ireland up to 25 y AWS GDPR DPA + Services agreement S3 — temporary / draft data 🇮🇪 Ireland removable after 1y prod · 3y backup (P06 §6.3) AWS GDPR DPA Aurora: metadata, programs, logs, audit trail 🇮🇪 Ireland engagement + audit horizon AWS GDPR DPA Cognito — user accounts 🇮🇪 Ireland lifetime · inactive 90 d removed (P07 §7.2) AWS GDPR DPA AI interaction log (server-side invocations) 🇮🇪 Ireland as agreed in the AI addendum AWS GDPR DPA + ME-TA QMS Backups (encrypted) 🇩🇪 Germany Aurora 7-day PITR · S3 replica eu-central-1 AWS GDPR DPA AWS EU inference (AI election A) Bedrock — AI inference (AI election A only) 🇪🇺 EU none beyond request lifetime AWS GDPR DPA stateless prompt path · no training · invocation logging Processor-controlled Denmark — operator workstation (ME-TA-owned, BitLocker) work/ stage files 🇩🇰 Denmark engagement duration ME-TA QMS (own custody) local AI-tool caches (if any) 🇩🇰 Denmark until engagement close (P22 §22.3.5) ME-TA QMS Audit metadata persists for the regulatory retention period independently of, and after, conversation-content deletion. Audit metadata persists for the regulatory retention period independently of, and after, working-file deletion.

Durations are policy windows (P06 §6.3), not automatic purges: the platform never destroys a record in-app (RS 1-5.2.1 H-19); temporary data may be removed after 1 year in production and 3 years in backups; end-of-engagement return or deletion is executed as a controlled operation on the controller's election (DPA Clause 5.6).

Client-work retention only. ME-TA's internal-only use of consumer-tier Anthropic (no client content) is described in a separate note below.

Client-work retention only.

ME-TA internal-only consumer-tier Anthropic

Separate from anything on the diagram above: ME-TA uses consumer-tier Anthropic (e.g. Claude Max) for internal work only — platform development, internal documentation, learning. No client content ever travels this path, per P22 §22.3.4. Conversations on this path live on Anthropic infrastructure in the United States under Anthropic's Consumer Terms (indefinite until operator-deleted, +30 day backend grace, T&S exception up to 2 years for inputs/outputs and 7 years for classification scores). Anthropic on this path is not a sub-processor of ME-TA — it is ME-TA's own tool vendor for internal-only purposes, with no controller-processor relationship arising.

4. How each boundary is enforced

Sections 1–3 above answer the procurement / DPO questions: where data goes, who sees it, how long it's kept. This section is for the IT-security review: nine specific boundaries the architecture is designed to maintain, the layered controls behind each, and what specifically enforces them. Read it if you are mapping our controls to a security framework (ISO 27001 Annex A, SOC 2 CC, NIST SP 800-53) or running a vendor risk assessment. Controls are stated at design level: the named mechanism per boundary; the as-deployed evidence set for a specific engagement is produced at engagement time. The deployed configuration can also be read by an assessor through a read-only cross-account role (RS 1-5.2.4 AUD-01) without ME-TA's involvement.

Sections 1–3 above answer the procurement / DPO questions: where data goes, who sees it, how long it's kept. This section is for the IT-security review: five specific boundaries the architecture is designed to maintain in the base service, the layered controls behind each, and what specifically enforces them. Read it if you are mapping our controls to a security framework (ISO 27001 Annex A, SOC 2 CC, NIST SP 800-53) or running a vendor risk assessment. Controls are stated at design level: the named mechanism per boundary; the as-deployed evidence set for a specific engagement is produced at engagement time. The deployed configuration can also be read by an assessor through a read-only cross-account role (RS 1-5.2.4 AUD-01) without ME-TA's involvement.

Defence in depth — controls layered per security boundary
Defence in depth — layered controls per security boundary Threat / boundary what we prevent · what enforces it Identity & access (IAM, SSO/OTP) Network VPC · egress · TLS Content / app structural · filters Procedural QMS policy · ME-TA Audit detection · logging 1. Cross-sponsor data isolation No sponsor sees another sponsor's data, ever Customer-scoped IAM + Cognito session S3 customer-prefix per-engagement scope Portal scope server-side enforced P07 §7.10 admin-grant model All access events logged · Aurora 2. No browsing without authorisation ME-TA personnel cannot read customer content Customer-admin grant required for access covered elsewhere Portal access control scoped to grants P07 §7.10 · P21 §21.8 explicit grant model Access events with operator identity 3. Cat-B stays out of AI (standard config) Patient-level data denied · P22 §22.4.3 carve-out on Tier 1 only AI stage architecturally excluded from patient storage Egress restricted to approved inference endpoint Human curation gate — curated Cat A content only P22 §22.4 · §22.5 three-stage architecture Promotion events · server-side AI invocations logged (H-12) 4. AI provider non-retention / non-training Bedrock stateless · no training on prompts No third-party AI tool in path (F161) · Bedrock IAM ME-TA software reaches only approved targets (INF-01, L-29) EU inference profile pinned in code · no history (INF-05) AWS Service Terms §1.14 (DPA auto-incorporated) Server-side invocations in audit trail (H-12-API) 5. Data stays in EEA No GDPR Chapter V transfer for client work Every stack pinned to eu-west-1 (RES-01-CLOUD) EU-only Bedrock inference profile · self-hosted in DK No replication outside EEA buckets Sub-processor register + RES-03: certs only outside EU Multi-region CloudTrail (LOG-01-CLOUD) 6. No exfiltration via personal AI Operator cannot route client work to consumer Anthropic Corporate accounts only · no personal AI for client work Client inference credentials provisioned per PC (L-30) Consumer-tier AI: no client content (P22 §22.3.4) P22 §22.3.3 + §22.3.4 training (§22.10) Incident reporting (§22.9) + yearly review (P03) 7. Lost laptop is not a breach Device loss does not become a data breach Passwordless sign-in · short-lived tokens (P07) covered elsewhere BitLocker full-disk encryption (XTS-AES 256) P07 §7.6 + §7.7 (BitLocker, Defender for Business) Intune device inventory + P07 §7.8 compromise report 8. Prompt-injection mitigation (AI-specific) Adversarial SCE output cannot subvert AI behaviour AI scope = Cat A only limited blast radius Egress: approved inference endpoint only Human review · AI result never changes a record (P22 §22.6) Per-engagement review gates CEO escalation (P22 §22.4) Server-side AI invocations logged · per-DPA retention 9. Audit log tamper-evidence Privileged admin cannot rewrite history Audit records append-only (RET-03-API, H-19-API) Dedicated CloudTrail bucket CMK-encrypted · retained CloudTrail log-file validation (LOG-01-CLOUD) Retention per DPA / AI addendum (as agreed) covered elsewhere Each row names a security boundary the architecture is designed to maintain. Columns are defence layers. Cells name the specific mechanism. “—” means the layer is not load-bearing for that threat — other layers cover it. Defence in depth — layered controls per security boundary Threat / boundary what we prevent · what enforces it Identity & access (IAM, SSO/OTP) Network VPC · egress · TLS Content / app structural · filters Procedural QMS policy · ME-TA Audit detection · logging 1. Cross-sponsor data isolation No sponsor sees another sponsor's data, ever Customer-scoped IAM + Cognito session S3 customer-prefix per-engagement scope Portal scope server-side enforced P07 §7.10 admin-grant model All access events logged · Aurora 2. No browsing without authorisation ME-TA personnel cannot read customer content Customer-admin grant required for access covered elsewhere Portal access control scoped to grants P07 §7.10 · P21 §21.8 explicit grant model Access events with operator identity 3. Data stays in EEA No GDPR Chapter V transfer for client work Every stack pinned to eu-west-1 (RES-01-CLOUD) Region-pinned service endpoints · eu-west-1 No replication outside EEA buckets Sub-processor register + RES-03: certs only outside EU Multi-region CloudTrail (LOG-01-CLOUD) 4. Lost laptop is not a breach Device loss does not become a data breach Passwordless sign-in · short-lived tokens (P07) covered elsewhere BitLocker full-disk encryption (XTS-AES 256) P07 §7.6 + §7.7 (BitLocker, Defender for Business) Intune device inventory + P07 §7.8 compromise report 5. Audit log tamper-evidence Privileged admin cannot rewrite history Audit records append-only (RET-03-API, H-19-API) Dedicated CloudTrail bucket CMK-encrypted · retained CloudTrail log-file validation (LOG-01-CLOUD) Retention per DPA (as agreed) covered elsewhere Each row names a security boundary the architecture is designed to maintain. Columns are defence layers. Cells name the specific mechanism. “—” means the layer is not load-bearing for that threat — other layers cover it.

Rows 1–7 restate ME-TA's trust-boundary analysis of the platform (each row a boundary, each cell the enforcing mechanism), governed under the QMS policies published at policy.me-ta.dk (chiefly P07 Systems Access, P21 GDPR, and P22 AI Usage). Rows 8–9 (prompt-injection mitigation; audit log tamper-evidence) are AI-specific and audit-integrity additions per the IT-security review. Requirement IDs (H-12, RET-03, INF-01, L-29 and so on) refer to the signed Requirement Specifications of the validation package.

Rows 1–5 restate ME-TA's trust-boundary analysis of the platform (each row a boundary, each cell the enforcing mechanism), restricted to the boundaries present in the base service and governed under the QMS policies published at policy.me-ta.dk (chiefly P07 Systems Access and P21 GDPR). Requirement IDs (H-12, RET-03, RES-01, LOG-01 and so on) refer to the signed Requirement Specifications of the validation package.

Reading the matrix

5. Sub-processors

ME-TA's contractual sub-processor chain for client work.

Sub-processor Role Location Instrument
Amazon Web Services EMEA SARL (Luxembourg) — infrastructure S3 storage, Aurora (metadata, SAS programs and logs, audit trail), Cognito auth, serverless platform functions (SCE compute runs locally on the operator's PC, so AWS is not a sub-processor for that stage) AWS eu-west-1 (Ireland) primary; file content replicated to eu-central-1 (Frankfurt); database backups retained 7 days AWS GDPR DPA (auto-incorporated, Service Terms §1.14.1)
Amazon Web Services EMEA SARL (Luxembourg) — AWS Bedrock AI inference for Category A content, invoked only by ME-TA's platform software (Anthropic Claude models on Bedrock via an EU-only cross-region inference profile; no provider-side retention beyond the request; no training) AWS EU regions — inference stays in the EU AWS GDPR DPA (auto-incorporated, Service Terms §1.14.1)
ME-TA self-hosted inference server (Denmark) — transparency listing AI inference for Category A content on ME-TA's own hardware, reached over authenticated TLS by ME-TA's client software and by platform functions in eu-west-1; ME-TA-operated processing, not a third-party sub-processor; listed for transparency (P21 §21.11) Denmark (ME-TA premises) ME-TA DPA + AI addendum (ME-TA's own processing)
Microsoft Ireland Operations Ltd and other ancillary business sub-processors Workforce email and documents (Microsoft 365), device management and endpoint protection on operator PCs (Intune, Defender for Business: endpoint telemetry only); engagement administration; no clinical data. Engagement-specific contractors, approved by the customer per P17, are listed in the register. EU Microsoft Online Services DPA; supplier DPA or NDA (P05 / P17)

The AI-inference rows are election-dependent. The Bedrock and self-hosted rows above exist only under AI election A. Under sponsor-operated inference (AI election B) or the no-AI base service, the AI-inference rows drop from the engagement's sub-processor chain entirely — the base chain is the infrastructure row plus ancillary business sub-processors.

Why Anthropic is not listed as a sub-processor

Under the AWS Bedrock access pattern, ME-TA's controller's prompts and completions do not flow to Anthropic. AWS hosts the model weights under license from Anthropic and operates the inference service on AWS infrastructure; prompts and completions are not shared with Anthropic. Applying GDPR Art. 4(2) / 4(8) and the EDPB Guidelines 07/2020 factual-nexus test, Anthropic does not factually process ME-TA's controller's data on this path and is therefore not engaged as a processor under Art. 28. The Art. 28 contract is with AWS. Anthropic is the upstream model author — a tool licensor — analogous to Microsoft for Word or the PostgreSQL Global Development Group for AWS RDS for PostgreSQL.

The full rationale, including honest caveats and the procurement walk-through, is available on request as part of the DPA package.

6. Source documents

The contractual and policy instruments behind the architecture above.

AWS GDPR Data Processing Addendum

Auto-incorporated into AWS Service Terms §1.14.1 — covers all AWS-hosted data including Bedrock inference.

Auto-incorporated into AWS Service Terms §1.14.1; covers all AWS-hosted data.

Download PDF →

AWS Service Terms §1.14

The clause that auto-incorporates the AWS GDPR DPA into every AWS customer agreement.

View on aws.amazon.com →

ME-TA QMS — P22 AI Usage

ME-TA's AI policy: AI inference tiers, three-stage architecture, data classification, operator hygiene, AI Act compliance.

View on policy.me-ta.dk →

ME-TA QMS — P21 GDPR

ME-TA's GDPR policy, sub-processor register, encryption framework.

View on policy.me-ta.dk →

ME-TA DPA template

Sponsor-tailored Article 28 DPA. Sent on request — combines the main DPA and the AI-specific addendum, with sponsor entity details substituted.

Sponsor-tailored Article 28 DPA. Sent on request, with sponsor entity details substituted.

Request via email →

ME-TA validation package

Validation Master Plan (1-5.1 v05), Validation Report (1-5.3 v02), 21 CFR Part 11 / EU Annex 11 mapping (1-5.4 v01) and per-release evidence records. Available under NDA or audit rights.

Request via email →

Sub-processor list

Live sub-processor register at policy.me-ta.dk — changes notified before they take effect, with a 30-day objection window, per P21 §21.11.

View on policy.me-ta.dk →

Need a sponsor-tailored DPA?

We provide an Article 28 DPA tailored to each engagement — entity details, Annex C scope, and AI-addendum elections. ME-TA maintains a standard DPA template and aligns it with each sponsor's requirements.

We provide an Article 28 DPA tailored to each engagement: entity details and Annex C scope. ME-TA maintains a standard DPA template and aligns it with each sponsor's requirements.

Email contact@me-ta.dk