Security that starts with architecture.
Compliance posture follows from product design. StandIn only processes what people explicitly write and choose to publish. No background syncs. No behavioral signals. No inferred data. Below is how that shape maps to GDPR, storage, access, and incident response.
Data minimization, by construction.
Most tools ask you to configure privacy through controls layered on top of collection. StandIn collects less in the first place. The LLM has no direct access to your systems. It receives a narrow, already-published context window at query time — and that context is discarded when the response returns.
What data does StandIn process?
StandIn processes three classes of data, and only these.
- Wraps, declarations, and handoffs users explicitly author and publish
- Read-only metadata from connected systems (issue titles, status, assignees, URLs) — within allowlists you configure
- Account identifiers required for attribution, access control, and audit
- Message bodies, DMs, email contents — never ingested
- Keystroke telemetry, screen activity, cursor tracking — none captured
- Inferred sentiment, productivity scores, or attention metrics — not computed
- Source code bodies — only PR/commit metadata from allowlisted repos
- Anything a user has not explicitly written or a connection has not explicitly exposed
If it was not intentionally written or explicitly connected, StandIn does not see it.
How is StandIn GDPR-compliant?
StandIn operates as a data processor. The customer org is the controller. DPAs with Standard Contractual Clauses are available on request.
- —Right of access — users can export their wraps and declarations at any time
- —Right to rectification — users can edit or revise published records
- —Right to erasure — admins can delete user data on request, within 30 days
- —Right to portability — full JSON export via API or admin dashboard
- —Lawful basis: contract (service delivery) and legitimate interest (org continuity), not consent theater
- —Purpose limitation: data used only for declared purposes — wrap delivery, retrieval, audit
- —Data minimization: see question 01
- —Storage limitation: retention configurable per org, default 24 months for published wraps
- —Integrity and confidentiality: encryption at rest and in transit, strict access controls
GDPR compliance is not a bolt-on. It is a consequence of only collecting what users choose to publish.
Where is data stored?
- —Postgres (Supabase) — primary data store with row-level isolation per org
- —Object storage (S3-compatible) — artifact attachments, encrypted at rest with AES-256
- —LLM provider — Anthropic (no training on customer data, zero-retention endpoints used)
- —Secrets — managed via Vercel encrypted environment, rotated quarterly
- —EU-hosted region available for pilot and enterprise customers (eu-central-1)
- —No transatlantic data transfer for EU-hosted orgs — LLM calls routed to EU endpoints
- —SCCs and Transfer Impact Assessments available for US-hosted orgs processing EU data
EU residency is a configuration, not an upgrade tier. Ask during onboarding.
What are the default access controls?
Nothing is visible to anyone outside an org by default. Within an org, access follows membership and role.
- —Org-scoped by default — no cross-tenant reads are possible at the row level
- —Three roles: admin, member, viewer — each with progressively narrower write scope
- —SSO/SAML available on pilot and enterprise plans
- —Audit log records every read of another user's wrap, every config change, every invite
The system assumes nothing about who should see what. You configure it explicitly.
What does StandIn do with your data?
We do three things with your data. We do not do a long list of other things.
- Retrieve it when one of your teammates asks a representative a question
- Store it encrypted at rest with per-org isolation
- Show it back to you and your team through the product surfaces
- Train any model — ours or third-party — on customer data
- Sell, syndicate, or share data with advertisers or data brokers
- Compute productivity scores, engagement metrics, or manager-facing surveillance
- Share one org's data with another org under any circumstance
- Retain LLM call bodies beyond the zero-retention inference call itself
If we did any of the items in the second list, a reasonable customer would leave. So we do not do them.
How does the LLM interact with your data?
The LLM does not have open access to your systems. It sees a narrow context, then it sees nothing.
- 1A teammate asks a representative a question
- 2StandIn retrieves already-published wraps and allowlisted metadata within the org boundary
- 3That bounded context — and only that context — is sent to the LLM with a zero-retention flag
- 4The LLM generates a grounded response; the context window is discarded
- No training on customer data — contractual commitment from Anthropic
- Zero-retention mode: prompts and completions are not logged beyond the request
- No autonomous system access — the LLM never calls an API on your behalf
- Refuses rather than fabricates when grounding is absent — see the Protocol page
The model sees what you published. Nothing else. For as long as it takes to answer one question.
Is there an audit trail?
Every sensitive action is logged. Admins see everything. Individuals see what was done to them.
- —Every read of another user's wrap — who, when, from which representative
- —Every configuration change — who changed what from what to what
- —Every invite, role change, and membership revocation
- —Every OAuth grant, token refresh, and integration connect/disconnect
If a behavior is surveillance-shaped, it shows up in the audit log. That is intentional.
How is data protected in transit and at rest?
- —TLS 1.3 for all client ↔ server traffic; HSTS enforced
- —AES-256 at rest for primary database and object storage
- —Integration tokens encrypted per-org with a rotated master key (TOKEN_ENCRYPTION_KEY)
- —Secrets, API keys, and OAuth refresh tokens never appear in logs or error traces
Standard practice executed consistently is worth more than exotic practice executed occasionally.
What happens in a data incident?
Notification is a commitment, not a capability.
- —Notify affected customers within 72 hours of confirmed incident, per GDPR Article 33
- —Provide a root-cause write-up within 14 days — what happened, what we changed, what you should do
- —Publish a post-incident summary at trust.standin.co once customers are informed
We would rather publish an uncomfortable incident write-up than hide one.
How do users exercise GDPR rights?
Users and admins have direct routes — no ticket queue, no sales gate.
- —Export — full JSON of your wraps, declarations, and queries from the product settings
- —Rectify — edit any published wrap; edits carry a revision history
- —Delete — admins can delete any user's data within 30 days of request
- —Restrict — admins can pause all LLM calls for a user or the entire org instantly
- —Object — users can opt out of being represented to teammates; their wraps remain private
- —Portability — JSON export is the canonical format; no proprietary lock-in
Rights the user cannot exercise themselves are not rights — they are rituals.
Architecture first. Policy second.
We designed StandIn so that the easy default is the private default. Policies then describe what the architecture already does. If you want to dig deeper, request our DPA, sub-processor list, or pentest report.