Security & Compliance Readiness

ASTIS exists to give organizations cryptographic control over sensitive business data.

Email providers, SaaS applications, cloud databases, and automation tools should not automatically become places where plaintext and decryption authority live forever. ASTIS separates storage, delivery, and computation from cryptographic control: infrastructure may route or store encrypted artifacts, but access to plaintext remains governed by customer-controlled keys, policy, TTL, and audit.

ASTIS has two product lines built on the same security model:

  • ASTIS Mail is a packaged secure workspace for protected business communication. It works with existing email providers while keeping message decryption separate from mailbox storage.
  • ASTIS API platform gives engineering and security teams sealed envelope encryption, hash-only signing, format-preserving tokenization, CVS, BYOK, HYOK, and tamper-evident audit primitives for their own applications and workflows.

The goal is simple: access to infrastructure should not automatically mean access to customer data.

This page describes our security program and compliance readiness. We do not claim certifications we have not completed. CASA Tier 2 has been completed; the validation report can be shared under NDA on request. SOC 2 Type II is in progress; ISO 27001 is on the roadmap. Enterprise contracts can include supplementary controls such as BYOK / HYOK, custom DPA, audit export, security review, and CVS Hybrid deployment.

Our security principles

Customer-controlled plaintext

Plaintext should exist only where it is needed: on the user device, customer application, or customer-controlled trust boundary. ASTIS is designed to avoid storing plaintext customer content.

Infrastructure access is not data access

A compromised mailbox, database, or infrastructure component should not automatically grant access to protected content. Decryption authority is separated from storage and delivery.

Separation of concerns

Mail providers handle routing and mailbox storage. Customer systems handle business workflow and data storage. ASTIS handles cryptographic control, policy enforcement, key workflows, and audit evidence.

Minimum-trust architecture

ASTIS services are designed to process the smallest amount of data required for each operation: capsules, hashes, encrypted artifacts, policy metadata, and audit events.

Customer key custody

Customers can choose the custody model that matches their risk profile: ASTIS-managed, BYOK, HYOK, or CVS Hybrid.

Tamper-evident audit

Security-relevant actions are recorded so customers can review access, export evidence, and support vendor-risk or regulatory review.

Compliance Readiness

Honest status per program. We use four explicit labels — Implemented, In progress, Planned, Supported by contract — instead of generic green checks. Items listed as Supported by contract are unlocked through Enterprise / API contractual controls, not through industry certification ASTIS itself holds.

CASA Tier 2

Cloud Application Security Assessment (CASA) Tier 2 verification completed.

Implemented

GDPR (EU/EEA)

Designed to support GDPR workflows. DPA available for business customers; data-subject-request handling supported on Enterprise plans.

Supported by contract

US Privacy (CCPA/CPRA)

Designed to support US state privacy workflows. We assist with privacy rights requests (access / deletion) under contract where applicable.

Supported by contract

SOC 2 Type II

Readiness program in progress — policies, evidence collection, and independent audit planning. Target: design-partner letter of readiness available under NDA in 2026.

In progress

ISO 27001

Roadmap item; controls designed around the ISO 27001 control catalogue but no certification yet.

Planned

Enterprise / Regulated workloads

Enterprise contracts add BYOK / HYOK key custody, extended audit retention and export, custom DPA / BAA, security review support, and SLA. ASTIS does not claim sector-specific certifications such as HIPAA / PCI / FedRAMP today.

Supported by contract

Data Protection

Controls are designed around production systems, customer metadata, encrypted capsules, keys, and audit logs. We follow common security frameworks (NIST CSF, ISO 27001 control catalogue) but do not claim certification we have not yet completed.

Data at rest

All production datastores are encrypted at rest. Sensitive fields are additionally protected at the application level where applicable.

Data in transit

TLS is enforced for data transmitted over potentially insecure networks.

Backups & retention

Encrypted backups are performed on a defined schedule. Backup retention: 30 days.

Hosting model

ASTIS runs on dedicated servers (not public cloud hosting). See /legal/subprocessors for third-party providers.

ASTIS Mail security model

How ASTIS Mail protects message content while leaving delivery and mailbox storage with your existing email provider.

Decouple delivery from security

ASTIS does not replace your email provider.

Your provider handles:

  • Message routing & delivery
  • Mailbox storage (IMAP/Exchange)
  • Provider-side backups and retention

ASTIS handles:

  • Encryption key control for protected content
  • Organization policies (who can decrypt)
  • TTL (time-bound access)
  • Security-relevant audit events

Key Rewrap and CVS scope

ASTIS API endpoints and persistent storage do not receive plaintext message content or plaintext session keys. In ASTIS-managed CVS workflows, approved Key Rewrap operations may transiently unwrap session-key material in memory only — for example when a recipient registers after a message was encrypted to a temporary holding key, or when an organization rotates encryption keys. The unwrapped material is not persisted, not logged, and not accessible via API.

HYOK and CVS Hybrid customers move this trust boundary to their own infrastructure: the rewrap operation runs on the customer's CVS deployment, and ASTIS has no key-material access at all. This is the recommended posture for organizations that cannot accept any in-memory plaintext exposure on ASTIS-managed servers.

Architectural detail: see RFC-014 (E2E messaging) and the per-endpoint Zero-Knowledge analysis available under NDA.

Key custody and OpenPGP key management

Public keys — WKD

ASTIS operates a Web Key Directory (WKD) service for distributing users' public OpenPGP keys. Public keys are intended to be shared openly and contain no private key material.

Private keys — customer custody by default

