GDPR Customer Guide

This guide explains how Arctickey fits into a customer's GDPR responsibilities. It is operational guidance, not legal advice.

Roles#

For most customer workloads:

The customer is the controller for personal data they choose to store in Arctickey.
Arctickey acts as a processor for customer instance data.
Arctickey is the controller for account, billing, and service communication data.

What Arctickey Provides#

EU-hosted customer Valkey instance data.
TLS-required client connections.
Plan-based backup retention.
Instance deletion controls.
DPA available on request.
Subprocessor list maintained in the docs.

What Customers Should Decide#

Before storing personal data in a Valkey instance, decide:

What categories of personal data will be stored.
Why the data is needed and what legal basis applies.
How long each key should live.
Whether keys need TTLs by default.
How user deletion requests will be mapped to application keys.
Whether exported data contains personal data.

Arctickey does not inspect customer key/value payloads. Customers should maintain a controller-side data map before storing personal data in Valkey. The dashboard compliance page and EU Evidence Pack include starter templates for common Valkey workloads.

Workload	Example keys	Possible personal data	Suggested TTL posture	Erasure mapping
Sessions	session:{opaque_session_id}, user:{opaque_user_id}:sessions	User identifiers, session state, authorization context, device metadata, login timestamps	Hours to days	Maintain a user-to-session index so sessions can be revoked.
Application caches	cache:profile:{opaque_user_id}, cache:org:{opaque_org_id}	Derived profile data, preferences, authorization results, computed views	Minutes to hours for user-level data	Use deterministic prefixes or indexes so user-level cache entries can be purged.
Queues and background jobs	bull:{queue}:, sidekiq:queue:, celery-task-meta-*	Job payloads, user identifiers, email addresses, order references	Short retry and completion retention	Store minimal payloads and reference source-system records.
Rate limits and abuse prevention	rate:{hashed_ip}, rate:user:{opaque_user_id}	IP-derived identifiers, account identifiers, request counters	Seconds to days	Use hashed or opaque identifiers and short TTLs.
Feature flags and experiments	flag:{feature}:{opaque_user_id}, experiment:{opaque_user_id}	Feature assignments, cohorts, account identifiers	Duration of the rollout or experiment	Delete user-specific assignments when the source account is erased.
Locks and idempotency keys	lock:order:{opaque_order_id}, idem:{request_id}	Order references, request identifiers, derived account identifiers	Seconds to hours	Avoid personal data in lock keys and use short TTLs.

Recommended Patterns#

Use TTLs for short-lived data:

Terminal

SET session:user_123 "{...}" EX 86400

Keep personal data out of cache keys where possible:

Terminal

# Prefer opaque identifiers
GET user_profile:8f2d2a1c

# Avoid emails, names, or national identifiers in keys
GET user_profile:anna@example.com

Separate application domains:

Sessions: short TTL, easy revocation.
Caches: rebuildable from your source of truth.
Queues: payloads should contain the minimum data needed to process the job.
Rate limits: store counters, not raw request bodies.

Lawful Basis and Minimization#

Arctickey does not decide the lawful basis for customer-controlled Valkey data. Customers should document the lawful basis, minimization decision, TTL, and deletion owner for every workload that can contain personal data.

Workload	Common purpose	Lawful-basis prompt	Minimization check
Sessions and authentication state	Authenticate users, maintain secure sessions, and revoke access.	Contract necessity for account access, with legitimate interest for security controls where applicable.	Store opaque session IDs and minimal authorization state; avoid raw names, emails, or unnecessary profile data.
Application caches	Improve performance by temporarily storing derived or source-system-backed data.	Mirror the legal basis of the source system record and document why cache copies are necessary.	Cache only fields needed for the immediate application path and use short TTLs.
Queues and background jobs	Process asynchronous work such as emails, imports, exports, notifications, or order operations.	Document whether each job is needed for contract delivery, legal obligation, consent, or legitimate interest.	Prefer source-record references over full payload copies; expire completed jobs.
Rate limits and abuse prevention	Protect accounts, infrastructure, and users from abuse or service disruption.	Usually legitimate interest or security necessity; assess balancing tests under your policy.	Use hashed IPs, opaque account IDs, counters, and short-lived risk signals.
Feature flags and experiments	Control rollout eligibility, product behavior, beta access, and experiment assignment.	Separate service-delivery flags from analytics or experimentation that may require consent or notice.	Use opaque IDs and remove assignments when the rollout or experiment ends.
Locks and idempotency keys	Prevent duplicate actions, coordinate writes, and protect workflow consistency.	Tie the basis to the underlying transaction or operational integrity requirement.	Keep personal data out of lock names and set automatic expiry.

This matrix is also included in the EU Evidence Pack as lawfulBasis.

DPIA Risk Register#

Use this starter register when deciding whether a full DPIA is required for Valkey-backed workloads. Customers must assess likelihood, severity, residual risk, and approval requirements for their own processing.

Risk area	Scenario	Customer mitigation
Data minimization	Personal data is embedded directly in Valkey keys.	Use opaque IDs, hashed identifiers where appropriate, and deterministic prefixes that do not expose names, emails, national IDs, or secrets.
Retention	User-level cache entries or queue metadata live longer than the source system record.	Set TTLs, expire completed jobs, maintain user-to-key indexes, and test erasure verification.
Support and operations	Secrets or personal data are pasted into support tickets or incident messages.	Redact examples, use synthetic data, share metadata and timestamps first, and document exceptions.
Access control	Valkey credentials or API keys are shared broadly across people, environments, or services.	Use a secrets manager, separate production and non-production instances, rotate after changes, and restrict egress IPs where possible.
Background processing	Background job payloads contain full personal data, notification content, or sensitive transaction context.	Store source-record references instead of full payloads and define failed-job cleanup windows.
Availability and resilience	A critical workflow depends on Valkey availability without fallback behavior.	Define graceful degradation, retry budgets, queue backpressure, alert ownership, and recovery expectations.

This register is exported in the EU Evidence Pack as dpiaRiskRegister.

Data Classification#

