Public procurement evidence · reviewed 4 September 2026
Sealkeep Subprocessor Register — public verification view
This view intentionally exposes the current verification gap. It must not be treated as a completed DPA annex until each provider's production use, legal entity, location, transfer mechanism, contract, and deletion terms are verified.
| Provider/service category | Intended purpose and data | Applies to | Current state |
|---|---|---|---|
| Cloudflare / R2 and web delivery | Encrypted archive objects, object keys/checksums; web request metadata where enabled | Managed storage and public website | Product and current operations identify these services; contracting entity, locations, transfer terms, and deletion evidence remain to verify |
| Google services | Optional Google sign-in; GCS migration fallback; optional customer-selected Google Drive is excluded when contracted directly by customer | Selected hosted features | Implementation identifies these services; exact production scope, legal entity, access locations, and transfer terms remain to verify |
| Transactional email | Account verification and operational email: address, template content, delivery events | Hosted accounts | Implementation references Postmark; production account and contracting entity remain to verify |
| Hosted application/database platform | Account, device, operational, billing, encrypted metadata, and request-log data | Hosted service | Production infrastructure provider and locations remain to verify |
| Payment provider | Subscription, invoice, tax, and payment administration; Sealkeep should not receive full card data | Paid hosted service | Add only after production billing configuration is verified |
| External support system | Contact details, cases, attachments, and customer-supplied diagnostics | Support, if externally operated | Add only if support is not handled solely in Spala-controlled systems |
| Monitoring/error service | Request metadata, pseudonymous identifiers, and diagnostics; no transcript plaintext by design | Hosted service, if enabled | Add only after production configuration is verified |
Not Spala Subprocessors in fully self-hosted operation
A provider selected, contracted, and controlled directly by the customer is not appointed by Spala merely because Sealkeep interoperates with it. This commonly includes the customer's:
- PostgreSQL, Kubernetes, virtual-machine, container, and network providers;
- S3, R2, GCS, Backblaze B2, Google Drive, MinIO, or compatible object storage;
- identity, logging, monitoring, backup, email, and support systems;
- coding-agent vendors whose local files the customer elects to archive.
If Spala selects, contracts, or can instruct a provider on the customer's behalf, its role must be reassessed and the applicable register updated.
Change process proposed for the signed DPA
- Review a provider before it receives production Customer Personal Data.
- Record entity, purpose, data, locations, retention, security, onward processors,
and transfer mechanism.
- Execute applicable Article 28 flow-down terms before production use.
- Provide at least 30 days' notice before adding an applicable Subprocessor.
- Accept reasonable data-protection objections within the agreed review window.
- Date the register when a provider begins or ends production use.
Verification and objections: privacy@spala.ai