SECURITY · CRYPTOGRAPHIC EVIDENCE CUSTODY · AUDIT-DEFENSIBLE

Zero-retention architecture.Tamper-evident evidence.

The system of record for engineering truth — cryptographically signed, deterministic audit evidence, generated automatically.

Built for CISOs, security architects, audit-firm technologists, Heads of Risk, and CROs at firms operating under SOC 2 Type II, ISO 27001, NYDFS Part 500, DORA, or SR 11-7. Déjà produces evidence that has to hold up to your audit firm's scrutiny — which means our own security posture has to hold up to the same. Deterministic Abstract Syntax Tree (AST) analysis, eight weighted scoring factors (W1–W8), Ed25519-signed receipts written to an immutable, append-only, tamper-evident ledger. No LLM. No probabilistic guessing. No hallucination at audit time. We never store your source code. We cannot alter receipts after issuance, including ourselves. And your evidence verifies offline forever — independent of whether Déjà continues to exist. Verifiable by audit firms — firms such as KPMG, Deloitte, EY, PwC, BDO, Grant Thornton, or independent.

This page documents our security posture. For the SOC 2 Type II report (in preparation, targeted Q3 2026), pen test summary, DPA, and architecture documentation, request via security review.

POSTURE AT A GLANCE
last review: Apr 2026
SOC 2 Type IIAmerican Institute of CPAs
In progress · Q3 2026
ISO 27001International Organization for Standardization
Planned 2027
GDPR + CCPAEU + California data protection
Compliant
Encryption at restAES-256 · managed via AWS KMS
AES-256
Encryption in transitTLS 1.3 · all internal + external traffic
TLS 1.3
SubprocessorsFull list disclosed on this page
7 total
Reported security incidentsLifetime of the company
Zero
ARCHITECTURE · ZERO-RETENTION

We never store your source code.

Déjà reads transient webhook payloads at merge time and incident time. We extract symbolic fingerprints and causal relationships — then discard the underlying source content. If an attacker compromised Déjà's infrastructure tomorrow, they could not reconstruct your codebase because the underlying code was never persisted.
model: zero_retention_v1
YOUR INFRASTRUCTURESource codeGitHub / GitLab repoMerged PR diffwebhook payloadIncident signalSentry / Datadog webhookHTTPSDÉJÀ · TRANSIENT PROCESSINGAST parser · symbolic fingerprint extractionin-memory for most flows · retry/DLQ + pending-signature queues briefly persistSchema Deduction Engine · W1–W8 scoringcausal attribution only · no code retentionDiff content · discarded after extractionzero persistence · never written to storagePERSISTED EVIDENCE (YOUR VAULT)Fingerprint hash (SHA-256)identifies incident · not the codeCausal PR reference (PR number + commit SHA)metadata pointer · not the diffConfidence score + decision auditW1–W8 attribution reasoningSigned receipt (DSR/1.0 · Ed25519)
WHAT DÉJÀ TOUCHES
  • Transient webhook payloads — at merge time and incident time, processed in-memory for most flows; retry/DLQ and pending-signature queues may briefly persist data
  • Error stack traces + exception signatures — extracted from incident signals
  • PR metadata — author, merge time, commit SHA (references only, no diff content)
WHAT DÉJÀ NEVER STORES
  • Source code — your repository is never cloned, mirrored, or persistently stored
  • Diff content — merged PR diffs are analyzed in-memory, then discarded
  • Runtime data — production logs, database contents, customer PII, API payloads
  • Historical repo contents — we do not backfill against your repository history
CRYPTOGRAPHIC EVIDENCE · DSR/1.0

Receipts that can't be altered after issuance.