Classify Valkey workloads before production. Classification helps decide which workloads can use standard controls, which require DPIA and named approval, and which data types should be kept out of Arctickey by default.

Tier	Examples	Default position	Required controls	Customer action
Low-risk operational data	Synthetic identifiers, feature toggles, non-personal configuration, aggregate counters, and short-lived infrastructure state.	Generally suitable for standard EU-hosted Valkey use.	Use TLS, avoid secrets in keys, set TTLs where data is transient, and keep production and non-production instances separate.	Confirm the data is not personal data or document why personal-data risk is low.
Standard personal data	Opaque user IDs, session state, cached profile attributes, order references, account IDs, and operational metadata.	Suitable only after controller-side lawful-basis, minimization, retention, and erasure mapping is complete.	Use opaque identifiers, short TTLs, user-to-key indexes, erasure verification, and documented legal basis.	Record key patterns, data categories, subject categories, legal basis, TTL, deletion owner, and Evidence Pack export date.
Sensitive or high-risk personal data	Health data, biometric data, child data, employee disciplinary data, financial vulnerability signals, or large-scale profiling signals.	Requires explicit DPIA review, risk acceptance, and extra application-side controls before production use.	Perform DPIA, limit fields, encrypt or tokenize upstream where appropriate, use shortest practical TTLs, and require named approval.	Document residual risk, approving owner, consultation decision, incident impact, and why Valkey is necessary.
Prohibited by default	Plain-text passwords, private keys, payment card numbers, national identifiers in keys, raw access tokens, unredacted secrets, or full support payload dumps.	Do not store in Arctickey by default; redesign the workload or complete a separate exception process.	Use secret managers, payment processors, token references, redaction, hashing, upstream encryption, and source-system references instead.	Remove the data before production or retain a documented exception with legal, security, and DPO review.

Review prompts to retain with the classification record:

Prompt	Expected evidence
Do keys, values, queue payloads, or logs contain direct identifiers?	Example key patterns, payload schema, redaction notes, and classification tier.
Does the TTL match the data category and source-system retention policy?	Configured TTL, no-TTL exception list, backup retention acceptance, and deletion owner.
Can a data subject be mapped to all relevant Valkey keys without payload inspection?	User-to-key index, deterministic prefixes, queue cleanup method, and erasure verification steps.
Does the workload need DPIA, security, legal, DPO, or procurement approval before launch?	Approver, risk decision, residual risk, mitigation plan, and Evidence Pack export.

This classification guide is exported in the EU Evidence Pack as dataClassification.

Use this mapping to connect Arctickey evidence to customer-side GDPR control work. It is operational guidance, not legal advice or a certification claim.

GDPR area	Arctickey evidence	Evidence Pack section	Customer responsibility
Article 5 - principles, minimization, storage limitation	Data map templates, lawful-basis prompts, retention map, erasure playbook, and guidance against personal data in keys.	`customerDataMap`, `lawfulBasis`, `retention`, `erasurePlaybook`, `dpiaRiskRegister`	Define personal data categories, key patterns, TTLs, erasure owners, and minimization decisions.
Article 6 - lawful basis	Workload-level lawful-basis prompts for common Valkey workloads.	`lawfulBasis`, `customerDataMap`	Select, document, and approve the actual legal basis.
Articles 12-23 - data subject rights	Account-level privacy request workflow, user-level erasure playbook, and request records.	`privacyRequests`, `erasurePlaybook`, `readiness`	Map data subjects to application identifiers and export or delete customer-controlled Valkey data.
Article 28 - processor terms and subprocessors	DPA request workflow, public subprocessors, material-change notices, Trust Center entries, and vendor inventory prompts.	`subprocessors`, `vendorInventory`, `vendorReview`, `trustChanges`	Request and review the DPA, approve subprocessors, and record vendor acceptance.
Article 30 - records of processing activities	Vendor inventory record, RoPA prompts, data map templates, retention map, transfer assessment, and evidence links.	`vendorInventory`, `customerDataMap`, `retention`, `transferAssessment`, `references`	Adapt the starter record to the customer's purposes, categories, recipients, retention, and legal bases.
Article 32 - security of processing	TOMs, TLS posture, residency, credential rotation, IP allowlisting guidance, backups, auditability, and status communication.	`securityMeasures`, `instanceResidency`, `controls`, `readiness`	Use TLS, protect secrets, restrict access, separate environments, and document application-side controls.
Articles 33-34 - breach notification	Incident response playbook, status context, Trust Center entries, subprocessors, and audit evidence where available.	`incidentResponse`, `trustChanges`, `subprocessors`, `readiness`	Determine controller notification duties, affected subjects, risk level, communication needs, and timeline evidence.
Article 35 - DPIA	DPIA risk register, data map, lawful-basis matrix, transfer assessment, TOMs, retention map, and vendor review checklist.	`dpiaRiskRegister`, `customerDataMap`, `lawfulBasis`, `transferAssessment`, `securityMeasures`, `vendorReview`	Assess likelihood, severity, residual risk, consultation needs, and approval requirements.
Chapter V - international transfers	EU/EEA residency, transfer assessment prompts, subprocessor region notes, DPA links where available, and material-change notices.	`instanceResidency`, `transferAssessment`, `subprocessors`	Record transfer decisions for billing metadata, support workflows, subprocessors, and any future non-EU processing.

This mapping is exported in the EU Evidence Pack as gdprControls.

DPA Schedule Starter#

Use this starter when preparing a DPA schedule or Article 28 processing annex. It is not a signed agreement and must be reviewed against the customer's actual contract and processing.

