Architecture & data flow
PublishedPlaintext boundary, encrypted archive path, hosted metadata, key custody, deployment modes, and runtime egress.
- Hosted, connected self-hosted, and fully isolated paths
- Fields visible and not visible to Spala
Public Trust Center · reviewed 5 September 2026
Inspect before you ask.
Architecture, privacy terms, operational ownership, known limitations, and assurance work should not require a sales call. These materials show the current contract framework, implemented controls, verification work, and open assurance items.
PublishedPublic templateOpen item
Evidence index
Seven buyer questions. Seven inspectable answers.
Each artifact opens as a dated, branded document that security, legal, and procurement teams can review, print, or retain. Status and open assurance items are stated directly.
Data Processing Agreement
Public templateHM Software LLC’s Article 28 contract framework covering roles, instructions, confidentiality, security, subprocessors, assistance, incidents, deletion, and audit.
- Internally approved for customer review
- Customer annexes and applicable law completed for signature
Technical & organisational measures
Control statementCurrent product controls are separated from operational measures supplied by the selected hosted or customer-operated deployment.
- Encryption, identity, network, secure development, logging, continuity
- Deployment-specific evidence is identified clearly
Subprocessor register
Verification openThe public register distinguishes Spala-selected hosted services from infrastructure selected and contracted directly by a self-hosted customer.
- Known service categories shown now
- Legal entities, regions, and transfer safeguards still require verification
Deployment responsibility matrix
PublishedWho owns application delivery, infrastructure, identity, keys, backups, monitoring, patches, support access, and exit.
- Connected and fully isolated boundaries
- No standing Spala access in the isolated mode
Release provenance & SBOM
Partial todayPackage locking, checksum manifests, optional signed manifests, test evidence, and the gaps before release provenance is a complete buyer control.
- No claim of OS code-signing today
- Public CycloneDX SBOM publication remains planned
Threat model & audit roadmap
Audit prep · Q3 2026Adversaries, trust assumptions, detected tampering, completed internal evidence, and the preparation path to independent review.
- Review package and public evidence are being prepared
- External cryptographic review remains the next assurance gate
Architecture / published
Plaintext ends at the endpoint.
The diagram describes the fully isolated path. In the hosted path, Spala operates the control plane and may arrange storage, but the endpoint still performs encryption before upload and retains the keys needed to open an archive.
Coding agentClaude Code or Codex session file
→
Local Sealkeep clientCapture, encryption, local search, keys
→
Customer serviceIdentity, membership, opaque metadata
→
Customer storageEncrypted archive objects and index
Customer security boundary · fully isolated operation has no mandatory Spala runtime service
| Data | Endpoint | Hosted Spala mode | Fully isolated mode |
|---|---|---|---|
| Session plaintext | Visible | Not designed to receive it | Not visible to Spala |
| Recovery phrase / private keys | Held locally | Not received | Not visible to Spala |
| Ciphertext and opaque archive metadata | Produced locally | Processed for selected hosted service | Customer systems only |
| Account, device, entitlement records | Uses identifiers | Processed by hosted control plane | Customer service; separate contract contacts may remain with Spala |
Exact scope
Ciphertext size, timing, identifiers, and operational metadata are not described as anonymous. Support cannot decrypt an archive or replace a lost recovery phrase. Customer-selected infrastructure does not become a Spala subprocessor merely because Sealkeep interoperates with it.
Shared responsibility / published
You operate the boundary. We deliver the product.
The exact allocation is completed in the order form, but the default fully isolated split is explicit.
| Control area | HM Software / Spala | Customer |
|---|---|---|
| Product | Application bundle, version, documentation, integrity information | Acceptance, approved configuration, permitted use |
| Infrastructure | Document requirements and optional dependencies | Runtime, network, PostgreSQL, storage, TLS, regions |
| Identity and keys | Preserve endpoint-encryption and recipient design | Identity, administrators, secrets, recovery material, recipients |
| Operations | Security updates and agreed support | Monitoring, backups, restore, capacity, patch timing, retention |
| Support access | No standing access; use approved minimum when invited | Authorize, time-bound, observe, and revoke any access |
| Exit | Document export and deletion within Spala-controlled systems | Export/delete customer database, objects, logs, endpoints, backups |
Active assurance roadmap
Evidence first. Independent review next.
The Q3 2026 workstream packages implemented controls, test evidence, and review scope so an external assessor can evaluate a precise, versioned target.
Implemented and exercised
- Authenticated-encryption vectors and tamper suite
- Archive, verify, restore, and tenant-boundary tests
- 12/12 live company rehearsal recorded 20 August 2026
- Checksum manifest generator and dependency lockfile
Independent-review preparation
- Threat model and known limitations
- Public DPA template and TOMs control statement
- Architecture and responsibility boundaries
- Subprocessor and release-evidence verification
External validation
- Independent cryptographic implementation review
- External key-lifecycle review
- Independent application penetration test
- Public per-release SBOM and signed provenance
- Native OS code signing
Current assurance boundary
The review program is active, but Sealkeep does not currently claim an independent cryptographic audit or certification. Published tests and rehearsals give reviewers inspectable evidence while external validation remains the next gate.
Disclosure boundary
Public by default. Controlled where disclosure creates risk.
Gating ordinary procurement facts creates friction without making the product safer. The boundary below keeps useful evidence discoverable while protecting customer and operational security.
Keep public
- Architecture and data categories
- Standard DPA and TOMs samples
- Current Subprocessor register
- Deployment responsibility matrix
- Threat model, known limitations, audit roadmap
- Release checksums, SBOMs, and provenance status
Keep controlled
- Executed customer agreements and negotiated terms
- Customer-specific diagrams, identities, regions, and configurations
- Unpatched vulnerability and exploit detail
- Credentials, internal infrastructure identifiers, and runbooks
- Restricted penetration-test reports and incident evidence
- Time-bounded support-access records