Security & Data Governance

Protected at every layer.Verifiable, not just claimed.

Turtini is built on Google Cloud, Firebase, and Cloudflare, and payments run through each organization’s own processor — each with their own certifications. On top of that we run our own tenant isolation, hash-chained audit trail, content moderation, code scanning, SIEM, and issuer authentication on card payments. Every Wally write previews before it commits, and the preview tells you whether that particular action can be undone.

Report a vulnerabilityRequest security docs

Platform Security

What we built in.

These aren't vendor certifications — they're security controls implemented directly into the Turtini platform.

Encryption everywhere

Every byte you push to Turtini is encrypted in transit (TLS 1.2+) and at rest (AES-256, Google Cloud-managed keys). Integration credentials — API keys, OAuth tokens — are held in Google Secret Manager: the database stores a reference, never the value. Worker Social Security numbers get a further layer: they are encrypted field-by-field with Cloud KMS before they are written.

TLS 1.2+ in transit
AES-256 at rest
Credentials in Secret Manager — never in the database
Cloud KMS field encryption for worker Social Security numbers

Tenant isolation at the database layer

Every read and write goes through Firestore Security Rules that scope on org membership. Cross-org access isn't prevented by app code — it's structurally impossible. A bug in our application can't leak one org's data to another.

Org-scoped rules on every collection
Owner / admin / editor / member roles enforced
Verified end-to-end via the Firestore Rules Test API

Authorization decided on the server

Sensitive actions are authorized in Turtini's own server code — domain services on privileged infrastructure that check the caller's verified identity before any write. Default-deny database rules sit underneath as a second, independent layer, so a request has to clear both. A permission decision never depends on a value a browser could set.

Server-side permission checks from the caller's verified identity
Default-deny data rules as an independent second layer
Privilege never derived from a client-supplied field

Least-privilege, hardened infrastructure

Every service runs with the narrowest permissions it needs and nothing more, isolated from the rest, so a single compromised component is contained rather than a foothold. The data plane runs on SELinux-hardened infrastructure with mandatory access control, and automated security checks gate every release before it ships.

Least-privilege service isolation
Mandatory access control on SELinux-hardened infrastructure
Automated security checks gate every release

Hash-chained audit trail

Every accounting write — journal entry, month-end close, period lock — is appended to a SHA-256 hash chain per org. Any retroactive edit breaks the chain and is immediately detectable. Auditors get a verifiable transcript without trusting the application layer.

SHA-256 hash chain for accounting writes
Tamper-evident — any edit invalidates downstream hashes
Wally + UI both surface the verification command

Wally writes preview, undo, and audit

Wally — Turtini's built-in AI — never silently mutates your data. Every write previews before it commits and lands in your org's hash-chained audit log. Where an action can be undone, the preview says so before you confirm and the undo stays open for 24 hours; where it cannot, the preview says that too. Read-only AI prompts cost tokens; writes also leave a paper trail.

Preview-and-confirm on every Wally write
Reversibility stated on the card before you confirm; 24-hour undo where it applies
Per-org, hash-chained Wally activity log you can verify end to end

Image + content moderation pipeline

Every image uploaded to Turtini — site assets, profile photos, marketplace listings — passes through Google Cloud Vision SafeSearch before it can be displayed. Flagged content sits in the admin moderation queue; only approved images render to other users.

Google Cloud Vision SafeSearch on every upload
pending → approved | rejected lifecycle, enforced at render
Admin moderation queue with one-click approve / reject

Payment risk monitoring

For organizations taking card payments, a nightly job reads the last 30 days of their own processor activity and computes dispute and refund rates. Crossing a threshold sets a review flag and opens a queue item for a person; it does not suspend an account, restrict a module, or touch any data. The flag clears by itself when the rates come back down.

Dispute rate above 0.75% — the card networks’ own high-risk cutoff, not a number we invented
Refund rate above 5% over a rolling 30 days
Sets a review flag for a human; nothing is suspended automatically

Platform conduct compliance

An Acceptable Use Policy gate at registration, an automated product-text scan on every public-page publish, and nightly monitoring of public org content. Anything flagged goes to a shared moderation queue for a person to read — nothing is removed or restricted automatically.

