EU Data Residency

Arctickey is built for teams that need Redis-compatible infrastructure with customer instance data kept in the European Union.

Current Hosting Model#

  • Customer Valkey instance data is hosted in EU data centers.
  • The default production region is EU East.
  • Backups are stored in EU-region storage.
  • TLS is required for customer connections.
  • Customer instance data is not transferred outside the EU/EEA for normal service operation.

Data Types#

Data typeLocationNotes
Valkey instance dataEUData written by customers to their instances
BackupsEURetention depends on plan
Instance metadataEUInstance name, plan, region, status, limits
Logs and health checksEUUsed for support, security, and operations
Billing dataPayment providerProcessed by Polar; Arctickey does not store card details

Customer Data Map#

Customer Valkey data location is only one part of EU readiness. Customers should keep their own data map for key patterns, data categories, legal basis, TTLs, and deletion owners. The dashboard compliance page includes starter templates for sessions, caches, queues, rate limits, feature flags, locks, and idempotency keys.

The EU Evidence Pack exports these templates as customerDataMap so they can be attached to DPIA and procurement records.

Data Classification#

Before relying on EU residency for regulated workloads, customers should classify the data they plan to store in Valkey. The dashboard compliance page and EU Evidence Pack include a dataClassification guide with low-risk operational, standard personal data, sensitive/high-risk, and prohibited-by-default tiers.

Use the classification guide to block secrets, raw tokens, payment card numbers, national identifiers in keys, and other data that should be redesigned or separately approved before production.

GDPR Control Mapping#

The dashboard compliance page and EU Evidence Pack include a gdprControls mapping that links Arctickey evidence to common customer-side GDPR control areas such as Articles 5, 6, 28, 30, 32, 33-35, and Chapter V transfers.

Use the mapping as an evidence index. It does not replace the customer's legal interpretation, policy ownership, or approval workflow.

Accountability Evidence#

The EU Evidence Pack includes an accountability register that helps customers decide which point-in-time exports to retain for launch approval, DPA review, RoPA updates, DPIA review, subprocessor notices, data subject requests, incidents, and retention reviews.

Use it to assign evidence owners and refresh cadence before regulated production processing.

Customer Notices#

EU residency facts often need to be reflected in customer-side privacy notices, DPA annexes, RoPA records, procurement approvals, and launch checklists. The dashboard compliance page and EU Evidence Pack include a customerNotices checklist for processor role, processing purpose, data categories, data subject categories, EU residency, subprocessors, retention, deletion, and data subject rights disclosures.

Use it as a transparency review prompt. Customers should adapt the language to their own controller role, application purpose, legal basis, and actual data categories.

Support Access and Disclosure#

Support access is part of the EU operational boundary. Arctickey's EU Evidence Pack includes a supportAccess register for support scope, payload minimization, customer instructions, emergency access, credential handling, and exceptional disclosure review.

Use the register to keep support workflows metadata-first. Customers should share timestamps, instance IDs, diagnostics, and synthetic examples before sharing any personal data, and should retain evidence for approved exceptions.

Operational Resilience#

EU residency must be paired with continuity planning. The dashboard compliance page and EU Evidence Pack include an operationalResilience register for backup retention acceptance, restore readiness, availability dependencies, incident communications, material change review, and exit planning.

Use the register to document customer-side fallback behavior, restore test evidence, communication owners, and continuity decisions. It is operational guidance, not a certification claim.

Lawful Basis and Minimization#

EU residency does not replace controller-side lawful-basis review. The dashboard compliance page and EU Evidence Pack include a lawfulBasis matrix for common Valkey workloads so teams can document:

  • The purpose for storing personal data in Valkey.
  • The likely lawful-basis prompt to review under the customer's policy.
  • The minimization decision, such as opaque identifiers and derived data.
  • The TTL or deletion evidence expected for each workload.

User-Level Erasure#

Instance deletion removes active customer Valkey data for the whole instance. User-level erasure is customer-controlled and depends on application key design. For production workloads that may contain personal data:

  • Keep a user-to-key or user-to-session index for active sessions.
  • Prefer opaque identifiers in keys instead of emails, names, or national identifiers.
  • Use short TTLs for caches, rate limits, locks, queues, and derived records.
  • Use queue-library cleanup APIs where possible so queue metadata remains consistent.
  • Verify deletion through key absence and TTL checks without exposing payloads.

The EU Evidence Pack exports this operational guidance as erasurePlaybook.

EU Transfer Assessment#

Customer instance data is not transferred outside the EU/EEA for normal service operation. Customers should still keep a transfer review record for account metadata, billing providers, support workflows, and future subprocessor changes.

AreaCurrent positionTransfer riskSafeguardsCustomer action
Customer instance dataHosted in EU regions for normal service operationNo routine non-EU transfer is expected for customer key/value payloadsEU-region hosting, TLS in transit, dedicated instances, customer-controlled TTLs, and deletion controlsDocument the selected EU region and avoid writing unnecessary personal data into keys or values
Managed backupsStored in EU-region backup storage with plan-based retentionBackup copies can extend the time window before deleted active data expires from operational copiesPlan-based retention windows and restore-only operational useSet short TTLs for personal-data-bearing keys and choose backup retention that matches your policy
Account and billing metadataProcessed by Arctickey systems; billing may be processed by the payment providerBusiness metadata may be subject to provider processing locations and legal obligationsPublished subprocessors, privacy links, DPA links where available, and material-change noticesRecord billing-provider treatment in your vendor inventory
Support and incident responseSupport should use metadata rather than customer key/value payloadsSupport tickets can include personal data if customers paste it into messagesCustomer guidance, audit logs, status communication, and minimization language in request formsDo not include secrets or personal data in support tickets unless required
SubprocessorsCurrent subprocessors and material changes are published through the Trust CenterA future provider change can introduce new processing locations or transfer mechanismsPublic disclosure, notice periods, and region notesReview active notices before regulated production use

