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.
Configuration shown: base service.
Configuration shown: base service with AI-assisted production.
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 PC — work/ (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 PC — work/ (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 is not part of the base service. AI-assisted production exists only as a per-engagement election, governed by a dedicated AI addendum to the DPA — ME-TA-operated on AWS Bedrock EU inference, ME-TA-operated 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. In every case: curated operational content only; patient-level data excluded; files stay local, only prompt and completion text travels; Anthropic is the upstream model author, not engaged as a separate sub-processor on the Bedrock path. See "Deterministic by default — AI only by election" below.
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.
Cognito user pool with passwordless sign-in — SSO federation to the sponsor's identity provider (Entra ID, Okta, or equivalent) or email one-time codes — and short-lived session tokens.
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.
Amazon VPC with private subnets for the data plane; encryption at rest throughout (S3 AES-256, Aurora KMS). 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 AES-256, Aurora KMS). Region: eu-west-1 (storage).
Each sponsor's files are held under a sponsor-scoped storage path, with per-session credentials scoped to that path. 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.
22 effective policies (P01–P22), including AI-usage governance (P22-AI Usage, effective 02 JUL 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.
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 to meet that sponsor's specific requirements, under counsel review.
Both views of this page rest on the same foundation: a validated, audit-ready statistical computing environment operated by ME-TA statisticians.
The Statistical Computing Environment runs validated, deterministic SAS. Programs, outputs, and logs carry full versioning in customer-scoped S3, with audit-trail metadata on every artifact.
Designed for 21 CFR Part 11 and EU Annex 11 alignment: attributable, contemporaneous, original, accurate records with a reconstructable history.
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.
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.
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 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 drafting on AWS Bedrock EU inference — or, agreed per engagement, on ME-TA's self-hosted inference server on ME-TA's own hardware in Denmark — Category A content only, under the AWS GDPR DPA (Bedrock path) and ME-TA's operator-endpoint hardening. This is the AI architecture described in the AI sections of this page.
AI drafting on AWS Bedrock EU inference — or, agreed per engagement, on ME-TA's self-hosted inference server on ME-TA's own hardware in Denmark — Category A content only, under the AWS GDPR DPA (Bedrock path) and ME-TA's operator-endpoint hardening. 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.
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, the AI-assisted workflow loop, and the operator-endpoint hardening profile — sits in the purple ▸ panels below.
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.
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.
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. Structurally excluded from the AI leg in our standard configuration.
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.
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.
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).
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.
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.
The ME-TA data processor reviews the outputs in the WORK stage. Approved deliverables are returned to the sponsor through metawebservice.com.
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.
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.
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.
The AI stage drafts SAS programs from the promoted Category A specifications, on the agreed EU inference target (AWS Bedrock EU or ME-TA's self-hosted server in Denmark). Files stay local to the operator endpoint; only prompts and completions traverse the network, within the EU throughout.
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.
Log files and redacted outputs flow back to the AI stage as context for the next iteration.
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.
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.
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. 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.
meta-cli sync with S3 for sponsor exchange.meta-cli sync with S3 for sponsor exchange.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:
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.
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.
* 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.
What is kept, where it is kept, how long, and under which contractual instrument.
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.
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.
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 (same principle as the dated-snapshot note under the hardening profile below).
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.
Rows 1–7 are derived from context/operations/data-flow.md §7 (trust boundaries + enforcement). Rows 8–9 (prompt-injection mitigation; audit log tamper-evidence) are AI-specific and audit-integrity additions per the IT-security review.
Rows 1–5 are derived from context/operations/data-flow.md §7 (trust boundaries + enforcement), restricted to the boundaries present in the base service.
CLAUDE_CODE_USE_BEDROCK=1, SKIP_PROMPT_HISTORY=1, WebFetch · survey · feedback disables). These come from the operator-endpoint hardening profile below — every named control is delivered via managed endpoint policy and verifiable on any operator PC.The matrix above names controls in shorthand. The managed-settings baseline below is how ME-TA delivers those controls on operator PCs — through endpoint policy at the Windows registry under HKLM\SOFTWARE\Policies\ClaudeCode\Settings, macOS com.anthropic.claudecode managed preferences, or /etc/claude-code/managed-settings.json on Linux/WSL — at managed scope, which has higher precedence than user or project settings and cannot be overridden locally.
/status and via the managed-settings store. Procurement reviewers who want the current profile (vs. the dated snapshot) should request it at engagement time.
CLAUDE_CODE_USE_BEDROCK=1 forces Bedrock-only routing at the application layer; ANTHROPIC_DEFAULT_SONNET_MODEL pinned to a version-specific ID prevents silent model changes (supports validated state under GxP); absence of CLAUDE_CODE_USE_MANTLE keeps invocations captured by Bedrock model-invocation logging (Mantle is not captured); AWS Service Terms §1.14 carries the contractual non-training claim that the technical posture demonstrates is real.AWS_REGION pinned to an approved EU region delivered via managed policy (not read from .aws/config); model IDs are version-specific and EU-constrained — in-region IDs or EU-scoped inference profiles, as agreed per engagement; global profiles, which can route worldwide, are excluded. IAM/SCPs enforce the same region constraint at the AWS account level.CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 (session-quality surveys), CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1 (post-session prompt), DISABLE_FEEDBACK_COMMAND=1 (the /feedback command). skipWebFetchPreflight: true closes the domain-safety preflight call to api.anthropic.com. WebFetch in permissions.deny closes the tool itself (preflight-only-disable is not enough on its own). Network-layer FQDN blocks at proxy/firewall can provide a redundant outer ring, where agreed.CLAUDE_CODE_SKIP_PROMPT_HISTORY=1 disables the default plaintext transcript store at ~/.claude/projects/ entirely. Combined with BitLocker AES-256 full-disk encryption, no prompt content persists on disk in recoverable form.disableAllHooks: true, allowedMcpServers: [], and strictKnownMarketplaces: [] remove the agentic tool surfaces that an adversarial prompt could attempt to invoke. The shell-network entries in permissions.deny (curl, wget, Invoke-WebRequest, Invoke-RestMethod) close the obvious exfiltration paths a prompt could ask the AI to run..env, secrets/, .pem, .key, and SSH key paths prevent the AI from reading credentials or sensitive paths even within an approved engagement — defence-in-depth on top of the Cat-A promotion gate.The two placeholders (<approved-eu-region>, <approved-version-specific-bedrock-id>) are deployment-specific and held in ME-TA's deployment register. The profile is reviewed at each Claude Code release and on the P22 §22 annual cycle. Evidence of the profile being in effect on any operator endpoint can be produced on request — Claude Code's /status command shows the active provider, region, model IDs, and disabled features.
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, Cognito auth (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; encrypted backups in a second EU region | AWS GDPR DPA (auto-incorporated, Service Terms §1.14.1) |
| Amazon Web Services EMEA SARL (Luxembourg) — AWS Bedrock | AI inference for Category A content (Anthropic Claude models on AWS Bedrock EU inference; no provider-side retention; 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 | Alternative AI inference for Category A content, on ME-TA's own hardware — ME-TA-operated processing, not a third-party sub-processor; listed for transparency | Denmark (ME-TA premises) | ME-TA DPA + AI addendum (ME-TA's own processing) |
| Ancillary business sub-processors | Engagement administration only (email, document exchange, scheduling) — no clinical data | Per supplier disclosure | Supplier DPA (under ME-TA 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.
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.
The contractual and policy instruments behind the architecture above.
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 →The clause that auto-incorporates the AWS GDPR DPA into every AWS customer agreement.
View on aws.amazon.com →ME-TA's AI policy: approved tools, three-stage architecture, data classification, operator hygiene, AI Act compliance.
View on policy.me-ta.dk →ME-TA's GDPR policy, sub-processor register, encryption framework.
View on policy.me-ta.dk →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 →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 →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