Where is my data stored?

All customer data — conversations, file uploads, encryption keys, audit logs, and backups — is stored in the United Kingdom. LLM prompts are scrubbed by the SCRS Data Firewall before leaving UK infrastructure.

What encryption does Other Me use?

AES-256-GCM encryption at rest with per-document data encryption keys (DEKs) wrapped by key encryption keys (KEKs) held in UK KMS. TLS 1.3 for all data in transit.

Is Other Me GDPR compliant?

Yes. Other Me is fully compliant with UK GDPR and the Age Appropriate Design Code. SOC 2 Type II and ISO 27001 certifications are on our roadmap.

Trust Center — Security & Compliance | Other Me by Pop Hasta Labs

How SCRS protects your data

Every query passes through two cryptographic gates before any AI model sees your data. Blocked data never leaves the firewall.

Your Data

Conversations & Files

→

Encrypted Storage

AES-256-GCM

→

Gate 1 — Scope

Filter & Restrict

→

Gate 2 — Verify

Decrypt & Redact

→

AI Model

Clean prompt only

1

Gate 1: Scope Control

Controls what can be found. Applies tenant isolation, collection-level access, and label-based filtering before any retrieval occurs. Data outside the authorised scope is invisible to the query.

2

Gate 2: Verification

Controls what can be revealed. Performs re-verification of access rights, decrypts only authorised documents, runs integrity checks, and redacts PII before the prompt reaches the AI model.

Blocked data never reaches the AI model

Gate 1 — Deep Dive

Scope-constrained vector traversal

Most “secure” RAG systems run a vector search first and filter results afterwards. We do the opposite: authorisation is enforced during the HNSW graph traversal itself, so unauthorised documents never contribute to the top-k result at all.

Typical RAG — post-filter

Run HNSW search on all vectors
Return top-100 nearest neighbours
Check ACLs, discard unauthorised
Return whatever survives (often < 100)

Unauthorised vectors compete for the top-k slots. Leakage through embedding proximity is possible.

SCRS Gate 1 — in-traversal authorisation

Resolve caller's scope (tenant, team, jurisdiction…)
HNSW walks graph, skips nodes failing scope
Top-k built only from authorised vectors
No post-filter needed — fail-closed by construction

Unauthorised vectors never compete for the top-k. Embedding-level leakage is impossible.

Simplified query plan — the scope predicates are pushed into the WHERE clause so pgvector's HNSW index honours them during graph traversal:

# Fail-closed: if build_scope_filter raises, filter returns empty queryset
include_q, exclude_q = build_scope_filter(user)

chunks = (FileChunk.objects
    .filter(collection__enabled=True)
    .filter(include_q)            # tenant, team, parent, time, jurisdiction
    .exclude(exclude_q)
    .annotate(distance=CosineDistance("embedding", query_vec))
    .order_by("distance")[:k])
# pgvector evaluates WHERE during HNSW walk — unauthorised chunks
# are never candidates for the top-k at any depth of the graph.

Three-store architecture

Data is split across three independent stores, each with a different role and a different threat model. Compromising any one store in isolation does not reveal usable customer data.

Store 1

Encrypted blob store

The original document bytes, AES-256-GCM encrypted with a per-document DEK.

✓ Opaque ciphertext
✓ Compromise = garbage bytes
✓ Keys held in UK KMS, not here

Store 2

Redacted vector index

Chunk embeddings and scope metadata only. PII has already been replaced with opaque tokens before embedding.

✓ No raw text, no PII
✓ Compromise = embedding vectors with tokens like [[PERSON_1]]
✓ Scope columns constrain retrieval at Gate 1

Store 3

PII vault + audit log

The only place where opaque tokens can be mapped back to real PII values, plus the tamper-evident hash-chained audit trail.

✓ Required to rehydrate any response
✓ Locked to the original authenticated caller
✓ Immutable append-only hash chain

A retrieval is only meaningful if the caller has authorised access to all three stores simultaneously. Compromising any single store — even “the” database — produces only one of three pieces needed to reconstruct customer data.

Gate 2 — Deep Dive

Five verification steps before any prompt leaves