Schedule field	Arctickey position	Customer review
Subject matter	Provision of EU-hosted Redis-compatible Valkey infrastructure for customer applications.	Confirm the service description, account owner, production environment, and application systems covered by the DPA.
Duration of processing	For the subscription term and applicable operational retention periods after instance deletion, account closure, or legal/tax retention obligations.	Align contract term, backup retention, account deletion, and internal retention policy before production use.
Nature and purpose	Hosting, transmitting, storing, backing up, restoring, securing, monitoring, and supporting customer-controlled Valkey workloads.	Document the customer application purpose, legal basis, and whether Valkey is used for sessions, caches, queues, rate limits, locks, or experiments.
Categories of personal data	Determined by the customer; common examples include opaque user identifiers, session state, cached profile attributes, job references, rate-limit identifiers, and operational metadata.	Replace starter examples with the actual personal data categories and note any sensitive categories or special handling.
Categories of data subjects	Determined by the customer; common examples include end users, administrators, employees, contractors, customers, or other subjects represented in application data.	List the actual subject categories and any vulnerable or high-risk groups.
Controller instructions	Customer controls data written to Valkey, region, instance lifecycle, key TTLs, deletion actions, credential use, and support disclosures.	Record who can instruct Arctickey, request support, delete instances, rotate credentials, or approve exceptional disclosures.
TOMs	TLS connections, per-instance credentials, password rotation, optional IP allowlisting, dedicated hostnames, backups, auditability, status communication, and trust metadata.	Confirm application TLS use, secrets management, access controls, environment separation, alert ownership, and incident procedures.
Subprocessors	Current subprocessors, region notes, privacy URLs, DPA links where available, status, and material-change notices are published through the Trust Center.	Review subprocessors, active notices, procurement approvals, and internal objection or escalation process.
International transfers	Customer Valkey instance data is EU-hosted for normal service operation. Billing metadata, support workflows, and future subprocessors require separate review.	Record transfer decisions for account metadata, payment provider processing, support tickets, and material-change notices.
Return and deletion	Customers can export application data with Redis-compatible tools and delete instances. Active deletion and backup retention are described in the retention map.	Define export owner, deletion owner, backup retention acceptance, user-level erasure process, and end-of-contract deletion evidence.

This schedule starter is exported in the EU Evidence Pack as dpaSchedule.

Procurement Evidence Index#

Use this index to route the EU Evidence Pack to the right reviewer during procurement, DPIA, vendor-risk, security, launch, incident, and executive approval.

Package	Reviewer	Evidence Pack sections	Customer decision
Legal and DPA review	Legal, DPO, privacy counsel, or contract owner	`dpaSchedule`, `subprocessors`, `customerNotices`, `gdprControls`, `responsibilityMatrix`, `limitations`	Approve or reject the DPA schedule starter and record negotiated differences.
Privacy and DPIA review	DPO, privacy engineer, risk owner, or product privacy owner	`dpiaRiskRegister`, `customerDataMap`, `lawfulBasis`, `transferAssessment`, `retention`, `erasurePlaybook`, `regulatoryApplicability`	Record data categories, likelihood, severity, mitigations, residual risk, consultation decision, and approval owner.
Security and TOMs review	Security, platform engineering, cloud security, or procurement security reviewer	`securityMeasures`, `controls`, `supportAccess`, `operationalResilience`, `incidentResponse`, `securityQuestionnaire`	Record accepted controls, compensating controls, open risks, monitoring expectations, and support redaction rules.
Vendor risk and procurement approval	Procurement, vendor management, compliance owner, or risk committee	`vendorReview`, `vendorInventory`, `accountability`, `trustChanges`, `subprocessors`, `regulatoryBoundary`	Approve the vendor record, retain point-in-time evidence, document findings, and set reassessment cadence.
Engineering launch approval	Product owner, application owner, SRE, platform owner, or release manager	`instanceResidency`, `dataClassification`, `customerDataMap`, `retention`, `operationalResilience`, `readiness`	Confirm region, workload classification, TTL defaults, backup retention fit, restore owner, fallback behavior, and launch approver.
Incident and rights operations	Support operations, incident commander, privacy operations, security operations, or DPO	`privacyRequests`, `erasurePlaybook`, `incidentResponse`, `supportAccess`, `accountability`, `trustChanges`	Define request owner, incident owner, evidence location, notification path, and completion verification method.
Executive and accountability sign-off	Founder, compliance owner, risk owner, security leadership, or product leadership	`summary`, `readiness`, `controls`, `accountability`, `responsibilityMatrix`, `regulatoryBoundary`, `limitations`	Record approval date, unresolved review items, accepted risks, follow-ups, and Evidence Pack version.

This index is exported in the EU Evidence Pack as procurementEvidence.

Accountability Evidence Register#

Use this register to decide which point-in-time Evidence Pack exports should be retained, who owns them, and when they should be refreshed.

Evidence area	Evidence source	Suggested owner	Refresh cadence
EU launch approval	EU Launch Readiness score and readiness item details.	Product or compliance owner	Before production launch and after material architecture changes.
DPA and procurement approval	DPA request status, DPA schedule starter, vendor review checklist, and GDPR control mapping.	Legal, procurement, or vendor management owner	Before contract signature, renewal, or vendor reassessment.
RoPA and vendor inventory	Vendor inventory record, RoPA prompts, data map, lawful-basis matrix, and retention map.	Privacy or data protection owner	Before production use and when purposes, categories, recipients, or retention change.
DPIA review	DPIA risk register, transfer assessment, TOMs, data map, incident response playbook, and lawful-basis matrix.	DPO, privacy engineer, or risk owner	Before high-risk processing and after material risk, feature, or subprocessor changes.
Subprocessor notice review	Current subprocessors, active material-change notices, Trust Center entries, and transfer prompts.	Vendor management or privacy owner	When active notices are published and during periodic vendor review.
Data subject request handling	Privacy request records, user-level erasure playbook, retention map, and customer data map.	Support, privacy operations, or application owner	For each access, erasure, portability, objection, or account-level DPA request.
Incident and breach assessment	Incident response playbook, Trust Center entries, status history, subprocessors, audit evidence, and DPIA register.	Incident commander, security owner, or DPO	For each security event, material operational incident, or postmortem.
Retention and deletion review	Retention map, managed backup retention, erasure playbook, and data map TTL prompts.	Application owner or privacy engineering owner	Before launch and whenever TTLs, backups, or deletion workflows change.

This register is exported in the EU Evidence Pack as accountability.

Customer Notice Checklist#

Use this checklist when updating customer-side privacy notices, DPA annexes, RoPA records, procurement tickets, or internal launch approvals. Arctickey provides current service facts; customers remain responsible for accurate controller-side notices.