Mail user private keys are generated and held client-side in the browser or device. API and organization keys are customer-generated and submitted to ASTIS only as sealed material. CVS performs approved key operations on this sealed material; HYOK and CVS Hybrid keep the custody boundary on customer infrastructure entirely.

If a mailbox provider is compromised

Mailbox access (IMAP compromise, account takeover, provider-side exposure, backups) does not automatically grant plaintext access to ASTIS-protected message content, because decryption is controlled separately via policies and TTL.

Caveat: this protects future access. Content that was already fetched and decrypted by a legitimate recipient before the compromise — and any plaintext copy the recipient kept locally — cannot be retroactively clawed back through ASTIS.

TTL and time-bound access

ASTIS supports TTL (time-to-live) for protected messages:

  • Policies can enforce default TTL per organization
  • After TTL expiration, decryption access is stopped according to policy
  • TTL controls access expiry (no release/rewrap after expiry) — reduces long-term exposure from mailbox retention and backups

Caveat: TTL stops future capsule release and rewrap. It does not delete already-delivered ciphertext from mailbox storage, and it cannot revoke session keys already fetched and used by a recipient.

Policies and audit

Organization-wide policies define decryption rules and security defaults. Security-relevant actions are recorded for audit purposes:

  • Policy changes
  • Administrative actions
  • Decryption-related events

ASTIS API platform security model

How customer applications integrate ASTIS without handing plaintext to ASTIS, cloud providers, or AI tools.

Sealed envelope at the API gateway

Customer applications send encrypted payloads to ASTIS API endpoints. The gateway routes, validates, and returns sealed artifacts without ever decrypting plaintext on ASTIS infrastructure. Schema, format, and length metadata may be inspected; payload content is not.

Architecture: RFC-008 (sealed envelope pattern).

Hash-only sign and verify

The signing service receives a cryptographic hash of the document, not the document itself. Signatures bind the hash; verification works without the verifier ever seeing the original payload. Suitable for legal-grade signing, contract workflows, and tamper-proof receipts where the signing service must not see content.

Format-preserving tokenization (FPE)

Sensitive fields are replaced with cipher that keeps the same shape as the plaintext (length, character class). Drop-in for existing schemas, useful for PCI scope reduction and database column protection without migrations.

FPE master keys are split between ASTIS and the customer custodian — neither side holds a complete master alone. The customer fetches a sealed share once per session and runs FF1 client-side; the actual tokenization happens on customer infrastructure.

Customer key custody — BYOK / HYOK / CVS Hybrid

Three deployment models for key authority:

  • BYOK — customer-generated keys held by ASTIS-managed CVS as sealed material; customer can revoke at any time.
  • HYOK — customer keys never leave customer infrastructure; ASTIS calls back to a customer-controlled key endpoint for sealed operations.
  • CVS Hybrid — the entire CVS service runs on customer infrastructure (Helm chart, mTLS, service-level PGP). ASTIS has no key-material access at all.

Tamper-evident audit chain

Every cryptographic operation is recorded into a hash-chained event log. Any tampering breaks the chain and is immediately detectable. Customers can export their evidence for compliance review or litigation hold; ASTIS does not modify or rewrite historical events.

No plaintext at the API gateway

ASTIS API endpoints do not accept, return, or log plaintext message content or plaintext session keys. The single architectural exception — transient in-memory unwrap during ASTIS-managed CVS rewrap — is documented above (Key Rewrap and CVS scope) and is removed entirely under HYOK / CVS Hybrid.

Security Controls

Each control carries an explicit status badge: Implemented, In progress, or Planned. The badge — not the bullet icon — is the source of truth. For questions about the current status of any specific control, contact [email protected].

Infrastructure Security

Implemented

Unique production database authentication enforced

Implemented

Encryption key access restricted

Implemented

Access control procedures established

Organizational Security

Implemented

Asset disposal procedures utilized

Implemented

Production inventory maintained

Implemented

Portable media encrypted

Product Security

Implemented

Data encryption utilized

In progress

Control self-assessments conducted

Planned

Penetration testing

Internal Security Procedures

Implemented

Continuity and disaster recovery plans established

In progress

Continuity and disaster recovery plans tested

Planned

Cybersecurity insurance

Data and Privacy

Implemented

Data retention procedures established

Implemented

Customer data deleted upon leaving

Implemented

Data classification policy established

Access Control & Operational Security

Identity and access management

  • Production access is restricted to authorized personnel
  • Administrative access uses strong authentication (MFA) and is logged
  • Access is reviewed on a recurring schedule
  • Separation of environments: dev / staging / production

Change management & secrets

  • Infrastructure and application changes follow a review process
  • Critical changes require approvals and are traceable
  • Secrets are not stored in source control
  • Secrets are rotated and restricted by environment and role

Monitoring, Detection & Incident Response

Monitoring & alerting

Availability and security signals are monitored continuously. Alerts are triaged with defined on-call procedures.

Vulnerability management

Dependencies are monitored for known vulnerabilities. Security patches are prioritized based on severity and exposure.

Incident response

We maintain an incident response process with escalation, containment, and post-incident review. For Enterprise customers, notification terms are governed by contract/DPA.

Subprocessors & Data Locations

Subprocessors

See /legal/subprocessors for the full list of third-party providers used by ASTIS.

Hosting model

ASTIS runs on dedicated servers (not public cloud hosting).

Data retention and deletion

See Privacy Policy for retention details

Responsible Disclosure

If you believe you have found a security vulnerability, please email [email protected] with:

  • A detailed description
  • Steps to reproduce
  • Impact assessment (if known)

We aim to acknowledge reports within 72 hours and are committed to working with security researchers to verify and address any potential vulnerabilities in a timely manner.

Frequently Asked Questions