Art. 28 Processor Checklist
Use this checklist to record each recipient of personal data in your deployment and its role under the GDPR. Hephaestus does not establish any of these relationships for you. Fill in the recipient record below for each recipient before you enable it.
Recipients to assess
| Component | What it receives | Role to assess |
|---|---|---|
| Your container host, PostgreSQL and the application roles | All application data | Own infrastructure needs no agreement. An externally operated host or database needs an Art. 28 assessment. |
| Server, review sandboxes and conversation sandboxes | AI work, temporary context and mounted evidence | Own infrastructure needs no agreement. Record each external server operator, location, access and deletion acknowledgement. |
| Reverse proxy or Gateway, ACME endpoint, DNS provider | TLS traffic and domain-validation data | A DNS-only record carries no request data. A proxied record or CDN makes its provider a recipient of request data. |
| GitHub, a GitLab instance | Sign-in identities and the source system's data | Assess whether the provider processes on your instructions or is a separate controller of its own service. |
| Model providers configured for a workspace | Prompts and responses for practice review and Hephaestus, where the AI choice allows them | An external provider processes on your instructions and needs an agreement. An in-house model on your infrastructure does not. |
| Instance-level model provider for product feedback | Code-redacted report text and public issue titles to draft an issue. Redaction can miss personal data | An external provider acts as a processor for drafts and needs an Art. 28 agreement. Check its location, retention, training terms, and subprocessors separately. |
| GitHub product feedback destinations, public and private | Rendered issues. Private issues have a report number. Public issues can have an opted-in GitHub mention | Name GitHub as a recipient. Assess processor and independent-controller purposes under the actual agreement. Public readers can keep copies. |
| Slack | App delivery, identity linking, Hephaestus messages and monitored-channel events | Assess when a workspace enables it. |
| An Outline instance | Selected documents and optional sign-in linking | Classify the exact origin: your infrastructure, a processor, or a separate controller. |
| SMTP relay | Recipient addresses, notification type and links | Record the relay operator, hosting, retention terms and role before you enable email. |
| Log store, trace collector | Container logs and traces | See Optional log collection and monitoring. |
Product feedback stays on the instance until the operator names a repository. Configured filing sends report text through the instance model provider and to GitHub after code redaction. Private filing also needs this recipient assessment. Complete the product feedback legal steps before activation. The webapp and the server include no error-reporting service.
Product feedback stores
The personal-data map owns export, erasure, and retention for these stores. Include their data flows in the recipient record before you enable a destination.
| Store | Data relevant to recipient assessment |
|---|---|
product_feedback_filing | Draft text can reach the instance model provider. Rendered issue text reaches the named GitHub repository. |
product_feedback_consent | Account choices, withdrawals, notice versions, and times stay in the instance as publication evidence. |
product_feedback_cleanup | Minimal locators and reconciliation facts support external cleanup after source deletion. No report text or account identity remains here. |
product_feedback_destination | Instance-wide repositories, installations, model, limit, and pause state determine the recipients. |
Evidence required before engagement
The repository cannot prove that a DPA is executed, that a certification is current or that production uses the stated endpoint. Before activation or renewal, the controller must fill this recipient record:
| Field | Required deployment evidence |
|---|---|
| Recipient and role | [legal entity, service, endpoint, controller/processor/joint-controller analysis]. Distinguish source-platform purposes from processing on instructions. |
| Contract | [signed DPA reference, instructions, subprocessors, renewal/review owner]. An API key is not an agreement. |
| Scope | [data categories, subjects, purposes, review/Hephaestus inputs and any human provider access]. Include broader Slack-thread and person-history context. |
| Retention and training | [prompt/response and abuse-monitoring retention, deletion path, training terms, any exception]. No-training is not zero retention. |
| Location and transfer | [storage, inference, support access, subprocessors, transfer mechanism and evidence date]. Verify deployment type, not just a resource's region. |
| Rights and exit | [export/erasure assistance, incident notice, credential revocation, deletion confirmation]. State what a completed request cannot retract. |
Art. 28 requires a processor agreement only where the recipient actually processes on the controller's instructions. Software selection or an admin role cannot establish that relationship. External workspace institutions may be joint controllers under an actual arrangement. Individual authorized admins within one controller are not separate controllers merely because they choose settings. Assess your own roles rather than copy another operator's arrangement.
For transfers, verify the appropriate basis for the exact recipient and covered service:
- Verify an active adequacy decision and certification.
- Alternatively, verify the appropriate SCC module and transfer assessment with supplementary measures where required. Module 2 is controller-to-processor. It is not automatically the right module for separate controllers or a processor chain. EU hosting and DPF participation do not by themselves prove every support or subprocessor flow stays in the EEA. Keep evidence and a review date.
Optional log collection and monitoring
Record [log store operator, endpoint, hosting, retention, access, contract and transfer safeguard]
before you collect container logs. Controller-owned self-hosting and an external service have different
roles. Collected lines carry stacks, workspace and job identifiers and trace IDs. Library exception
text can still carry personal data.
- Inspect synthetic lines from each runtime role before activation.
- Restrict read access to the operators who need it.
- Set the store's retention to the recorded period.
A release before 1.0 could send error reports to Sentry. That recipient keeps what it received under its own retention. Removing the integration does not delete those reports.
Optional trace export also needs an approved collector and retention. It can contain workspace and run identifiers. Private metrics must not be exposed through the public application route.
Research benchmark runs
Building and running benchmarks for research can mean running AI models on research data. The research organization is the controller of this research. A provider that runs these models for it is a processor.
Apply these rules to every benchmark run:
- Complete the recipient record above for each provider before its first run. Do not assume that the agreement, region or training terms of practice review apply.
- Send only pseudonymized data. Pseudonymized data is still personal data (EDPB Guidelines 01/2025).
- Send data only for participants with a current research grant.
- Honor the participant's AI choice (No AI, In-house or Cloud) in the run.
Recipients of anonymized datasets are not processors. Anonymous data is outside the GDPR (Recital 26). A release of a dataset that is not anonymized needs a separate choice and a new notice version.
Follow-up if the processing surface changes
Amend this record, your Art. 30 record, and the privacy statement before deploying any of the following:
- A new model provider.
- A product feedback destination or drafting provider is enabled or changed. Complete its legal notice and recipient assessment first.
- A new identity provider.
- Enabling Outline for a new origin or changing its operator, hosting region, or contractual role.
- SMTP email delivery becomes active. The chosen SMTP host becomes a recipient of personal data. An external relay needs an Art. 28 DPA.
- Collecting container logs into a log store, or adding a recipient to one. Record the exact operator, role, region, retention and transfer path. Amend the notice and reassess the DPIA. An external processor needs an Art. 28 agreement.
- The application adds external storage (S3, CDN) or serves a third-party font, script, image, or embed. This requires a recipient-role assessment, any applicable agreement and a privacy-statement entry.
- Hephaestus gains internet access or the practice-review sandbox network posture expands beyond the governed sandbox gateway of the server. This triggers a new DPIA assessment.
- An existing processor receives a new source privacy class. Its region or provider retention changes. Product evidence gains an operator/research evaluation use. An existing DPA does not by itself authorize a new purpose or data category. Complete the source governance gate.
- Research benchmark runs start without the agreement that "Research benchmark runs" requires.
- Research benchmark runs use data that is not pseudonymized.
Direct browser image requests
Avatar components pass provider image URLs to browser image elements. Hephaestus does not proxy these requests. The image host receives visitor network metadata and the requested URL, including from
people browsing public pages without signing in. Record [hosts, roles, basis, transfer safeguard and retention].
Third-party hosting does not automatically imply Art. 28 status. Assess its actual role.
Primary references
- EDPB Guidelines 07/2020, controller and processor: roles depend on actual purposes and means.
- European Commission transfer safeguards and SCCs: choose the module for the actual roles.
- OpenAI API data controls: distinguish training, abuse monitoring and endpoint-specific application state. Do not infer these terms for a compatible third-party API.
- Microsoft Azure OpenAI data privacy: verify deployment geography and any modified abuse-monitoring approval.
- Loki label best practices and structured metadata: keep per-request and per-person values out of index labels.
- GitLab account deletion: upstream deletion is separate from Hephaestus copies and attribution.
Recheck these terms against the contract and exact service version when a provider changes. Published vendor documentation does not prove that the deployment has purchased or enabled a particular control.