Acceptable Use Policy gate at registration
Product-text scan on Builder publishes
Flagged content is queued for human review, not auto-removed

Marketplace bundle code scanning

Every module bundle uploaded to the Turtini Marketplace is scanned for 30+ threat patterns — obfuscation, crypto miners, shell execution, data exfiltration — before a human reviewer ever sees it. Risk score and findings ride alongside the submission.

Pre-upload static scan on every module bundle
Risk score + findings surfaced to reviewers
Bundles flagged "high risk" blocked from approval workflow

Offboarding runs from your directory

Connect your identity provider over SCIM 2.0 and joiners and leavers are handled by the system you already use for everything else. When your directory deactivates someone, their membership in your organization is removed and every session they have open, on every device, stops being able to renew itself. The removal is recorded with its date, because "when did access end" is the question an auditor actually asks.

SCIM 2.0 user provisioning and deprovisioning
Sessions revoked platform-wide on deactivation, not just at next sign-in
Deactivated people stay listed with the date access ended

Built-in SIEM

Turtini ships its own Security Information & Event Management module that captures, correlates, and alerts on platform events — auth, role changes, integration connects, marketplace installs, anomalous Wally activity. Your security team doesn't need a separate Splunk.

Real-time event ingestion + alert rules
Per-org event log with full retention
Auto-escalation to org admin email + in-app banner

Payment data — not on our infrastructure

Turtini never stores, processes, or transmits raw cardholder data. Card entry is delegated to the organization’s own payment processor — each a PCI DSS Level 1 service provider — and their hosted field collects the card. We retain only the last-4, brand, and expiry for display.

No raw card data on Turtini systems
PCI DSS Level 1 processors, chosen by each organization
Tokenized payment methods only

Card payments are authenticated by the issuer

Every card payment is put through 3-D Secure — the buyer’s bank is asked to confirm the cardholder is really them. Most banks answer instantly with nothing shown to the buyer. When the bank confirms, card-network rules move responsibility for a fraud-reason chargeback to the bank that approved it, rather than leaving it with the business that made the sale. Card-present sales at a register and recurring renewals are excluded, since there is no cardholder present to ask.

3-D Secure requested on every card payment, not just large ones
Fraud-chargeback liability moves to the issuing bank on a confirmed authentication
Subscriptions authenticate the first payment; renewals keep running untouched

Dispute evidence is gathered at checkout, not after

Every payment records what was sold, who bought it, the device and network the purchase came from, and the authentication result — at the moment of sale, while the facts still exist. If a chargeback arrives months later, the response is already assembled instead of being reconstructed from memory. High-consequence money actions — refunds, payout changes, releasing held funds — ask for a verification code before they run.

Items, buyer details, and request context captured at the time of payment
Authentication outcome recorded against the charge
Verification code required on refunds, payout changes, and held-fund releases

Infrastructure

Certifications inherited from our providers.

Turtini runs on Google Cloud + Firebase, processes payments via Stripe, and serves traffic through Cloudflare. The infrastructure layer inherits each of their compliance postures.

Google Cloud

All Turtini application data is stored and processed on Google Cloud.

SOC 2 Type IIISO 27001FedRAMP ModerateISO 27017ISO 27018

Firebase

Real-time database, authentication, file storage, and Cloud Functions all run on Firebase.

SOC 2 Type IIISO 27001GDPR-compliant infrastructure

Payment processors

Each organization holds its own merchant account — Stripe, Square or another — and card data goes to that processor, never to Turtini. Money moves directly between the buyer and the organization.

PCI DSS Level 1SOC 2 Type IIISO 27001

Cloudflare

DNS, edge caching, and DDoS protection for sites + custom domains.

SOC 2 Type IIISO 27001PCI DSS

Infrastructure-level certifications apply to the underlying cloud services. Turtini's own compliance roadmap is SOC 2 Type II → CMMC Level 2 → FedRAMP Li-SaaS for the application layer — covering our own policies, procedures, and controls. SOC 2 readiness is in progress. Contact us for current status; federal buyers can deploy the data plane in their own VPC today (see Air-gap deployment above).