Notice area	Recommended disclosure	Evidence source	Customer action
Processor role	State that Arctickey is used as a processor for Redis-compatible Valkey infrastructure where the customer controls the data written to the service.	DPA schedule starter, vendor inventory record, GDPR control mapping, and Trust Center references.	Confirm the controller, processor, and subprocessor roles in the customer's privacy notice, DPA schedule, and vendor inventory.
Processing purpose	Describe whether Arctickey supports sessions, caching, queues, rate limiting, feature flags, locks, idempotency, or other application workflows.	Customer data map templates, lawful-basis matrix, DPA schedule, and RoPA prompts.	Replace starter workload examples with the customer's actual application purposes and legal bases.
Personal data categories	List the personal data categories that may be stored in Valkey, such as opaque user IDs, session state, cached profile attributes, job references, or operational metadata.	Customer data map, DPA schedule, lawful-basis matrix, and DPIA risk register.	Document actual categories and flag any special-category, child, employee, financial, or high-risk data before production use.
Data subject categories	Identify the groups represented in customer-controlled Valkey data, such as end users, admins, employees, contractors, customers, or organization members.	DPA schedule starter, RoPA prompts, and customer data map.	Update customer notices and Article 30 records when a new subject group is introduced.
EU data residency	Explain that Arctickey customer instance data is hosted in EU regions for normal service operation, while account, billing, support, and subprocessor processing should be reviewed separately.	Instance residency, transfer assessment, retention map, subprocessor list, and data residency documentation.	Keep residency language precise and avoid claiming that all customer business data is exclusively EU-only unless the full workflow has been reviewed.
Subprocessors and notices	Point to the current subprocessor list and describe how material subprocessor changes are reviewed under the customer's vendor policy.	Public subprocessors, material-change notices, Trust Center entries, and accountability register.	Record subprocessor approval, objection decisions, and downstream customer communication obligations where required.
Retention and deletion	Describe customer-controlled TTLs, instance deletion, backup retention, and user-level erasure handling for Valkey-backed workloads.	Retention map, erasure playbook, data map TTL prompts, and managed backup retention.	Align public retention language with actual TTLs, backup plan, deletion workflow, and erasure verification evidence.
Data subject rights	Explain how access, erasure, portability, objection, or other rights requests are mapped from the customer's user identifiers to Valkey keys and related systems.	Privacy request workflow, erasure playbook, customer data map, and accountability register.	Define the source-of-truth system, key lookup method, export method, deletion owner, exception handling, and completion evidence.

This checklist is exported in the EU Evidence Pack as customerNotices.

Support Access and Disclosure#

Support workflows should rely on metadata and customer-provided diagnostics rather than customer Valkey payload inspection. Use this register to document customer instructions, redaction rules, emergency access decisions, credential handling, and exceptional disclosures.

Control area	Arctickey position	Customer instruction	Evidence to retain
Support scope	Routine support should use account metadata, instance metadata, audit logs, health checks, status context, and customer-provided diagnostics.	Describe the problem with timestamps, instance IDs, error messages, and synthetic examples before sharing any personal data.	Support ticket, diagnostic summary, affected instance IDs, timestamps, and any approved customer instructions.
Payload minimization	Customer-controlled Valkey key/value payloads are not inspected by the EU Evidence Pack and should not be required for routine troubleshooting.	Redact secrets, emails, names, tokens, and raw personal data from screenshots, logs, examples, and queue payloads.	Redaction note, synthetic reproduction data, and exception rationale if payload-level data was unavoidable.
Customer instructions	Customer instructions for support, deletion, export, credential rotation, or incident handling should be tied to the authenticated account and audit trail.	Record who is authorized to instruct Arctickey, what action is requested, the affected instances, and any deadlines.	Authenticated requester, instruction text, approval record, audit log event, and completion timestamp.
Emergency access	Emergency operational actions should be limited to what is needed to protect availability, security, or data integrity and should be documented after containment.	Define the customer's incident escalation contact, notification expectations, and approval path for high-impact support actions.	Incident ticket, action timeline, operator notes, affected systems, customer notifications, and postmortem references.
Credentials and secrets	Per-instance credentials and API keys should be rotated through product controls rather than pasted into support tickets.	Use a secrets manager, rotate credentials after suspected exposure, and avoid sending credentials through email, chat, tickets, or screenshots.	Credential rotation event, API key change record, affected deployment list, and verification that old credentials no longer work.
Disclosure review	Any exceptional disclosure involving customer data, legal request handling, or third-party support context should be reviewed against customer instructions and applicable process.	Define legal, DPO, security, and procurement contacts for disclosure review and downstream communication decisions.	Disclosure request, review owner, decision rationale, recipient, scope, safeguards, and customer communication record.

This register is exported in the EU Evidence Pack as supportAccess.

Operational Resilience#

Use this register for EU vendor-risk, DPIA, procurement, and launch-readiness records. It helps customers document continuity decisions without treating Arctickey evidence as a certification claim.

Resilience area	Arctickey evidence	Customer decision	Evidence to retain
Backup retention acceptance	Plan-based managed backup retention windows and instance deletion behavior are included in the retention map and Evidence Pack.	Confirm the selected plan's backup retention window matches the customer's deletion, recovery, and regulatory policy.	Selected plan, retention acceptance, data categories covered, backup exceptions, and approval owner.
Restore readiness	Managed backup and restore controls are available from the instance workflow where supported by the selected plan.	Define restore owner, restore priority, data validation method, and application-level recovery steps after Valkey restore.	Restore test date, instance ID, backup point, validation result, issues found, and next test date.
Availability dependency	Instance status, health metadata, platform status, and incident response guidance are available for operational review.	Classify which application workflows degrade, pause, retry, or fail closed when Valkey is unavailable.	Critical workflow list, retry budget, fallback behavior, alert owner, and business impact rating.
Incident communications	Status page, Trust Center entries, incident response playbook, and trust change log provide incident context and customer-facing evidence.	Define who receives Arctickey incident updates and who decides downstream customer, regulator, or data subject communications.	Communication owner, escalation channel, decision timeline, customer notifications, and post-incident follow-up.
Material change review	Trust changes, subprocessor notices, region notes, and customer notice prompts are available for change review.	Decide which Arctickey changes require DPIA update, procurement review, release freeze, customer notice, or internal risk sign-off.	Reviewed change, impact assessment, approver, objection decision, and related DPIA or vendor-review update.
Exit and continuity planning	Customers can export application data with Redis-compatible tools and delete instances through product controls.	Define export format, migration owner, cutover plan, credential rotation, and deletion evidence for end-of-contract or exit scenarios.	Export runbook, migration test result, deletion confirmation, credential rotation record, and residual retention acceptance.

