HiveGrid-Wireframes/hivegrid-cloud/docs/compliance/gdpr.md

GDPR Data Inventory

Scope

This inventory documents the current data-protection-relevant surfaces in the boilerplate for follow-up work in Compliance Retention. It is a repository evidence map, not legal advice and not an implemented retention schedule. Entries are grounded in the current security and production evidence boundaries from docs/security.md and docs/production-checklist.md, the Compliance Retention baseline inventory report, and Prisma schema surfaces under prisma/schema.

The inventory covers user, tenant, authentication, API, file, entity-row, import/export, notification, billing, audit, email, analytics, worker, and optional plugin-candidate surfaces that can contain personal data or personal-data-adjacent operational evidence. Unknown retention periods are listed as implementation gaps for later Compliance Retention slices rather than invented durations.

Data categories

Category	Current examples	Primary schema evidence	Sensitivity notes
Account identity	User email, first name, last name, phone, avatar, locale, OAuth identifiers, active status, default tenant	User, AdminUser, TenantUser, TenantUserInvitation, Registration in prisma/schema/accounts.prisma	Direct personal data; invitations and registrations may contain people who never complete signup.
Authentication and MFA	Password hash, verification token, encrypted TOTP secrets, MFA recovery code hashes, MFA timestamps, session-adjacent identity relationships	User in prisma/schema/accounts.prisma	Credentials and recovery material are security-sensitive and must not appear in support evidence.
Tenant and organization profile	Tenant slug, name, icon, logo, active/deactivated state, tenant type, tenant membership status	Tenant, TenantType, TenantUser in prisma/schema/accounts.prisma	Tenant names, slugs, and branding can identify customers and must be redacted from shared evidence.
API keys and API access logs	API key alias, key hash/prefix/last-four, expiry, active status, endpoint, method, params, IP, duration, error, tenant/user linkage	ApiKey, ApiKeyLog, TenantIpAddress, Log in prisma/schema/core.prisma and accounts.prisma	API key values, hashes, prefixes, params, and IPs are sensitive; only generic status and request IDs are safe in docs.
Files and media	File names, object keys, content types, checksums, public URLs, upload/download timestamps, row media, email attachments	FileObject, FileUploadProgress, FileChunk, RowMedia, EmailAttachment	Object keys, URLs, filenames, and attachments can expose customer content or identifiers.
Dynamic entity data	Entity row values, comments, tasks, tags, permissions, relationships, formulas, custom fields, tenant settings rows	Row, RowValue, RowComment, RowTask, RowPermission, RowRelationship, FormulaLog, TenantSettingsRow in prisma/schema/entityBuilder.prisma	Entity rows are tenant-defined and can contain arbitrary personal data.
Imports and error reports	Uploaded import source bucket/key, file name, content type, row counts, rejected row counts, error names/messages, error report bucket/key	ImportJob in prisma/schema/imports.prisma	Import files and rejection reports can contain bulk personal data.
Exports	Export jobs and generated files referenced by Compliance Retention baseline tests (packages/db/src/export-jobs.server.test.ts, packages/exports/*)	Export-related package tests and file-object storage surfaces	Export artifacts can aggregate tenant personal data and require explicit expiration/deletion follow-up.
Notifications	In-app/email delivery category, message key, status, provider message ID, payload metadata, sent/read timestamps, user preferences	NotificationDelivery, UserNotificationPreference in prisma/schema/notifications.prisma	Payload metadata and provider message IDs can identify users or message content.
Email and campaigns	Inbound/outbound addresses, names, subjects, text/html bodies, reads, CC recipients, senders, campaigns, opens, clicks, unsubscribe/bounce timestamps	Email, EmailRead, EmailCc, EmailSender, Campaign, OutboundEmail, OutboundEmailOpen, OutboundEmailClick in prisma/schema/email.prisma	Email bodies, addresses, tracking events, and provider configuration are high-risk personal-data surfaces.
Billing and subscriptions	Stripe customer/subscription/session identifiers, checkout email, from URL, usage records, credits, product entitlement state	TenantSubscription, TenantSubscriptionProduct, TenantSubscriptionUsageRecord, CheckoutSessionStatus, Credit in prisma/schema/subscriptions.prisma	Billing records can link identity, payment-provider identifiers, and usage.
Audit, events, metrics, and impersonation	Logs, event payloads, webhook attempts, metric logs, IP geolocation, impersonation actor/target, request path, metadata	Log, Event, EventWebhookAttempt, MetricLog, IpAddress, IpAddressLog, ImpersonationAudit	Audit data is needed for security but can include personal data, URLs, IPs, and payload fragments.
Optional plugin-candidate surfaces	Knowledge base, workflow, app engine, forms, portals, sites, prompt/AI, help desk, analytics, feature-flag, and onboarding surfaces	baseline report plus schema roots such as prisma/schema/appsEngine.prisma; additional schema files under prisma/schema	Treat as potentially personal until each plugin-candidate surface has a dedicated data review.

Processing surfaces

• Web, API, worker, and provider surfaces follow the redaction boundaries documented in docs/security.md; diagnostics may record route class, endpoint label, status, stable error code, request ID, job ID, queue name, and provider category only.
• Account and tenant flows process identity data for registration, invitation, authentication, organization membership, admin access, MFA, and impersonation audit trails.
• API key flows process credentials and access telemetry for tenant-scoped API usage, including endpoint, method, params, status, duration, error, IP, and tenant/user relationships.
• Entity-builder flows process tenant-defined rows, values, comments, tasks, tags, permissions, files, formulas, relationships, and custom schemas. These rows may contain arbitrary personal data because field semantics are tenant-defined.
• File, import, export, and email flows process uploaded documents, generated artifacts, object metadata, message bodies, attachments, campaign tracking events, and provider delivery identifiers.
• Worker, queue, notification, mail, analytics, metrics, app sync, and webhook flows process operational metadata and delivery state. Raw job payloads, provider payloads, webhook bodies, and source/destination sync data are not safe evidence.
• Billing and subscription flows process Stripe-linked customer/subscription/session identifiers, usage records, checkout emails, credits, and entitlement state.

Storage evidence

Surface	Evidence path	Current storage notes
Users and tenants	prisma/schema/accounts.prisma	User, Tenant, TenantUser, TenantUserInvitation, Registration, TenantIpAddress, and ImpersonationAudit store identity, membership, invite, IP, and audit state. Most tenant/user relations cascade on delete, but impersonation audit uses SetNull for actor/target/tenant references.
Security and API telemetry	prisma/schema/core.prisma	ApiKey, ApiKeyLog, Log, Event, EventWebhookAttempt, MetricLog, IpAddress, and IpAddressLog store credential metadata, request traces, event payload strings, webhook attempts, metrics, and IP geodata.
Files and uploads	prisma/schema/core.prisma; entityBuilder.prisma; email.prisma	FileObject, FileUploadProgress, FileChunk, RowMedia, and EmailAttachment store object metadata, binary chunks, public URLs, and attachment content. External object-store deletion behavior needs implementation evidence.
Entity records	prisma/schema/entityBuilder.prisma	Row has deletedAt for soft deletion; many child tables use cascade relations. RowComment has isDeleted, while values, tasks, permissions, formulas, and relationships can retain personal data until deletion paths are enforced.
Imports	prisma/schema/imports.prisma	ImportJob stores source bucket/key, filename, content type, row counts, error messages, and error-report bucket/key. Source and error-report object retention is not defined here.
Notifications	prisma/schema/notifications.prisma	NotificationDelivery uses nullable tenant/user references with SetNull; UserNotificationPreference cascades with tenant/user. Payload metadata and provider IDs require redaction.
Email and campaigns	prisma/schema/email.prisma	Email, campaign, attachment, open/click, read, sender, and outbound records store addresses, names, message bodies, and delivery/tracking state.
Billing	prisma/schema/subscriptions.prisma	Subscription, checkout, usage, and credit records store payment-provider identifiers, checkout email, from URL, usage quantities, and tenant/user references.
App/plugin candidates	prisma/schema/appsEngine.prisma; other schema roots listed by baseline	App config, encrypted connection config, sync runs, logs, items, source/destination data, workflow, knowledge-base, portal, form, site, prompt/AI, help-desk, analytics, and feature-flag schemas need individual classification before extraction or removal work.

Export surfaces

• Package tests in the baseline identify existing export-related code paths in packages/db/src/export-jobs.server.test.ts and packages/exports/src/*. Later Compliance Retention export work should preserve those contracts while adding data-subject scoped inventory coverage.
• Entity rows, row values, row media, comments, tasks, tenant settings rows, email records, imports, notifications, audit logs, billing references, app sync items, and files are potential export inputs when tied to a user, tenant, or data subject request.
• Export artifacts must be treated as sensitive generated files. Evidence may name export job labels, file-object IDs, object-store class labels, status, row counts, request ID, and expiration status; it must not paste exported row data, email content, customer identifiers, object keys, signed URLs, or provider payloads.
• Export scope gaps for later slices: define data-subject selector behavior, tenant-admin export permissions, artifact expiration, object-store deletion, queue retry handling, and safe audit evidence for export completion/failure.

Deletion and erasure surfaces

• Existing schema evidence includes cascade relationships for many tenant/user-owned records, Row.deletedAt for soft-deleted entity rows, RowComment.isDeleted for comment deletion state, and nullable SetNull references on notification delivery and impersonation audit records.
• User erasure must account for direct user records plus created rows, comments, tasks, entity views, notifications, preferences, API keys, tenant memberships, invitations, impersonation audit actor/target links, email reads, analytics sessions, metrics, formulas, workflows, apps, forms, portals, sites, and optional plugin-candidate surfaces.
• Tenant erasure must account for tenant profile, tenant users, invitations, API keys/logs, rows, row permissions, entity views, imports, exports, files, email/campaign data, notifications, billing/subscription records, app sync data, workflow data, portals, forms, sites, and object-store artifacts.
• Operational audit data may need restricted retention rather than immediate deletion when required for security, fraud, accounting, or legal defense. That policy is not implemented in this task and must be explicitly defined later.
• External providers and object stores require deletion hooks beyond database cascades: Mailjet/mail providers, Stripe, Redis/queue payloads, object storage, analytics providers, and deployment/runtime logs.
• Deletion evidence must be redacted to status labels, request IDs, job IDs, model/surface labels, counts, and redacted diagnostic codes. Do not include deleted data samples, emails, tenant names, object keys, signed URLs, API keys, webhook bodies, or raw queue payloads.

Retention status

Repository-level retention defaults now live in docs/data-retention.md. That document is the current default schedule for engineering follow-up work, not legal advice and not evidence that deletion automation already exists.

Surface	Current default schedule	Remaining implementation gap
Account, tenant, invitations, registration	Covered by account lifecycle, tenant lifecycle, and short-lived operational artifact defaults.	Implement account/tenant closure, inactive-account handling, invitation expiry/deletion, and registration cleanup jobs.
API keys and logs	Covered by account lifecycle and operational telemetry defaults.	Implement API telemetry TTL, API key revocation/deletion cleanup, parameter scrubbing, and secure diagnostic aggregation.
Entity rows and comments	Covered by tenant lifecycle defaults with a limited restoration window before hard deletion.	Implement hard-delete jobs, restoration rules, and child-table erasure behavior.
Files, imports, exports	Covered by short-lived operational artifact defaults.	Implement upload/import/export artifact expiration, signed URL limits, and object-store deletion verification.
Email, notifications, webhooks, queues	Covered by operational telemetry and short-lived operational artifact defaults.	Implement provider-side deletion, retry/dead-letter cleanup, payload redaction, and redacted evidence.
Billing and subscriptions	Covered by provider/accounting exception defaults.	Define approved accounting retention separately and ensure erasure workflows preserve only required minimal references.
Audit, impersonation, metrics, IP geolocation	Covered by security/audit evidence and operational telemetry defaults.	Implement security-retention basis, minimization, aggregation, IP truncation or deletion, and access controls.
Plugin-candidate surfaces	Covered by plugin-candidate review defaults.	Classify each candidate before migration, deletion, export, or pause/resume implementation.

Operational redaction rules

• Follow docs/security.md and docs/production-checklist.md: automatic evidence is local/static unless a human explicitly approves a runtime check; browser, provider-console, Docker, registry, Coolify, production traffic, Playwright, and Cypress activities remain manual records.
• Safe evidence includes model or surface labels, route or endpoint labels, status, stable error code, request ID, job ID, queue name, counts, command name, exit code, redacted diagnostic code, and pass/fail labels.
• Unsafe evidence includes secrets, bearer tokens, cookies, API keys, key hashes/prefixes/last-four, raw authorization headers, tenant identifiers, customer domains, customer names, email addresses, phone numbers, IP addresses, object keys, signed URLs, webhook signatures, provider payloads, queue payloads, raw logs, screenshots with personal data, import/export contents, and email/message bodies.
• Examples in compliance docs must stay placeholder-shaped and must not include realistic personal data, tenant slugs, domains, UUID-like deploy endpoints, provider IDs, or secret-shaped strings.
• If sensitive evidence is accidentally captured, remove it from shared records, rotate credentials where applicable, and record only containment status, affected surface label, and redacted remediation facts.

Downstream follow-ups

• Implement focused verification that rejects missing data-protection inventory sections and placeholder markers while staying non-E2E.
• Define data-subject export scope across users, tenants, entity rows, files, imports, exports, email, notifications, audit data, billing references, and plugin-candidate surfaces.
• Define erasure workflows for user and tenant deletion, including soft delete, hard delete, object-store cleanup, provider deletion, queue cleanup, and audit-minimization exceptions.
• Define retention policy defaults for accounts, invitations, registrations, API logs, entity rows, imports, exports, files, emails, notifications, webhooks, queues, metrics, IP geodata, billing records, and audit trails.
• Add operational runbooks for redacted data-protection request evidence, approval boundaries, failure handling, retry behavior, and escalation when provider-side deletion is blocked.
• Classify optional plugin-candidate surfaces before extracting, pausing, exporting, or deleting them, especially knowledge base, workflows, app engine, forms, portals, sites, prompt/AI, help desk, analytics, and onboarding data.