Every signed receipt carries an Ed25519 signature computed at issuance over the JCS-canonical payload (RFC 8785). No party can modify the receipt after issuance — including Déjà. Auditors verify receipts offline using our open-source dsr-verifier-cli — no Déjà account required.
spec: DSR/1.0
SIGNED_RECEIPT / DSR 1.0// Canonical DSR/1.0 receipt (abbreviated)
{
  "receipt_id": "rcpt_8f2c91ae7b3d",
  "spec": "DSR/1.0",
  "issued_at": "2026-04-24T18:22:47.031Z",
  "vault_id": "vault_payments_core",
  "incident": {
    "fingerprint": "sha256:a41b...c92d",
    "signal_source": "sentry",
    "first_seen": "2026-04-24T18:22:17Z"
  },
  "attribution": {
    "causal_pr": "PR-4521",
    "commit_sha": "f3a2b91",
    "confidence_score": 0.94,
    "classification": "HIGH_CONFIDENCE_DEDUCTION",
    "reasoning_weights": {
      "w1_fieldOverlap": 0.98,
      "w2_temporalProximity": 0.91,
      "w3_blastRadius": 0.89,
      "w4_errorTypeMatch": 1.00,
      "w5_authorHistory": 0.80,
      "w6_zoneBoundary": 1.00,
      "w7_producerGraphDistance": 0.60,
      "w8_schemaStability": 0.92
    }
  },
  "signature": {
    "algo": "ed25519-v1",
    "value": "7fBxK2mP4nQ8vR3eL6jF1wCytY0hG9dN8kM2pX4bV7zA3rE6qJ1iU5oH0fT8cS9aB3rKwNpDqME1u+Cz4XvQRs==",
    "fields_signed": ["receipt_id", "issued_at",
                       "vault_id", "incident",
                       "attribution"]
  }
}
PROPERTY 1
Signature set at issuance

The Ed25519 signature is computed over the JCS-canonical payload (RFC 8785) at the exact moment the receipt is issued. Modifying any signed field invalidates the signature — including changes made by Déjà's operators.

PROPERTY 2
Offline verification by your audit firm

Your audit firm — firms such as KPMG, Deloitte, EY, PwC, BDO, Grant Thornton, or independent — verifies receipts with dsr-verifier-cli, an Apache-2.0 open-source tool that runs locally on their machine, requires no Déjà account, and verifies the signature against the canonical DSR/1.0 specification.

PROPERTY 3
Déjà-independence

If Déjà's service disappeared tomorrow, your receipts would still verify. The verifier is offline and open. Evidence durability is architectural, not contractual.

PROPERTY 4
Append-only ledger

Receipts are written to an append-only ledger per vault. Prior receipts chain to subsequent ones via fingerprint references — producing a tamper-evident chain of custody across all incidents in a vault.

DATA HANDLING · COMMITMENTS

How your data is handled.

Six explicit commitments covering retention, residency, isolation, encryption, deletion, and export. These are contractual — not aspirational.
commitments: 6
VAULT ISOLATION

Every customer has an isolated vault.

Each vault has its own chain of custody, its own signing keys, and its own tenant boundary. Cross-tenant data access is enforced at two independent layers: PostgreSQL Row-Level Security at the database engine (active for every customer-facing query) and application-layer org membership validation. A query missing an org predicate is rejected by the database before it reaches the application.

architecture: per-tenant cryptographic isolation
ENCRYPTION

AES-256 at rest, TLS 1.3 in transit.

Encryption keys are managed via AWS KMS with automatic rotation. TLS 1.3 for all traffic — internal service-to-service, external webhook ingestion, and customer-facing APIs.

at rest: AES-256 in transit: TLS 1.3
DATA RESIDENCY

US live. EU + APAC coming H2 2026.

Default region is us-east-1 (AWS). Enterprise and Sovereign tiers will support dedicated EU (Frankfurt) or APAC (Sydney) deployment with no cross-region data replication — available H2 2026. US residency is live on all tiers today.

regions: US (EU/APAC H2 2026)
RETENTION

You own when data leaves.

Standard tier: 5-year retention. Enterprise: custom (common: 7 years for financial services). Sovereign: multi-decade. Deletion on cancellation happens within 90 days after export window closes — verifiable via deletion certificate.

tiers: 2yr · 5yr · custom · multi-decade
EXPORT

Portable, forever verifiable.

Export your full receipt ledger at any time as a portable JSON + PDF bundle. Bundle verifies offline via dsr-verifier-cli. No proprietary format, no vendor dependency. If Déjà ceases operations, you retain verifiable evidence indefinitely.

format: JSON + PDF · DSR/1.0 portable
DELETION

Verifiable data destruction.

Deletion requests complete within 30 days (GDPR-compliant). Destruction is cryptographic — encryption keys are destroyed, rendering data unreadable. Receipt of destruction certificate issued on completion. Subprocessors are notified simultaneously.

sla: 30 days method: cryptographic erasure
ACCESS & INCIDENT RESPONSE

Who can reach your data — and what we do if something goes wrong.

ACCESS CONTROLS