Retention Summary#

Data categoryRetention model
Customer Valkey dataUntil instance deletion or customer-controlled key expiry
Managed backupsFree 1 day, Starter 7 days, Growth 30 days
Account metadataWhile the account is active; deletion workflow targets removal on closure
Privacy request recordsTracked with a 30-day response deadline
Operational logs and health dataLimited retention for support, abuse prevention, and security
Billing recordsRetained as required for tax, accounting, and legal obligations

Regions#

Arctickey currently exposes one customer-selectable production region:

RegionLocationStatus
EU EastLithuaniaAvailable
EU CentralEuropean UnionPlanned
EU WestEuropean UnionPlanned

Additional regions should stay within the EU unless the product explicitly introduces a separate non-EU offering.

Subprocessors#

The current subprocessor list and DPA information are maintained in Subprocessors and DPA.

Keep this list aligned with the privacy policy and production infrastructure before launch.

GDPR Workflows#

Arctickey should support these customer-facing workflows before public launch:

  • Data Processing Agreement available on request.
  • Account deletion.
  • Instance deletion.
  • Backup retention enforcement.
  • Export instructions for customer-owned Valkey data.
  • Audit logs for security, billing, backup, restore, and lifecycle actions.

EU Launch Readiness#

Logged-in customers can review account-specific EU Launch Readiness from the dashboard compliance page. The readiness score combines:

  • Instance residency status.
  • DPA request status.
  • GDPR rights workflow availability.
  • Procurement evidence reviewer packages.
  • Support access and disclosure guidance.
  • Published subprocessors and active material-change notices.
  • Trust change log availability.
  • Accountability evidence, customer notices, procurement evidence, support access, operational resilience, regulatory boundary, regulatory applicability triage, security questionnaire, responsibility matrix, residual risk acceptance, GDPR control mapping, data classification, data map, lawful-basis, retention, transfer assessment, technical measures, vendor inventory, and vendor review coverage.

The same readiness result is exported in the EU Evidence Pack for procurement and DPIA records.

Procurement Evidence Index#

The EU Evidence Pack includes a procurementEvidence section that groups evidence for legal, privacy, security, vendor-risk, engineering launch, incident operations, and executive sign-off reviewers.

Use it to attach the right Evidence Pack sections to each customer-side approval record instead of sending every reviewer the same undifferentiated export.

Security Questionnaire Starter#

The EU Evidence Pack includes a securityQuestionnaire section with starter answers for common EU procurement and security due-diligence questions. Each answer includes the relevant Evidence Pack section and a claim boundary so teams can avoid unsupported compliance statements.

Use it for vendor questionnaires, DPIA evidence tables, controller due-diligence reviews, and procurement tickets.

Responsibility Matrix#

The EU Evidence Pack includes a responsibilityMatrix section for assigning customer-side owners to controller decisions and linking those decisions to Arctickey evidence.

Use it for launch approval, DPA review, DPIA residual-risk sign-off, RoPA updates, erasure handling, incident notification decisions, retention approval, and point-in-time evidence retention.

Residual Risk Acceptance#

The EU Evidence Pack includes a riskAcceptance section for recording unresolved EU launch, DPIA, procurement, support, incident, retention, and unsupported-claim risks.

Use it to assign an approval owner, document mitigation decisions, set review triggers, and attach the Evidence Pack version used for production approval.

Regulatory Boundary#

The EU Evidence Pack includes a regulatoryBoundary matrix that separates current evidence from unsupported regulatory or certification claims. Use it when answering procurement questionnaires, writing privacy notices, or approving launch material.

  • Arctickey can claim GDPR-supporting operational evidence for EU-hosted Valkey workloads, but does not decide the customer's legal basis, DPIA outcome, breach notification duty, or Article 30 content.
  • Arctickey can claim customer instance data is EU-hosted for normal service operation, but account, billing, support, legal, and subprocessor workflows require separate review.
  • Arctickey publishes technical and organizational measures, but should not claim SOC 2, ISO 27001, CSA STAR, or similar certifications without current audit evidence.
  • Arctickey provides operational resilience evidence for vendor-risk review, but should not claim NIS2 or DORA compliance.
  • Arctickey infrastructure may support AI-adjacent applications, but should not claim EU AI Act compliance, high-risk AI conformity, or model governance coverage.

Regulatory Applicability Triage#

The EU Evidence Pack includes a regulatoryApplicability section for routing customer-side review of GDPR/ePrivacy, NIS2, DORA, EU AI Act, Cyber Resilience Act, Data Act, and sector-specific requirements.

Use it to decide which internal owner should review the workload before launch. Applicability depends on the customer's sector, role, Member State implementation, and actual processing; it is not a compliance attestation.

Do not claim the following until implemented and verified:

  • SOC 2, ISO 27001, CSA STAR, NIS2, DORA, or EU AI Act compliance.
  • Dedicated private networking.
  • Guaranteed multi-region failover.
  • Customer-managed encryption keys.