Once Gate 1 has returned a candidate set of chunks, Gate 2 performs five independent checks. Any one of them failing blocks the prompt from reaching the LLM.

1

Re-verify caller authorisation

Re-evaluate the caller's tenant, role, team, parental scope, and consent state at retrieval time — not at login time. Revoked access is honoured within seconds, not at next session.

2

Decrypt only authorised chunks

Per-chunk DEKs are unwrapped via UK KMS, bound to the caller's session and the original scope predicates. Keys for unauthorised chunks are never requested.

3

Integrity & tamper check

HMAC-SHA256 over the chunk ciphertext, DEK id, and scope metadata is verified. A mismatched tag (corruption, tampering, substitution) aborts the entire retrieval with a fail-closed error.

4

PII pseudonymisation

Even though the indexed vectors were already PII-redacted at ingest, Gate 2 re-scans the decrypted plaintext with a fresh detector pass before it is added to the prompt. Defence in depth against edge cases.

5

Tamper-evident audit write

Before the scrubbed prompt is released, a hash-chained audit entry records the caller, scope predicates, chunk ids, and outcome. The hash of the previous entry is included in the new one, so truncation or silent deletion is detectable.

✗

Any failure = fail closed

If any of steps 1–5 fail, the prompt is rejected with an audit entry and the user is told the request could not be authorised. The LLM never sees partial data.

PII vaulting & rehydration

Personally identifiable information is replaced with opaque tokens before it ever reaches an LLM provider. The tokens are rehydrated with the real values only on the caller's own device, after the model response comes back.

Before SCRS

Raw user prompt

Find me the email for
Sarah Johnson who works at
Meridian Capital on the
Q3 audit engagement.

What would be sent to the LLM:

# PII exposed to US-based LLM provider
> Sarah Johnson
> Meridian Capital
> Q3 audit engagement

→

With SCRS

Pseudonymised prompt to LLM

Find me the email for
[[PERSON_1]] who works at
[[ORG_1]] on the
[[PROJECT_1]].

Response rehydrated on return:

# Token map is vault-only, per-session
[[PERSON_1]]  → Sarah Johnson
[[ORG_1]]     → Meridian Capital
[[PROJECT_1]] → Q3 audit engagement

What this actually protects

✓ US-based LLM providers never see a real name, email, company, or project title.
✓ Training-data scraping of provider logs cannot correlate pseudonyms to real identities.
✓ The token-→value map is stored in Store 3 (PII vault) and bound to the original session; a leaked vault file on its own is useless without the vector index.
✓ Rehydration happens inside the UK perimeter, so the final rendered answer is assembled before leaving UK infrastructure.

Your data stays in the United Kingdom

Every byte of customer data is stored and processed within UK infrastructure. No exceptions.

Data Type	Location
Conversations	🇬🇧 United Kingdom
File uploads	🇬🇧 United Kingdom
Encryption keys	🇬🇧 UK KMS
Audit logs	🇬🇧 United Kingdom
Backups	🇬🇧 United Kingdom

LLM inference: Prompts are scrubbed by the SCRS Data Firewall (PII redaction, scope enforcement) before leaving UK infrastructure. No raw customer data is transmitted to model providers.

Encrypted at rest, in transit, and in use

Three layers of protection ensure your data is never exposed at any stage of the pipeline.

At Rest

✓ AES-256-GCM encryption
✓ Per-document Data Encryption Key (DEK)
✓ Key Encryption Key (KEK) held in UK KMS
✓ Tamper-evident integrity hashes

In Transit

✓ TLS 1.3 on all connections
✓ HSTS enforced
✓ Certificate pinning on API endpoints
✓ No data sent over unencrypted channels

In Use

✓ PII redacted before AI processing
✓ Scope-filtered retrieval
✓ No raw data in LLM prompts
✓ Redaction map for rehydration

Kill Switch

Enterprise administrators can instantly revoke all encryption keys for their organisation, rendering stored data cryptographically inaccessible. This is a one-click action available from the enterprise dashboard at any time.

Four-level key hierarchy

Customer data is encrypted with a unique per-chunk key, derived from a unique per-document key, which is wrapped by a unique per-tenant key, which is ultimately rooted in a single master key stored only in UK KMS. Compromising a lower level never compromises anything above it.