This register is exported in the EU Evidence Pack as operationalResilience.

Regulatory Boundary#

Use this matrix when writing privacy notices, procurement responses, launch approvals, or security questionnaire answers. It keeps current Arctickey EU evidence separate from legal opinions, certifications, and broader regulatory claims.

Area	Current position	Allowed claim	Claim boundary
GDPR support	Arctickey provides EU-hosted customer instance data, DPA request workflow, subprocessors, Trust Center metadata, retention guidance, TOMs, and customer-side GDPR evidence prompts.	Supports customer GDPR readiness work for EU-hosted Valkey workloads.	Does not decide the customer's lawful basis, DPIA outcome, breach notification duty, Article 30 content, or regulator consultation needs.
EU data residency	Customer Valkey instance data is EU-hosted for normal service operation and new instances default to EU East.	Customer instance data is hosted in EU regions for normal service operation.	Do not claim every account, billing, support, legal, or subprocessor workflow is EU-only without separate workflow review.
Security measures	TOMs include TLS, per-instance credentials, password rotation, optional IP allowlisting, backups, auditability, and trust/status communication.	Publishes technical and organizational measures for customer review.	Do not claim SOC 2, ISO 27001, CSA STAR, or other certification unless a current audit report or certificate exists.
NIS2 and DORA	Operational resilience prompts, incident response guidance, status context, and vendor-risk evidence are available for customer assessment.	Provides operational evidence that can support customer NIS2 or DORA vendor-risk review.	Do not claim NIS2 or DORA compliance, essential-entity status, financial-entity outsourcing compliance, or complete ICT risk management coverage.
EU AI Act	Arctickey is infrastructure for Redis-compatible Valkey workloads and does not classify customer AI systems or inspect customer payloads.	Can support customer-side evidence storage or caching decisions for AI-adjacent applications where the customer controls the AI use case.	Do not claim EU AI Act compliance, high-risk AI system conformity, model governance, training-data governance, or AI provider obligations.
Legal opinion and certification	The Evidence Pack is an operational artifact generated from current account and public trust metadata.	Provides evidence for procurement, DPIA, vendor review, launch approval, and accountability records.	Do not treat it as legal advice, certification, audit opinion, regulator approval, or a substitute for customer policy ownership.

This matrix is exported in the EU Evidence Pack as regulatoryBoundary.

Regulatory Applicability Triage#

Use this triage to route EU regulatory questions to the right customer-side owner before production use. It is not a legal conclusion; applicability depends on sector, role, Member State implementation, and actual processing.

Regulation area	When to review	Arctickey evidence	Customer decision
GDPR and ePrivacy	Personal data, session identifiers, tracking identifiers, communications metadata, or user-level state may be stored or referenced through Valkey workloads.	EU residency, DPA schedule starter, GDPR control mapping, data map, lawful-basis prompts, retention map, erasure playbook, subprocessors, and TOMs.	Confirm roles, legal basis, notice language, data subject rights handling, TTLs, and whether ePrivacy rules apply.
NIS2	The customer operates in an essential or important sector or uses Arctickey for services that support critical EU business operations.	Operational resilience, incident response, support access, Trust Center, trust change log, subprocessor notices, and security measures.	Determine entity classification, Member State requirements, incident reporting path, supplier-risk obligations, and management accountability.
DORA	The customer is a financial entity or ICT provider supporting financial services, and Valkey is used for important or critical functions.	Operational resilience, incident response, transfer assessment, subprocessors, exit planning prompts, retention map, and support access.	Classify ICT criticality, contract requirements, exit strategy, incident escalation, testing expectations, and register-of-information entries.
EU AI Act	Customer AI systems use Valkey for retrieval, caching, feature stores, prompts, outputs, user state, audit evidence, or orchestration.	Data classification, customer data map, retention map, support access boundaries, regulatory boundary, TOMs, and accountability prompts.	Classify the AI system and document data governance, logging, human oversight, and model-output handling.
Cyber Resilience Act	The customer ships a product with digital elements or relies on Arctickey for product-security evidence.	Security measures, vulnerability disclosure policy, trust changes, audit logs, credential controls, incident response prompts, and claim boundaries.	Determine product role, vulnerability-handling duties, secure development evidence, and customer communication requirements.
EU Data Act and portability expectations	The customer needs switching, export, interoperability, or exit evidence.	Exit prompts, export guidance, instance deletion behavior, retention map, backups, and operational resilience evidence.	Define export format, migration owner, switching plan, deletion evidence, contract requirements, and downstream communication.
Sector-specific EU and Member State rules	The customer processes health, payment, telecom, public-sector, employment, education, children, biometric, or other regulated data.	Data classification, DPIA risk register, lawful-basis matrix, support access, transfer assessment, retention map, and responsibility matrix.	Identify local-sector requirements, prohibited data, approval gates, audit evidence, confidentiality duties, and authority expectations.

This triage is exported in the EU Evidence Pack as regulatoryApplicability.

Security Questionnaire Starter#

Use these starter answers for EU procurement, vendor security, DPIA, and controller due-diligence requests. Copy answers together with their Evidence Pack section and claim boundary.