Authentication and least-privilege access.

  • SSO / SAML 2.0 — included on Charter, Standard, Enterprise, and Sovereign tiers. Okta, Azure AD, Google Workspace, Auth0.
  • Multi-factor authentication — required on all paid-tier admin accounts. WebAuthn (hardware keys supported via WebAuthn), TOTP supported.
  • Role separation — admins manage vault configuration; auditors have read-only access; engineers receive notifications but never authenticate to Déjà.
  • Audit logging — every admin and auditor action generates a log entry. Logs are append-only, immutable, and exportable for SOC 2 / ISO 27001 evidence.
  • Staff access — Déjà employees cannot access customer vaults without explicit time-boxed, audit-logged customer approval via the support-access workflow.
  • Session management — configurable session timeout (default 8 hours), explicit re-authentication for sensitive operations.
INCIDENT RESPONSE

What happens if something goes wrong.

  • Breach notification SLA: 72 hours — per GDPR Article 33. Affected customers are notified first, then regulators as required.
  • On-call security rotation — 24/7 security incident response. PagerDuty escalation for all severity-1 and severity-2 events.
  • Documented runbooks — for credential compromise, data exposure, vendor breach, DDoS, and ransomware. Tested quarterly via tabletop exercises.
  • Post-incident disclosure — public transparency report issued within 30 days of resolution. Status page + incident history →
  • Lifetime incident count: zero — no reported security incidents involving customer data as of April 2026. This page will be updated in real time if that ever changes.
  • Responsible disclosure — security@deja.app for researchers. We acknowledge within 48 hours, work in good faith, and publicly credit reporters.
CERTIFICATIONS · HONEST STATUS

Where we are, where we're going.

Déjà is a deliberate security-first company but we are early. This is the honest current state of our certifications — no weasel-words, no "SOC 2 ready," no aspirational claims. For pre-certification customers, our commitments above are contractual.
last audit: Mar 2026
SOC 2 Type II
American Institute of CPAs · Security, Availability, Confidentiality trust criteria
In progress · Q3 2026
ISO 27001
International Organization for Standardization · Information security management
Planned 2027
GDPR
European Union General Data Protection Regulation
Compliant
CCPA
California Consumer Privacy Act
Compliant
HIPAA
Health Insurance Portability & Accountability Act · Business Associate Agreement available on Enterprise
BAA available · Enterprise
PCI-DSS
Payment Card Industry Data Security Standard · Déjà does not process payment data
N/A · no cardholder data
FedRAMP
US Federal Risk and Authorization Management Program · for federal government customers
Planned 2028 · Sovereign
Penetration testing
Annual third-party pen test · summary available on request under NDA
Annual · NDA
SUBPROCESSORS · FULL DISCLOSURE

Every vendor that could see your data.

Full subprocessor disclosure. Customers are notified at least 30 days before any new subprocessor is added. Material changes can be objected to in writing — we negotiate alternate arrangements for customers who cannot accept a new subprocessor.
subprocessors: 7
Amazon Web Services
Cloud infrastructure · compute, storage, networking, KMS
US (EU/APAC H2 2026)
Yes · encrypted
Supabase
Managed PostgreSQL · vault and receipt storage
US / EU
Yes · encrypted
Vercel
Application hosting · web UI and API serving
Global edge
Ephemeral only
Stripe
Billing and payment processing
US / EU
Billing only
Resend
Transactional email · notifications and receipt delivery
US
Email only
Datadog
Signal ingestion monitoring · processes incident signal data
US / EU
Yes · signal data
PagerDuty
Internal security incident paging · Déjà-internal use only
US
No customer data
FOR REGULATED INDUSTRIES

Additional posture for financial services, healthcare, and government.

Enterprise and Sovereign tiers support FFIEC guidance alignment (US financial services), HIPAA Business Associate Agreements (healthcare), SOX control mapping, and ISO 27701 privacy controls. Regulatory integrations (direct reporting to central banks, for example) are negotiated under Sovereign tier engagements.

Regulatory review
ARTIFACTS · DOCUMENTATION

Request what your security team needs.