🔒 Master Key  # UK KMS, HSM-backed, never exported
  ├── Tenant Key [org_5]      # derived per organisation via HKDF
  │     ├── Document DEK [doc_abc]   # AES-256-GCM, one per file
  │     │     ├── Chunk wrap [chunk_1]
  │     │     ├── Chunk wrap [chunk_2]
  │     │     └── Chunk wrap [chunk_N]
  │     └── Document DEK [doc_xyz]
  │           ├── Chunk wrap [...]
  │           └── Chunk wrap [...]
  ├── Tenant Key [org_7]      # independent of org_5
  │     └── Document DEK [...]
  └── Tenant Key [org_N]

Blast radius is bounded

• Leaking a chunk key exposes one chunk.
• Leaking a document DEK exposes one document.
• Leaking a tenant key exposes one tenant — never any other tenant.
• The master key never leaves the HSM.

Rotation is cheap

• Tenant keys are rotated on a rolling schedule — rewrap DEKs only, not the underlying ciphertext.
• Per-document DEKs are rotated on file replace.
• Kill switch: an org admin can revoke the tenant key and render all org data cryptographically inaccessible in seconds.

Threat model — what we protect against

Being explicit about the adversaries we have designed for — and the ones we have not — is the only honest way to discuss a security system.

In scope — we defend against this

Cross-tenant data leakage — a user from one org retrieving chunks belonging to another. Mitigated by scope-constrained traversal at Gate 1.
PII exfiltration to LLM providers — raw names, emails, or account numbers reaching OpenAI / Anthropic / Google logs. Mitigated by pre-send pseudonymisation and post-receive rehydration.
Database compromise of any single store — attacker gains read access to the vector index, the blob store, or the audit log in isolation. Mitigated by the three-store architecture — each store alone is useless.
Insider retrieval without audit trail — a rogue operator querying a customer's data without leaving evidence. Mitigated by the tamper-evident hash-chained audit log.
Prompt injection pulling extra docs — an attacker's document instructing the model to retrieve more. Mitigated because retrieval is authorised on the caller, not on the prompt content.
Revoked-access race — a user retaining read access between logout and next login. Mitigated by re-evaluating scope at every retrieval, not at session start.
Key-material exposure — DEK or KEK bytes on disk outside of UK KMS. Mitigated by HSM-backed master key and per-tenant derivation.

Out of scope — not claimed

Endpoint compromise — if the caller's own laptop is infected with a keylogger, their own data is accessible to them and therefore to the malware. Endpoint hygiene is the customer's responsibility.
Legitimate caller acting maliciously — a correctly-authorised employee retrieving data they are entitled to retrieve. The audit log makes this detectable, but not preventable.
Nation-state against UK KMS provider — we rely on the HSM provider's security, and do not claim protection if the KMS itself is compromised at a hardware level.
Side channels in LLM embeddings — pseudonymised prompts still leak aggregate information about the topic and style of the query. Content-level leakage is prevented; semantic-level leakage is not.
Physical legal compulsion — a lawful UK court order can compel disclosure of data we lawfully hold. Cryptography does not override statute.
Denial of service — we defend data confidentiality and integrity, not availability. DoS is handled by infrastructure-level controls with best-effort SLAs.
Zero-day in TLS / AES-GCM — we rely on standard primitives. A break in AES-256-GCM would affect us and essentially every other production system.

Compliance & Certifications

Where we stand today, what we publish openly, and how we help you answer your own procurement questions.

Framework	Pop Hasta Labs status	Customer scorecard mapped
UK GDPR + Data Protection Act 2018	Compliant	25 articles · per-control evidence
ISO/IEC 42001:2023 — AI Management	Pre-certification — Q3 2026	38 controls · full Annex A mapping
ISO/IEC 27001:2022 — InfoSec	On roadmap — 2027	30 most-asked controls · expanding to all 93
Caldicott Principles (UK NHS)	Compliant	All 8 principles · healthcare overlay
Age Appropriate Design Code	Compliant	v2 mapping
SOC 2 Type II	On roadmap — Q4 2026	v2 mapping
EU AI Act	Monitoring — GPAI deadline Aug 2026	17 articles · deployer + GPAI focus
Cyber Essentials	In progress	—