Question	Suggested answer	Evidence Pack section	Claim boundary
Where is customer instance data hosted?	Customer Valkey instance data is hosted in EU regions for normal service operation. New customer instances default to EU East.	`instanceResidency`, `transferAssessment`, `retention`	Separately review account, billing, support, legal, and subprocessor workflows before claiming every workflow is EU-only.
What role does Arctickey play under GDPR?	Arctickey acts as processor for customer-controlled instance data and controller for account, billing, and service communication data.	`dpaSchedule`, `vendorInventory`, `gdprControls`	Customers remain responsible for their controller role, legal basis, data map, privacy notices, and data subject rights handling.
Are subprocessors disclosed and reviewed?	Current subprocessors, region notes, privacy URLs, DPA links where available, status, and material-change notices are published through the Trust Center and Evidence Pack.	`subprocessors`, `trustChanges`, `accountability`	Customers should record approval, objection decisions, and downstream communication requirements under their own vendor policy.
How are GDPR rights requests supported?	The dashboard supports account-level access, erasure, portability, objection, and DPA requests, and the Evidence Pack includes a user-level erasure playbook for customer-controlled Valkey data.	`privacyRequests`, `erasurePlaybook`, `customerDataMap`	Arctickey does not inspect customer key/value payloads. Customers must map users to keys and delete or export application-controlled data.
Which technical and organizational measures are available?	Arctickey publishes TOMs including TLS, per-instance credentials, password rotation, optional IP allowlisting, dedicated instances, backups, auditability, and trust/status communication.	`securityMeasures`, `controls`, `supportAccess`	Do not present these measures as SOC 2, ISO 27001, CSA STAR, or other certification evidence unless a current audit report exists.
How are incidents and breach assessments supported?	The Evidence Pack includes GDPR-aware incident response prompts, status context, Trust Center references, subprocessor context, and accountability evidence prompts.	`incidentResponse`, `operationalResilience`, `trustChanges`	Customers decide controller breach notification duties, data subject impact, regulator communication, and internal incident classification.
How are retention and deletion handled?	Customer Valkey data remains until instance deletion or customer-controlled key expiry, while managed backups follow plan-based retention windows.	`retention`, `erasurePlaybook`, `operationalResilience`	Customers must set workload TTLs, record no-TTL exceptions, and verify user-level erasure for their own key patterns.
Which compliance claims are not currently supported?	The Evidence Pack is operational evidence for EU vendor review and GDPR readiness work, not a certification, legal opinion, regulator approval, or complete regulatory attestation.	`regulatoryBoundary`, `limitations`	Do not claim SOC 2, ISO 27001, NIS2, DORA, EU AI Act, or similar compliance unless separately implemented and verified.

This starter is exported in the EU Evidence Pack as securityQuestionnaire.

Responsibility Matrix#

Use this matrix to assign customer-side owners for EU controller decisions and connect those decisions to current Arctickey evidence.

Responsibility area	Arctickey role	Customer owner	Decision record
Processing purpose and lawful basis	Provides infrastructure evidence, DPA schedule starter, customer data map templates, and lawful-basis prompts.	Controller, privacy owner, or product owner.	Processing purpose, legal basis, data subject groups, and application owner.
Data classification and minimization	Publishes data classification tiers, prohibited-by-default examples, TOMs, and claim boundaries.	Application owner or privacy engineer.	Workload classification, minimization decision, TTL posture, and high-risk data exceptions.
DPA and subprocessor approval	Provides DPA workflow, DPA schedule starter, subprocessors, material-change notices, and Trust Center evidence.	Legal, procurement, vendor management, or privacy owner.	Approval, objection, escalation, and contract-record evidence.
DPIA and residual risk	Provides DPIA prompts, transfer assessment, incident response guidance, TOMs, and regulatory claim boundaries.	DPO, risk owner, privacy engineer, or security owner.	Likelihood, severity, mitigations, residual risk, approval owner, and consultation decision.
Data subject rights and erasure	Provides privacy request workflow, erasure playbook, retention map, and evidence prompts.	Support, privacy operations, or application owner.	Request timeline, identifiers searched, keys deleted or exported, exceptions, and completion evidence.
Incident and breach assessment	Provides incident response prompts, Trust Center context, operational resilience evidence, and subprocessor context.	Incident commander, security owner, DPO, or legal owner.	Awareness time, affected data categories, risk to individuals, notification decision, and corrective actions.
Retention, backup, and deletion acceptance	Publishes retention categories, backup windows, instance deletion behavior, and exit prompts.	Application owner, privacy engineering owner, or compliance owner.	TTL defaults, backup retention acceptance, deletion workflow, restore-test cadence, and exit evidence.
Evidence pack and accountability ownership	Generates the EU Evidence Pack from current account, trust, and compliance metadata.	Compliance, privacy, product, or procurement owner.	Point-in-time Evidence Pack attached to launch, procurement, DPIA, DPA, RoPA, incident, and request records.

This matrix is exported in the EU Evidence Pack as responsibilityMatrix.

Residual Risk Acceptance#

Use this register to document unresolved EU launch, DPIA, procurement, and operational risks before approving production use.

Risk area	Scenario	Evidence Pack sections	Approval owner
Account, billing, and support metadata	Account, billing, support, and legal workflows may involve separate providers or processing locations even when customer instance data is EU-hosted.	`transferAssessment`, `subprocessors`, `trustChanges`, `customerNotices`, `regulatoryBoundary`	Legal, privacy, procurement, or DPO owner
No-TTL personal data in Valkey	Customer applications may write personal-data-bearing keys without TTLs, extending retention beyond the stated business purpose.	`retention`, `customerDataMap`, `dataClassification`, `lawfulBasis`, `erasurePlaybook`	Application owner, privacy engineer, or product owner
Sensitive or high-risk data	Health, biometric, child, employee, financial vulnerability, profiling, or other high-risk data may be stored in customer-controlled workloads.	`dataClassification`, `dpiaRiskRegister`, `regulatoryApplicability`, `responsibilityMatrix`	DPO, risk owner, security owner, or product leadership
Subprocessor and material-change acceptance	A new or changed subprocessor can affect transfer posture, procurement approval, customer notices, or downstream contractual commitments.	`subprocessors`, `trustChanges`, `accountability`, `procurementEvidence`, `transferAssessment`	Vendor management, procurement, legal, or privacy owner
Backup retention and restore acceptance	Managed backups can retain deleted active data for a plan-based window and restores may reintroduce deleted or expired application data.	`retention`, `operationalResilience`, `erasurePlaybook`, `customerDataMap`	Application owner, SRE, privacy engineering, or compliance owner
Support payload exposure	Customers may paste personal data, secrets, screenshots, logs, or raw payloads into support channels.	`supportAccess`, `securityQuestionnaire`, `incidentResponse`, `accountability`	Support owner, security owner, legal owner, or DPO
Incident notification uncertainty	Customers may not have a documented path for GDPR breach notification, downstream communications, or sector reporting timelines.	`incidentResponse`, `operationalResilience`, `regulatoryApplicability`, `responsibilityMatrix`, `trustChanges`	Incident commander, DPO, legal owner, or security leadership
Unsupported compliance claims	Sales, procurement, launch, or customer-facing material may overstate current EU evidence as certification, legal advice, or complete regulatory compliance.	`regulatoryBoundary`, `securityQuestionnaire`, `regulatoryApplicability`, `limitations`	Legal, compliance, product marketing, or founder owner