Compliance Alignment

Mapped to NIST CSF.

Posture alignment, not certification — but a recognized reference point for enterprise and government procurement.

Identify

Asset inventory via org + module registry
Risk scoring on uploaded content + marketplace bundles
GL dimensions tag every transaction with owner + module

Protect

Mandatory access control — authorization verified in server code from the caller's identity
Least-privilege service isolation on SELinux-hardened infrastructure
Default-deny, org-scoped data rules as a second layer
Encryption in transit + at rest
Integration credentials isolated in Secret Manager, never stored in the database
Cloud KMS field encryption for sensitive personal data
Issuer authentication on card payments above a configurable threshold
Verification code required on high-consequence money actions

Detect

SIEM event monitoring with real-time alerting
Automated content + code scanning
Conduct sweep across public org content
Hash-chain verification of accounting writes

Respond

Admin moderation tools for content removal
Marketplace bundle review before approval
SIEM alert escalation
Wally 24-hour undo on platform writes
Chargeback evidence assembled at the time of payment

Recover

JSON export of every org record on demand
Builder sites exportable to GitHub as static files
30-day grace + 365-day soft-purge recovery on org cancellation
Org pause / resume with no data loss

Data Governance

How your data is handled.

Multi-org data isolation

Every org operates in a strict data silo. Firestore Security Rules enforce org-scoping at the database layer — no application-level bug can expose one org's data to another.

No cross-org data sharing

We do not aggregate, sell, or expose individual org data with other orgs on the platform. Your CRM, financial records, and documents stay yours.

Data residency

Application data is stored in Google Cloud's us-central1 region. Firestore, Firebase Storage, and Cloud Functions all operate within this boundary.

Customer-controlled AI endpoints

Wally and every customer-facing AI surface (Builder Docs rewrites, Builder Sites generation and review, AI Builder Review, Builder Design, drafts, translations) can be pointed at an Anthropic- or OpenAI-compatible endpoint your compliance team operates — AWS Bedrock, Bedrock GovCloud, Google Vertex AI in any region, vLLM, Red Hat AI Inference Server, Azure OpenAI, or your own gateway. Prompts and responses never traverse Turtini's infrastructure on the inference path. Configured per-org from Settings → Wally model; keys live in Google Secret Manager, never in our database.

Air-gap deployment (Enterprise)

Federal and regulated buyers can deploy Turtini's data plane into their own VPC via the Firestore portability shim — a Debezium-streamed Postgres replica with declared per-domain schemas. Pair with a BYO inference endpoint and the result is a Turtini that runs inside your boundary with no callbacks to our central tenancy on the hot path. Contact us for the deployment guide.

Employee-owned records

Paystubs and tax documents stay attached to the person, not the org. Employees keep access to their own pay history after they leave an org.

Third-party access

Turtini does not grant third parties access to org data without explicit authorization. External integrations (Gmail, Google Calendar, GitHub) use OAuth and act only on behalf of the authenticated user, with the narrowest scopes that work.

Retention + deletion

Org admins can pause, cancel, or fully purge their org from Settings, and cancellation runs through a grace period before anything is permanently deleted. JSON export is always available. Every retention period, what user erasure does and does not reach, and where automated enforcement is not yet in place are published in full in the Data Retention Policy at /data-retention.

Responsible Disclosure

Found a vulnerability?

If you believe you've discovered a security vulnerability in Turtini, report it responsibly. We review every report promptly and aim to resolve confirmed issues within 30 days. Reports that include clear, reproducible steps and a demonstration of real-world impact help us act fastest.

[email protected]

No monetary rewards. Turtini runs a responsible-disclosure program, not a paid bug-bounty program. We do not offer monetary rewards, bounties, or other compensation for vulnerability reports, and submitting a report does not create any expectation of payment. We're grateful for good-faith research and will credit reporters of confirmed, original issues on request.

Please don’t publicly disclose vulnerabilities before we’ve had a chance to address them.

Need our security packet for procurement?

Enterprise and government buyers can request the security questionnaire, infrastructure diagram, and compliance artifacts directly.

Contact securityPrivacy policy Data Processing Addendum