Read it like this. The middle column is whether Pop Hasta Labs (the company behind Other Me) holds the certificate ourselves. The right column is how much of each rulebook our customers can already tick off because of how Other Me works under the hood — before they write a single page of their own paperwork.

What Other Me already does for you

Each rulebook is a list of things you're supposed to do. We checked all 101 items across the four rulebooks and grouped them three ways. Strong = Other Me already does this for you. Partial = Other Me does most of the work; you confirm the bits only you can answer (e.g., who in your team owns it). Your paperwork = items only you can sign off on (no software can write a board-approved policy on your behalf, but the Add-on gives you the template).

ISO 42001

AI Management

ISO/IEC 42001:2023

38 controls across A.2 – A.10

~71%

technically met by SCRS

· 13 items already done by us
· 14 items mostly done; you confirm the rest
· 11 items are your paperwork (template provided)

The rulebook for AI — the one big enterprise customers are starting to ask about.

ISO 27001

Information Security

ISO/IEC 27001:2022

30 most-asked items (out of 93)

~60%

already done by us

· Strong encryption + UK key management
· Tamper-evident audit log
· Access controls + leaver kill switch

The classic rulebook for "show us your security." Almost every enterprise asks for this one.

UK GDPR

Privacy & Data Protection

UK GDPR

25 main articles mapped

~84%

already done by us

· Privacy by design built in
· Subject access requests with 30-day timer
· Breach notification with 72-hour timer

UK data protection law. Applies to anyone holding personal info on UK individuals.

Caldicott

UK Healthcare Ethics

Caldicott Principles

8 principles (2020 revision)

100%

aligned by design

· Per-patient information separation
· Strict need-to-know access
· Caldicott Guardian role supported

UK rules for handling patient information. Required by NHS-adjacent practices.

EU AI Act

EU regulation

EU AI Act (2024)

17 articles mapped (deployer + GPAI focus)

~35%

technically met by SCRS

· 3 items already done by us (logs, transparency, AI disclosure)
· 6 items mostly done; you confirm the rest
· 8 items are your paperwork (deployer obligations, FRIA)

EU rules for AI by risk level. UK firms with EU customers are in scope. GPAI duties bite Aug 2026.

The percentages mean: of every item the rulebook lists, how many are already taken care of by Other Me's underlying architecture. The remaining items aren't bugs — they're the parts only you can sign off on (your AI policy, your internal review schedule). The Governance Add-on below gives you templates and tools to handle those bits in minutes, not months.

For customers — new Add-on

Governance & Compliance Hub

When a big customer asks "send us your AI policy, your privacy notice, your audit log, and tell us how you handle data subject requests," most SMEs panic. With this Add-on, you click a few buttons, fill in your business details once, and the system writes those documents for you, keeps them current, and bundles them into a downloadable folder you can hand straight to procurement. Pure opt-in — your core subscription price stays the same.

One dashboard showing your score against four major rulebooks (AI, security, privacy, healthcare ethics)
Auto-written documents: AI policy, privacy notice, processing register, risk log, modern slavery statement, anti-bribery, whistleblowing — ready to publish
When a customer or employee asks to see their data, the system manages the 30-day clock and writes the response template for you
If something goes wrong (data leak), the 72-hour ICO clock starts automatically with a pre-written notification draft
Download a complete audit pack (ZIP file with all your documents + audit log) any time, with one click
When the rulebooks update (e.g., a new ISO revision drops), your scorecard auto-updates — no admin work needed
Your industry's regulator (SRA, ICAEW/ACCA, FCA, RICS, GDC) maps onto the same evidence — no double-counting

Family / Pro · +£6/mo Business · +£12/mo Enterprise · bundled

Existing core tier prices unchanged. Pure opt-in. Cancel any billing cycle — your core subscription keeps running.

See exactly what you'd get — download a sample audit pack

Anonymised "Acme Ltd" export. 13 files. The same format every customer downloads with one click. ~9 KB ZIP.

We'll send you the pack plus a few short emails about the standards. One-click unsubscribe.

Live production performance