This register is exported in the EU Evidence Pack as riskAcceptance.

Data Subject Requests#

When a user asks to access, delete, or export their data:

Identify the application records that reference that user.
Delete or export the relevant Valkey keys from your application.
Delete related queued jobs if they are no longer needed.
Remove session keys to revoke active access.
Contact Arctickey if the request requires account-level or billing-level data.

User-Level Erasure Playbook#

Use this playbook for customer-controlled Valkey key/value data. Arctickey does not inspect customer payloads, so user-level erasure depends on your key design, indexes, TTLs, and application workflows.

Phase	Step	Customer action
Identify	Resolve the data subject to internal identifiers	Map the request to opaque user, account, organization, session, and order identifiers in your source-of-truth database.
Locate	Find Valkey key patterns and secondary indexes	Use your data map to list relevant session, cache, queue, rate-limit, feature-flag, lock, and idempotency key patterns.
Delete	Delete active subject-specific keys	Use Redis-compatible DEL, UNLINK, SREM, ZREM, or queue-library APIs for known keys and indexes.
Expire	Shorten TTLs for derived or shared operational keys	Ensure counters, locks, aggregates, and other derived data have short TTLs and opaque identifiers.
Revoke	Revoke active sessions and tokens	Remove active sessions after erasure, account closure, employee departure, or credential compromise.
Verify	Verify deletion without reading payloads unnecessarily	Record absence checks, TTL checks, and application rehydration checks in your privacy request workflow.

Incident and Breach Assessment#

Arctickey's status page and Trust Center provide operational context for customer-facing incidents. Customers remain responsible for deciding whether an event is a reportable personal data breach for their own processing.

Phase	Customer review question	Evidence source
Triage	Is this only an availability incident, or could personal data confidentiality, integrity, or availability be affected?	Status page, Trust Center, account audit logs, application logs.
Containment	Which credentials, sessions, workers, or integrations should be paused or rotated?	Dashboard security controls, audit logs, application deployment records.
GDPR assessment	Which data categories, subject counts, risks, and mitigations apply?	Customer data map, application logs, EU Evidence Pack.
72-hour window	When did your organization become aware of a potentially reportable breach?	Status timestamps, trust change timestamps, internal incident register.
Communication	Do customers, data subjects, regulators, or internal stakeholders need updates?	Status updates, Trust Center entries, incident summary.
Postmortem	What root cause, timeline, corrective actions, and evidence should be retained?	Status history, trust changes, audit logs, remediation records.

Deletion and Backups#

Deleting an instance removes the active customer Valkey data for that instance. Backup copies follow the plan's retention window and should expire automatically.

For high-risk personal data, use short TTLs and avoid storing the only copy in Valkey.

Retention Map#

Data category	Location	Retention model
Customer Valkey data	EU customer region	Until instance deletion or customer-controlled key expiry
Managed backups	EU-region backup storage	Free 1 day, Starter 7 days, Growth 30 days
Account metadata	EU application database	While the account is active; deletion workflow targets removal on closure
Privacy request records	EU application database	Tracked with a 30-day response deadline
Operational logs and health data	EU operational systems	Limited operational retention for support, abuse prevention, and security
Billing records	Payment provider and Arctickey billing metadata	As required for tax, accounting, and legal obligations

This retention map is also included in the downloadable EU Evidence Pack from the dashboard compliance page.

Technical and Organizational Measures#

Arctickey publishes technical and organizational measures for vendor review and DPA schedules in the Security guide. The EU Evidence Pack also includes the current measure list.

Area	Example measure	Customer action
Encryption	TLS-only customer connections	Use rediss:// URLs and keep certificate verification enabled.
Access control	Per-instance credentials and password rotation	Store credentials in a secrets manager and rotate after employee or deployment changes.
Network restrictions	Optional source IP allowlisting	Enable allowlists for production apps with stable egress IPs.
Isolation	Dedicated instances and hostnames	Separate production, staging, and different risk profiles into different instances.
Auditability	Audit logs and account evidence exports	Export evidence before procurement reviews or internal control checks.
Data minimization	Customer-controlled key design and TTLs	Avoid personal data in keys and set TTLs for personal-data-bearing values.

International Transfers#

Arctickey's operating posture is EU-first: customer instance data is not transferred outside the EU/EEA for normal service operation. Customers should still maintain a transfer review record for their own processing, especially around billing metadata, support tickets, and future subprocessor changes.

Area	Arctickey position	Customer review item
Customer Valkey data	EU-region hosting for normal service operation.	Document selected region and avoid unnecessary personal data in keys or values.
Backups	EU-region backup storage with plan-based retention.	Confirm backup retention matches your erasure and retention policy.
Account and billing metadata	Account metadata is processed by Arctickey; billing metadata may involve the payment provider.	Review current subprocessors and record billing-provider processing in your vendor inventory.
Support	Support should rely on metadata and diagnostics, not customer key/value payloads.	Do not paste secrets or personal data into support tickets unless required.
Material changes	Subprocessor changes can be published with customer notice periods.	Review active material-change notices before regulated production use.