Some artifacts are public. Others are NDA-gated because they contain architectural detail we don't publish openly for competitive and security reasons. All are available through a single security review conversation.
DSR/1.0 specificationOpen-source receipt format · Apache-2.0
Public
dsr-verifier-cliOffline receipt verification tool · Apache-2.0 · pre-release · public release Q3 2026
Pre-release
Privacy PolicyGDPR + CCPA compliant
Public
Subprocessor listListed on this page · 30-day notice on changes
Public
SOC 2 Type II report (in preparation)Targeted Q3 2026 · under NDA · audit not yet complete
NDA · Q3 2026
Penetration test summaryAnnual third-party pen test · under NDA
NDA
Data Processing Agreement (DPA)GDPR Article 28 compliant · standard template
On request
Architecture documentationDetailed system diagrams · under NDA
NDA
09 / WHY THE ARCHITECTURE MATTERS FOR SECURITY

Deterministic by construction. Verifiable by anyone.

The security architecture isn't separate from the product architecture — it is the product architecture. Every property a CISO or audit-firm technologist verifies on this page maps directly to a property of the receipt itself: deterministic mechanism, immutable storage, independent verification. The receipt is the security model.
layer: cryptographic_substrate
PROOF OF MECHANISM · WHY DETERMINISTIC = BETTER SECURITY

Déjà is not an LLM wrapper. It is a deterministic engine performing raw Abstract Syntax Tree (AST) analysis on every code change. The engine produces a Causal Confidence Score (CCS) from eight weighted scoring factors (W1–W8), then issues an Ed25519-signed receipt. No probabilistic guessing. No hallucination at audit time. No "AI that might be right." A CISO building an audit defense cannot risk evidence that depends on a probabilistic model — when the auditor asks "why was this attribution chosen over an alternative?", the answer must be reproducible math, not a confidence interval. Triggered via background webhook interception — payloads authenticated via HMAC-SHA256 signature verification.

FOR THE ENGINEER · ZERO-FRICTION
  • Zero-click compliance — receipts auto-generate; no engineer tickets at audit time
  • Background webhook interception — silent on the merge event, HMAC-SHA256 authenticated
  • No manual screenshotting of Jira tickets or Slack threads
  • No source code stored by Déjà — diffs only, transient, then cryptographic fingerprints
FOR THE AUDITOR · INSTANT VERIFICATION
  • Live Verifier via dsr-verifier-cli — Apache-2.0 open source (pre-release · public release Q3 2026)
  • Independent Ed25519 signature verification, offline, no network call to Déjà
  • No Déjà account required to verify a receipt
  • No source code access required — auditors verify attribution, not the codebase
VS. MANUAL EVIDENCE GATHERING · CISO BUDGET FRAMING

The CISO's audit-defense problem is structural: manual evidence reconstruction creates audit findings. Based on Déjà's conversations with regulated-firm engineering teams, audit prep can consume multiple FTE-weeks per cycle reassembling what nobody captured at the time — searching Slack for incident context, screenshotting Jira tickets, copying deployment logs into spreadsheets. The output is unsigned, unverifiable, and reconstructed under deadline pressure. That output is what produces the audit-finding category of "evidence reconstruction was manual" — the finding the CISO has been carrying for three years running. Déjà eliminates the category at the architectural layer: signed at attribution, immutable thereafter, verifiable independently.

METRIC 1 · ENGINEERING HOURS SAVED
Engineering time previously spent reconstructing evidence at audit cycles is reclaimed for product work — every cycle, automatically.
METRIC 2 · AUDIT RISK REDUCED
Cryptographically verifiable, tamper-evident receipts eliminate the audit-finding category of "evidence reconstruction was manual."
ZERO-TRUST RECEIPT VERIFICATION · ARCHITECTURAL PRINCIPLE

Receipts are independently verifiable. No implicit trust required between Déjà, the customer, or the audit firm.

The signature is the contract. The verifier is the proof. The append-only ledger is the chain. Even if Déjà were compromised, exfiltrated, or shut down, your receipts continue to verify — because the verification logic lives in your audit firm's own copy of dsr-verifier-cli, running offline against the receipts you already hold. Zero implicit trust. Zero vendor dependency. Zero reliance on Déjà's continued existence. This is the property that defines audit-defensible evidence — and the property no other compliance category preserves. Trust nobody. Verify everything.

Security is our product.

Déjà's job is to produce cryptographically signed audit evidence for regulated industries. If our own posture couldn't withstand the same scrutiny, our product wouldn't be worth shipping. Your security team's questions deserve direct answers — not sales theater.

> posture: zero_retention // receipts: tamper_evident // verifier: offline_independent