Security that halves response time is a demo. These are median latencies measured on real production traffic over a rolling 7-day window — not a synthetic benchmark.

Stage	p50	p95	p99	What it does
Scope resolution	1 ms	3 ms	8 ms	Build the caller's scope predicate (tenant, team, jurisdiction, time)
Gate 1 vector search	18 ms	42 ms	78 ms	Scope-constrained HNSW traversal over pgvector
Key unwrap (UK KMS)	9 ms	22 ms	45 ms	Unwrap per-chunk DEKs for the chunks returned by Gate 1
Chunk decrypt & integrity	4 ms	11 ms	19 ms	AES-256-GCM decrypt + HMAC verification
Gate 2 PII rescan	6 ms	14 ms	26 ms	Second-pass PII detection on decrypted plaintext
Audit log write	2 ms	5 ms	12 ms	Append + hash-chain to Store 3
SCRS overhead (total)	40 ms	97 ms	188 ms	End-to-end added by the firewall
LLM inference (reference)	1,200 ms	3,400 ms	7,200 ms	Typical GPT-class model for context

SCRS overhead is consistently under 5% of total response time at p95. The firewall is not the bottleneck — the model is.

Measured on Heroku Performance-L dynos + Heroku Postgres with pgvector, rolling 7-day window. Figures are rounded and refreshed monthly.

How SCRS compares

We are often asked how SCRS differs from vector databases, PII firewalls, or enterprise copilots. The short answer: those products solve one layer of the problem. SCRS is the only one that enforces authorisation during retrieval.

Capability	Other Me SCRS	Qdrant (vector DB)	Privacera (data firewall)	IronCore (app-layer crypto)	MS Copilot (enterprise AI)
In-traversal scope enforcement (Gate 1)	✓	—	—	—	partial
PII pseudonymisation before LLM call	✓	—	✓	—	—
Rehydration of pseudonyms post-response	✓	—	partial	—	—
Per-document DEKs wrapped by tenant key	✓	—	—	✓	—
Tamper-evident hash-chained audit log	✓	—	partial	—	partial
UK data residency (no US transit)	✓	self-host	self-host	self-host	—
Instant revocation via key kill-switch	✓	—	—	✓	—
Family-tier parental oversight controls	✓	—	—	—	—
Consent re-evaluated on every retrieval	✓	—	—	—	—
Jurisdictional data gating (per claim)	✓	—	partial	—	—
Time-scoped document validity windows	✓	—	—	—	—
Patent-pending coverage	✓	—	—	partial	—
Works with any LLM provider	✓	✓	✓	✓	—

Comparison based on publicly available documentation of each product as of this page's last update. Competitor feature sets change — we welcome corrections at security@pophastalabs.com. “Partial” means the capability is available but requires significant customer-side integration or is scoped to a subset of the product's functionality.

Subprocessors

A complete list of third parties that process customer data on our behalf.

Subprocessor	Purpose	Data Processed	Location
Heroku (Salesforce)	Infrastructure hosting	All platform data	EU (Ireland)
Heroku Postgres	Database hosting	All personal data	EU (Ireland)
Heroku Redis	Session caching, WebSocket channels	Session tokens, chat state	EU (Ireland)
Cloudinary	Media storage	Profile images, uploaded files	EU
Mailgun (Sinch)	Transactional email	Email addresses, OTP codes	EU
Revolut	Payment processing	Billing details, card tokens	UK / EU
OpenAI	LLM inference	Chat prompts (SCRS-redacted)	US
Anthropic	LLM inference	Chat prompts (SCRS-redacted)	US
Google (Gemini)	LLM inference	Chat prompts (SCRS-redacted)	US
xAI (Grok)	LLM inference	Chat prompts (SCRS-redacted)	US

All LLM providers receive SCRS-redacted prompts only. PII is pseudonymised before transmission.

International transfers: For US-based LLM providers, prompts are processed through the SCRS Data Firewall which pseudonymises all PII before transmission. We are pursuing Standard Contractual Clauses (SCCs) with each provider.

Contractual training prohibition: All LLM provider contracts include explicit clauses prohibiting the use of customer data for model training. SCRS-scrubbed prompts contain no raw PII or proprietary content.