Vendor Inventory and RoPA#

Use the dashboard compliance page and EU Evidence Pack as starter material for your vendor inventory and Article 30 records of processing activities. Customers must adapt these prompts to their own processing purposes, legal bases, data categories, and retention decisions.

RoPA field	Suggested Arctickey entry	Customer action
Vendor and service	Arctickey, EU-hosted Redis-compatible Valkey infrastructure.	Record the contract owner, procurement owner, and internal system owner.
Roles	Arctickey is processor for customer instance data and controller for account, billing, and service communication data.	Document your controller role for data you write to Valkey.
Purpose	Caching, sessions, queues, rate limiting, locks, and operational application data.	Map the purpose to your application feature and legal basis.
Data subjects	End users, administrators, employees, or other subjects whose data you store in Valkey.	Replace with your actual data subject categories.
Personal data categories	Customer-defined identifiers, session state, cached profile attributes, job references, rate-limit identifiers, and derived operational metadata.	List actual fields, key patterns, TTLs, and source systems in your data map.
Recipients and subprocessors	Current subprocessors are published through the Trust Center and subprocessors page.	Review subprocessors, DPA links, region notes, and active material-change notices.
Transfers	Customer instance data is EU-hosted for normal service operation.	Separately assess billing metadata, support workflows, and future subprocessor changes.
Retention	Customer controls key TTLs and deletion; managed backups follow plan-based retention.	Set TTLs and maintain user-level erasure evidence.
Security measures	TLS, credentials, password rotation, IP allowlisting, isolation, auditability, backups, public status, and trust-change communication.	Verify application TLS usage, secret storage, API keys, and production access controls.
Evidence	EU Evidence Pack, Trust Center, GDPR guide, Security guide, Data Residency guide, and Subprocessors and DPA page.	Attach current evidence to your RoPA, DPIA, vendor review, or procurement ticket.

DPIA and Vendor Review Prompts#

Use these prompts when approving Arctickey for production workloads:

Area	Prompt	Evidence	Customer action
GDPR roles	Have controller and processor roles been documented?	Arctickey is processor for customer instance data and controller for account, billing, and service communication data.	Document Arctickey in your vendor inventory and map your legal basis for the personal data you write to Valkey.
Data map	Which personal data categories will be stored in Valkey?	Arctickey provides EU-hosted Redis-compatible infrastructure but does not inspect customer key/value payloads.	Keep a data map for sessions, queues, caches, rate limits, and derived identifiers before production use.
Retention	Are TTLs and erasure workflows defined for user-level data?	Instance deletion removes active customer Valkey data; managed backups follow plan-based retention.	Set TTLs for personal-data-bearing keys and maintain a user-to-key deletion strategy in your application.
Subprocessors	Have subprocessors and material change notices been reviewed?	The Trust Center and subprocessors page publish current subprocessors and active material change notices.	Review current subprocessors before procurement approval and subscribe internally to vendor-change review.
DPA	Is a Data Processing Agreement required before production use?	DPA requests are available from the dashboard compliance page and tracked with admin status.	Request a DPA before processing regulated or production personal data if your policy requires one.
Security	Are connection security and operational controls acceptable?	Arctickey supports TLS connections, audit logs, password rotation, IP allowlists, backups, and status/incident communication.	Verify your app uses TLS connection strings, least-privilege API keys, and no secrets in cache keys or queue payloads.
Evidence	Has current evidence been exported for the procurement record?	The EU Evidence Pack exports account-scoped residency, retention, privacy request, subprocessor, and trust-change metadata.	Attach the downloaded EU Evidence Pack to your DPIA, vendor review, or procurement ticket.

Before Production#

Download your account metadata export from dashboard settings when you need a machine-readable copy of account, instance, backup, alert, API key metadata, and audit log records.
Request a DPA if you process personal data.
Review the EU Launch Readiness section on the dashboard compliance page.
Review EU Data Residency.
Review Subprocessors and DPA.
Verify your own privacy policy explains how you use Redis-compatible infrastructure.
Test account deletion and instance deletion flows in your application.

EU Launch Readiness#

The dashboard compliance page scores the account against EU readiness checks. The score is also included in the downloadable EU Evidence Pack.

Check	What it verifies
Residency	Customer instances are reported in EU regions.
DPA	A DPA request has been recorded when your policy requires one.
DPA schedule	A processing schedule starter is available for Article 28 annex review.
GDPR rights	Access, erasure, portability, objection, and DPA request workflows are available.
Procurement evidence	Reviewer packages are available for EU procurement, DPIA, vendor-risk, security, launch, incident, and executive review.
Support access	Support instruction, redaction, credential, emergency access, and disclosure prompts are available.
Subprocessors	Public subprocessors and active material-change notices are reviewable.
Trust log	Recent trust changes can be attached to procurement and incident reviews.
Accountability	Evidence ownership and refresh-cadence prompts are available.
Customer notices	Privacy notice and controller-disclosure prompts are available.
GDPR controls	GDPR control mappings are available with Evidence Pack section references.
Data classification	Workload risk tiers and prohibited-by-default data prompts are available.
DPIA	Infrastructure risk prompts are available for customer-side DPIA review.
Lawful basis	Workload-level lawful-basis and minimization prompts are available.
Operational resilience	Backup, restore, incident communication, availability, change, and exit prompts are available.
Regulatory boundary	Supported EU evidence and unsupported compliance claims are separated.
Regulatory triage	EU regulatory applicability prompts are available for customer-side review routing.
Security questionnaire	EU procurement and security questionnaire starter answers are available.
Responsibility	Controller/processor ownership prompts are available.
Risk acceptance	Residual risk acceptance prompts are available for EU launch, DPIA, procurement, incident, support, retention, and claim review.
Retention	Retention categories and backup windows are documented.
Transfers	EU transfer assessment items are documented.
Security	Technical and organizational measures are documented.
Vendor inventory	Vendor inventory and RoPA prompts are available.
Procurement	Vendor review checklist items are available for DPIA and procurement records.