---
title: "Controls - Trust Center - Trooth"
description: "Trooth's controls by category, each with its evidence, and those not yet in place."
canonical_url: "https://trooth.co/security/controls"
markdown_url: "https://trooth.co/security/controls.md"
generated_from: "the rendered page, converted to Markdown when this was requested"
agent_index: "https://trooth.co/llms.txt"
---

## Controls

Updated October 12, 2026

57 implemented and attested, 1 in progress, 5 planned, 3 overdue. All self-attested; none independently assessed.

Implemented and attestedIn progressPlanned, not yet in place

### Implemented and attested (57)

In place today. Every one is self-attested by Trooth: no independent auditor or assessor has examined these controls, and none is certified.

| Control | Status | Owner | Evidence reviewed |
| --- | --- | --- | --- |
| Encryption in transit enforced Infrastructure Security TLS 1.2 or later on trooth.co and api.trooth.co; HTTP only redirects to HTTPS. HSTS with includeSubDomains: two years (63072000 seconds) on trooth.co, one year (31536000) on api.trooth.co; trooth.co is not on the browser preload list. **Evidence:** next.config.mjs; infra/dns/records.json (tls_policy) and check:hsts-agreement; the public headers of https://trooth.co and https://api.trooth.co/public/keys, read back by every ship. [Check the evidence](https://trooth.co/) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Encryption at rest Infrastructure Security Neon PostgreSQL (AWS us-east-1) encrypts customer data and backups with AES-256; Trooth's nightly export is AES-256 encrypted before upload. **Evidence:** .github/workflows/db-backup.yml (gpg --symmetric --cipher-algo AES256); Neon's published security documentation. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Tenant data is separated by row-level security Infrastructure Security Every tenant-data table has a row-level security policy the runtime role cannot bypass; a build gate fails the deploy for a table without one. **Evidence:** The database's row-security policies, and two automated checks, run before every deploy, that fail it if any table lacks row security or the application connects with more than its own role. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Tenant isolation tested live with real sessions Infrastructure Security Three real accounts in three workspaces send foreign and forged identifiers to every covered surface, and each must be refused. All assertions held on a production-configured deployment on 2026-09-17, after three runs whose findings were fixed the same day. **Evidence:** tests/tenant-isolation.api.test.mjs; .github/workflows/e2e-isolation.yml, run #5. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Secrets held in the platform secret store, never in source Infrastructure Security Credentials live in Vercel and Cloudflare encrypted configuration and GitHub Actions secrets. Every build checks for committed secrets; TruffleHog runs on every push to main and pull request. **Evidence:** An automated secret scan runs before every deploy and again in the security workflow on every push. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Production deploys from the gated workflow; a direct deploy is detected, not prevented Infrastructure Security On a push to main, nothing uploads until every gate succeeds on that commit, or once main moves past it; the build command runs the gates too, and Vercel's automatic deploys from main are off. A deploy made directly with a Vercel credential cannot be refused, since Vercel cannot confine production to one identity for this team; instead, Vercel membership is limited to the security owner, the workflow token expires in 90 days, workflow deploys are recorded as GitHub Deployments a Vercel credential cannot write, and a check scheduled every hour emails the security owner about anything unrecorded or smoke-test-failed on trooth.co. GitHub starts scheduled checks late, or skips them, when it is busy, so a direct deploy is detected within hours; it is not prevented. **Evidence:** Production is built by the deploy pipeline from the main branch after the full set of automated checks, and a drift check scheduled every hour reports any deployment the pipeline did not record; Access Control Policy, section 5. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Nightly encrypted database backups, no copy kept longer than 35 days Infrastructure Security Website database: exported nightly, encrypted with a required passphrase or not uploaded, kept 30 days. API database: exported daily by its worker and encrypted to a key only Trooth's security owner holds, so neither the storage bucket nor the worker can read it, deleted at 35 days, the longest any backup is kept. **Evidence:** .github/workflows/db-backup.yml; run #47 on 2026-09-18. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Restore from backup is rehearsed Infrastructure Security A monthly workflow restores the latest backup into a fresh database and checks tables, row-level security, row count and restore time. It succeeded on September 10, 2026. **Evidence:** .github/workflows/db-restore-rehearsal.yml; run #1 on 2026-09-10. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Production is separated from preview and development Infrastructure Security Previews run on their own Vercel hosts, not trooth.co. The build's row-level-security proof uses a throwaway runner database, and the isolation harness refuses production. **Evidence:** The deploy pipeline runs the database checks against a separate PostgreSQL instance, never production, and the tenant-isolation tests refuse to run against production. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Availability is monitored from outside and published Infrastructure Security An external monitor checks trooth.co, api.trooth.co and the health route, backed by a GitHub Actions monitor. Results, incident history and email subscriptions are on the public status page. **Evidence:** External monitors check the site and the API on a schedule and publish the result at https://trooth.co/status. [Check the evidence](https://trooth.co/status) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Security policies established and reviewed Organizational Security Nineteen public, dated, Trooth-owned policies with six-month review dates: information security, access control, passwords and authentication, data classification, encryption, secure development, vulnerability management, logging and monitoring, incident response, business continuity, backup and retention, asset, risk and vendor management, acceptable use, personnel, physical security, data residency and AI governance. **Evidence:** POL-01 to POL-19 (Resources tab), effective September 18, 2026, next review March 18, 2027; superseding the signed set of May 25, 2026. [Evidence on the Resources tab](https://trooth.co/security/resources) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Security roles and responsibilities defined Organizational Security Trooth's security owner makes security decisions and policy changes, and production write access is limited to that role. Anyone else signs a confidentiality and acceptable-use agreement first; vendors processing Trooth data sign a data processing agreement. **Evidence:** Information Security Policy, section 4; Access Control Policy, section 5. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Inventory of systems and data assets maintained Organizational Security A register of external services, an asset inventory by classification, and route, component and file inventories checked on every deploy. **Evidence:** Internal service and asset registers, checked on every build against the code that is deployed; available under NDA on request. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Sub-processors are inventoried, published and announced before change Organizational Security Sub-processors are listed publicly with purpose and region; customers get 30 days' notice of a new one and may object for reasonable cause. **Evidence:** https://trooth.co/subprocessors; Data Processing Addendum; Vendor and Third-Party Risk Management Policy. [Check the evidence](https://trooth.co/subprocessors) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Risk register maintained Organizational Security Each risk records likelihood, impact, control and evidence; the register is re-read when gates or known limitations change. **Evidence:** An internal risk register, checked for staleness on every build; available under NDA on request. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Confidentiality agreement required before any system access Organizational Security No contractor or agent gets access before signing a confidentiality and acceptable-use agreement. As of this page's date, no employee or contractor has access. **Evidence:** Information Security Policy, section 4; POL-15 Acceptable Use Policy (Personnel), published on the Resources tab. [Evidence on the Resources tab](https://trooth.co/security/resources) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Incident response plan established Internal Security Procedures Four severities, first response in one hour to three business days. Covers detection, acknowledgment, containment, eradication, recovery, status page and email updates, and a written post-mortem within seven days at the highest severity. Alerts reach the founder's phone at any hour. **Evidence:** Incident Response Policy; an internal incident runbook, available under NDA on request; the incident history at https://trooth.co/status. [Check the evidence](https://trooth.co/status) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Breach notification within 72 hours Internal Security Procedures Affected customers, and supervisory authorities where required, are notified within 72 hours of Trooth learning of a personal data compromise, per the Data Processing Addendum. **Evidence:** Data Processing Addendum at https://trooth.co/dpa; Incident Response Policy, section 6. [Check the evidence](https://trooth.co/dpa) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Business continuity and disaster recovery plan established Internal Security Procedures Targets: service restored within four hours of detection when Trooth's operators respond, and at most twenty-four hours of data lost, matched to the nightly backup. If Trooth's operators cannot be reached, the Continuity Contact may act only after four hours of trying, so that wait can use the whole four-hour target; the contact's first steps are containment, and no end-to-end exercise with the contact has been completed yet. **Evidence:** Business Continuity Statement at https://trooth.co/continuity, section 6.3 for the clocks and the limit; internal disaster recovery and business continuity plans, available under NDA on request. The first exercise with the Continuity Contact is planned for October 2026. [Check the evidence](https://trooth.co/continuity) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Every workflow deploy clears automated gates first Internal Security Procedures A commit on main uploads through the deploy workflow only after the type check, lint, unit suites and build gates succeed: headers, authorization, database roles, row-level security, secrets, request validation, rate limits, accessibility, documentation and more. A deploy made directly with a Vercel credential can skip the workflow; it is detected within hours, not prevented, as the deploy row above says. **Evidence:** Every change passes the full set of automated checks before the deploy pipeline will build it. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Vulnerability management with remediation timelines Internal Security Procedures Dependabot watches dependencies; static analysis and a high and critical advisory audit run on every push to main and pull request. Published remediation for production findings: critical 24 hours, high 7 days, medium 30, low 90. **Evidence:** .github/dependabot.yml; .github/workflows/security-scan.yml (pnpm audit, TruffleHog, semgrep); Vulnerability Management Policy. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Vulnerability disclosure policy with safe harbor published Internal Security Procedures Researchers report to security@trooth.co under a published safe harbor policy for good-faith research, advertised in security.txt. **Evidence:** https://trooth.co/security/vulnerability-disclosure-policy; https://trooth.co/.well-known/security.txt. [Check the evidence](https://trooth.co/security/vulnerability-disclosure-policy) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Application errors and security events are logged and reviewed Internal Security Procedures Application errors are scrubbed of personal data on the server before sending. Material actions go to an append-only, hash-linked ledger where a removed or altered row is detectable. **Evidence:** Errors are reported to the error tracker with authorization headers, cookies and credentials in URLs removed before they leave the application; automated checks hold the scrubbing in place on every build. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Physical security inherited from the data center providers Internal Security Procedures Trooth operates no physical infrastructure. AWS (through Neon and Vercel) and Cloudflare hold the data and publish independent audit reports on their facilities' physical and environmental controls. **Evidence:** Sub-processor list; Shared Responsibility Model (Resources tab). [Evidence on the Resources tab](https://trooth.co/security/resources) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| AI systems are inventoried in a published fact sheet AI Security & Compliance A published model card names each AI-assisted feature's intended use, users, inputs, outputs, approach and limitations. **Evidence:** https://trooth.co/model-card; AI System Fact Sheet (Resources tab). [Check the evidence](https://trooth.co/model-card) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| AI use policy published AI Security & Compliance A public policy names where generative AI is and is not used, decisions a person always makes, and no training on customer content. **Evidence:** https://trooth.co/ai-policy; https://trooth.co/ai-disclosure. [Check the evidence](https://trooth.co/ai-policy) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Customer data is not used to train models AI Security & Compliance Customer content, connected-integration data and account information do not train foundation models and are not sold or shared so others can. Pages carry noai and noimageai directives. **Evidence:** Privacy Policy, https://trooth.co/privacy; AI Disclosure, section on automated access. [Check the evidence](https://trooth.co/privacy) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| EU AI Act role and risk classification documented AI Security & Compliance Each AI-assisted feature is classified by EU AI Act risk, with Trooth's provider role, each transparency obligation and how it is met documented. **Evidence:** EU AI Act Transparency and Risk Classification (Resources tab); EU AI Act statement. [Evidence on the Resources tab](https://trooth.co/security/resources) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| EU AI Pact signatory AI Security & Compliance Trooth signed the AI Pact ahead of the AI Act's application; the European Commission lists it on its public signatory roster. **Evidence:** https://digital-strategy.ec.europa.eu/en/policies/ai-pact; EU AI Pact commitments (Resources tab). [Evidence on the Resources tab](https://trooth.co/security/resources) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| AI-generated content is labeled where it appears AI Security & Compliance AI-assisted output is labeled in the product; a witnessed observation is never labeled as an AI draft. **Evidence:** AI Disclosure, sections 2 and 3; test:ai-features in verify:deploy. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| A person makes every decision that binds the company or a customer AI Security & Compliance AI-assisted features draft; they do not send, publish, sign, approve or delete, and each of those actions needs a person's explicit confirmation. **Evidence:** AI Disclosure, section on decisions always made by a person; test:publish-authorization and test:approval-authority in verify:deploy. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Content from outside the company is isolated from instructions AI Security & Compliance Third-party text (questionnaires, crawled pages, uploads) is data, never an instruction to an AI-assisted feature; a build gate enforces this. **Evidence:** Text a company or a source supplies is treated as data, never as instructions, and an automated check holds every surface that shows it to that rule on every build. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| AI risk management aligned to the NIST AI RMF AI Security & Compliance Trooth maps its AI governance to the four NIST AI RMF functions and publishes the mapping with its open gaps. **Evidence:** NIST AI RMF alignment statement (Resources tab). [Evidence on the Resources tab](https://trooth.co/security/resources) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| AI features run on infrastructure whose terms exclude inputs and outputs from training AI Security & Compliance Open-weight models run on Cloudflare Workers AI, inside the product's network, under terms excluding Trooth's inputs and outputs from training. No customer content reaches a consumer AI service; Cloudflare is a listed sub-processor. **Evidence:** Sub-processor list (Cloudflare, Inc.); AI System Fact Sheet; Cloudflare's published Workers AI data-use terms. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Multi-factor authentication available to every account Product Security Authenticator-app TOTP (time-based one-time password) as a second factor, and passkeys, are built in and free for every account, buyers included, and are never a paid feature. **Evidence:** Settings, Security, in the product; covered by the automated sign-in tests. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Passwords stored as salted hashes with rising work factors Product Security Salted PBKDF2 hashes, upgraded as work factors rise. Equalized timing and lockout resist account enumeration at sign-in and signup. **Evidence:** Security Overview (Resources tab); the sign-in behavior is observable from outside on every attempt. [Evidence on the Resources tab](https://trooth.co/security/resources) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Sessions in httpOnly, secure cookies with a fixed expiry Product Security Session cookies are httpOnly, secure and same-site, with a 30-day absolute expiry; logout revokes the session upstream and reports any failure. **Evidence:** The session is an httpOnly, Secure, SameSite=Lax cookie that browser code cannot read; signing out ends it on the server as well; covered by the automated sign-in tests. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| API keys shown once and stored only as hashes Product Security API keys are shown once, stored only as SHA-256 hashes, scoped to a workspace and revocable at any time. **Evidence:** Security Overview (Resources tab); API Terms at https://trooth.co/api-terms. [Check the evidence](https://trooth.co/api-terms) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Multi-factor recovery codes Product Security Accounts with multi-factor authentication on can generate single-use recovery codes for a lost authenticator. **Evidence:** Ten single-use codes per set, made in Settings, Security with a current authenticator code; a new set revokes the old, only keyed hashes are stored, and each set or use is emailed. Covered by automated tests on the site and on api.trooth.co. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Request bodies validated against schemas Product Security Credential-free mutating routes parse bodies against declared schemas and read no undeclared field; a build gate enforces it. **Evidence:** Every request body is checked against a schema on the server before it is used, and an automated check fails the build if a route skips it. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Content Security Policy and security headers enforced and gated Product Security Every response carries a content security policy, HSTS, and frame, content-type and referrer policies; a build gate checks the policy against source on every deploy. **Evidence:** next.config.mjs; check:csp in verify:deploy. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Rate limiting and bot protection on public surfaces Product Security Unauthenticated and bare-token mutations are rate limited per client, failing closed where work costs money. Cloudflare Turnstile rejects a failed public form submission before anything else. **Evidence:** Per-network limits on public forms and sign-in routes, a bot check on the forms people submit, and an automated check that holds public routes to their limits on every build. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Append-only, hash-linked audit ledger Product Security Every material product action enters an append-only, hash-linked ledger, so a removed or altered entry breaks the chain and is detectable. **Evidence:** check:ledger in verify:deploy; the Security Overview (Resources tab). [Evidence on the Resources tab](https://trooth.co/security/resources) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Authorization derived from the session, never from the request body Product Security Tenant-data routes take the owner from the session, a build gate checks each for an authorization call, and assessed surfaces enforce function-level and property-level authorization. **Evidence:** An automated authorization check runs before every deploy; an internal defensive assessment, available under NDA on request. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Build inputs pinned and continuous-integration permissions minimized Product Security Frozen-lockfile installs, third-party GitHub Actions pinned to full commit SHAs, and read-only workflow permissions unless a job must write. **Evidence:** .github/workflows (permissions blocks and pinned uses); check:lockfile in verify:deploy. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Software bill of materials published for the web application and the API Product Security The web application's public CycloneDX bill lists every resolved package, direct and transitive, with integrity hash, ship flag and dependency graph; a build gate fails on any lockfile mismatch. Which deployment a bill describes is self-attested: the deploy workflow records the bill's digest beside the build's in an unsigned statement that no reader can check independently, and a direct deploy with a Vercel credential is bound to no bill. Each of the eight Workers behind api.trooth.co has a bill from its lockfile at a named commit, not from the script Cloudflare serves. **Evidence:** https://trooth.co/sbom.json for the website and https://trooth.co/sbom/api.cdx.json for api.trooth.co, regenerated on every release and checked by automated tests. [Check the evidence](https://trooth.co/sbom.json) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Privacy policy published and maintained Data and Privacy The dated policy states what is collected, why, how long, who processes it and how to exercise rights, reviewed when the product or law changes. **Evidence:** https://trooth.co/privacy. [Check the evidence](https://trooth.co/privacy) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Data processing addendum available Data and Privacy A data processing addendum with standard contractual clauses is published and part of customer terms without negotiation. **Evidence:** https://trooth.co/dpa. [Check the evidence](https://trooth.co/dpa) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Sub-processor list published with 30 days' notice of change Data and Privacy The public list gives each provider's purpose and processing region, and changes are announced 30 days ahead. **Evidence:** https://trooth.co/subprocessors; this page's Sub-processors tab reads the same document. [Check the evidence](https://trooth.co/subprocessors) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Data retention and disposal schedule published Data and Privacy Each data kind has a maximum retention and disposal event. Closing an account stops sign-in at once and removes working data from live systems within 30 days; a backup copy expires at most 30 days (website) or 35 days (account service) after the data leaves live systems. **Evidence:** https://trooth.co/retention; Data Retention and Disposal Policy. [Check the evidence](https://trooth.co/retention) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Data subject requests handled within 30 days Data and Privacy Access, correction, portability and erasure requests follow a published procedure and close within 30 days; erasure runs on the live database and is tested in the build. **Evidence:** Data Subject Rights Request Procedure (Resources tab); test:privacy-request and test:erasure-live in verify:deploy. [Evidence on the Resources tab](https://trooth.co/security/resources) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Data classification policy established Data and Privacy Public, internal, confidential and restricted levels, each with encryption, access, logging and storage rules. **Evidence:** POL-04 Data Classification and Handling Policy, published on the Resources tab. [Evidence on the Resources tab](https://trooth.co/security/resources) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| No payment card data is collected or stored Data and Privacy Trooth takes no payment and holds no card data. No payment processor is a sub-processor. **Evidence:** Sub-processor list change log, September 4, 2026. [Request the evidence](https://trooth.co/security#document-request) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Personal information is not sold Data and Privacy Trooth does not sell personal information or use the content of connected data for advertising. **Evidence:** Privacy Policy; CCPA statement (Resources tab). [Evidence on the Resources tab](https://trooth.co/security/resources) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Data residency documented Data and Privacy The website's database is in the United States (AWS us-east-1, through Neon). The account service at api.trooth.co keeps its records and their backup export in Cloudflare's Eastern North America location, which is not restricted to a jurisdiction. Cloudflare and Vercel run edge compute and delivery globally. Each sub-processor's region is published. **Evidence:** https://trooth.co/subprocessors. [Check the evidence](https://trooth.co/subprocessors) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Cookie use disclosed and limited Data and Privacy The site sets the cookies its session and security need, each disclosed; analytics are aggregate, with no personal identifiers. **Evidence:** https://trooth.co/cookies. [Check the evidence](https://trooth.co/cookies) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |
| Records of processing activities maintained Data and Privacy A GDPR Article 30 record lists purposes, data and data-subject categories, recipients and retention. **Evidence:** Records of Processing Activities (available under NDA from the Resources tab). [Evidence on the Resources tab](https://trooth.co/security/resources) | Attested Self-attested | Security owner | October 4, 2026 (30 days ago) |

### In progress (1)

Started, with a record of the part that is done. Not in place until its record is complete.

| Control | Status | Owner | Due |
| --- | --- | --- | --- |
| Quarterly access reviews performed Organizational Security Human and service accounts, sub-processor access and tokens are reviewed and recorded every 90 days. **Becomes attested when:** Partly complete: the first review (September 28, 2026) covered the code host, hosting, network, database, package registry, workspace email and error tracking, and found eleven items. Explained and kept: A3 the Vercel token is Trooth's own Vercel connection. Closed: unused integrations removed, every remaining token given an end date or revoked, and two-step sign-in confirmed on every account read, the database provider's confirmed by Trooth on October 6, 2026; one credential that nothing uses is kept and recorded. The remaining providers are reviewed by October 31, 2026, when this becomes attested; the next full review is due by December 27, 2026. [Request the evidence](https://trooth.co/security#document-request) | Overdue Self-attested | Security owner | Was due October 31, 2026 |

### Planned, not yet in place (5)

Not in place. Each row says when it is due, or the event it waits for; a date that passes turns the row Overdue without anyone editing it.

| Control | Status | Owner | Due |
| --- | --- | --- | --- |
| Security awareness training completed annually Organizational Security Everyone with production access completes recorded security awareness training within thirty days and annually after. **Becomes attested when:** Not due yet: no completion record exists, and the first is due by October 31, 2026; becomes attested with the first completion record. [Request the evidence](https://trooth.co/security#document-request) | Overdue Self-attested | Security owner | Was due October 31, 2026 |
| Personnel screening before production access Organizational Security New hires are background-checked before production access, where lawful in their jurisdiction. **Becomes attested when:** Not due yet: the written check is due before anyone new gets production access. [Request the evidence](https://trooth.co/security#document-request) | Planned Self-attested | Security owner | Before anyone new gets production access |
| Incident response plan tested Internal Security Procedures An end-to-end drill of detection, the status page, customer communication and the post-mortem is run and documented at least annually. **Becomes attested when:** Not due yet: not yet run. The first drill, including the operator-unavailable key-compromise and deletion scenario (continuity document, section 6), is set for October 30, 2026 (Incident Response Policy, section 8); becomes attested when its record exists, whatever it shows. [Request the evidence](https://trooth.co/security#document-request) | Overdue Self-attested | Security owner | Was due October 30, 2026 |
| Independent penetration test Product Security A third party tests the production web application and its APIs at least annually; the executive summary is published here. **Becomes attested when:** Deferred: not yet performed, and deferred until the first enterprise customer signs. Static analysis, dependency audits and committed-secret checks run on every push meanwhile; this row changes when a report exists. [Request the evidence](https://trooth.co/security#document-request) | Planned Self-attested | Security owner | When the first enterprise customer signs |
| EU representative appointed Data and Privacy A representative in the European Union is designated under GDPR Article 27 where that obligation applies. **Becomes attested when:** Not appointed, under the exemption in Article 27(2)(a) (revised September 28, 2026, the same day as a decision to appoint by November 30). EU processing is occasional (two cookie choices from European Economic Area, United Kingdom or Swiss visitors since September 27, 2026), has no special category data and is unlikely to put anyone's rights at risk; a representative is appointed within 30 days of the first EU-established customer, or sooner if processing becomes regular, reassessed each quarterly access review. [Request the evidence](https://trooth.co/security#document-request) | Planned Self-attested | Security owner | Within 30 days of the first EU-established customer, or sooner if EU processing becomes regular |

Abbreviations used in the Trust Center

**AES**

Advanced Encryption Standard

**AI**

artificial intelligence

**API**

application programming interface

**APRA**

Australian Prudential Regulation Authority

**AWS**

Amazon Web Services

**BAA**

business associate agreement (HIPAA)

**CAIQ**

Consensus Assessments Initiative Questionnaire (Cloud Security Alliance)

**CCPA**

California Consumer Privacy Act

**CISA**

Cybersecurity and Infrastructure Security Agency (United States)

**CPRA**

California Privacy Rights Act

**CSA**

Cloud Security Alliance

**CSF**

Cybersecurity Framework (NIST)

**CPS**

Cross-Industry Prudential Standard (APRA)

**DORA**

Digital Operational Resilience Act (European Union)

**DPA**

data processing agreement

**DPDP**

Digital Personal Data Protection Act (India)

**DPIA**

data protection impact assessment

**DSS**

Data Security Standard (PCI)

**EU**

European Union

**FTC**

Federal Trade Commission (United States)

**GDPR**

General Data Protection Regulation (European Union)

**HIPAA**

Health Insurance Portability and Accountability Act

**HSTS**

HTTP Strict Transport Security

**HTTP**

Hypertext Transfer Protocol

**HTTPS**

HTTP over TLS

**ICT**

information and communication technology

**IEC**

International Electrotechnical Commission

**ISO**

International Organization for Standardization

**LLC**

limited liability company

**NDA**

non-disclosure agreement

**NIS**

Network and Information Security Directive (European Union)

**NIST**

National Institute of Standards and Technology (United States)

**NYCRR**

New York Codes, Rules and Regulations

**NYDFS**

New York State Department of Financial Services

**PBKDF2**

Password-Based Key Derivation Function 2

**PCI**

Payment Card Industry

**PIPEDA**

Personal Information Protection and Electronic Documents Act (Canada)

**RMF**

Risk Management Framework (NIST)

**SHA**

Secure Hash Algorithm

**SIG**

Standardized Information Gathering questionnaire (Shared Assessments)

**SOC**

System and Organization Controls (AICPA)

**SP**

Special Publication (NIST)

**STAR**

Security, Trust, Assurance and Risk registry (Cloud Security Alliance)

**TLS**

Transport Layer Security

**TOTP**

time-based one-time password

**URL**

web address (uniform resource locator)

## Structured data

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://trooth.co/#org",
      "name": "Trooth",
      "legalName": "Trooth, LLC",
      "alternateName": [
        "Trooth, LLC",
        "Trooth Network",
        "trooth.co"
      ],
      "url": "https://trooth.co",
      "logo": {
        "@type": "ImageObject",
        "@id": "https://trooth.co/#logo",
        "url": "https://trooth.co/brand/trooth-mark_black-on-white_1024.png",
        "contentUrl": "https://trooth.co/brand/trooth-mark_black-on-white_1024.png",
        "width": 1024,
        "height": 1024,
        "caption": "Trooth"
      },
      "image": {
        "@id": "https://trooth.co/#logo"
      },
      "description": "Trooth is an infrastructure and cybersecurity company providing Machine-Readable Trust. The Trooth Network keeps one current Machine-Readable Trust Profile per company, each fact sourced. Trooth signs what it witnessed; company declarations are unsigned.",
      "foundingDate": "2025-12-16",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "777 Brickell Ave, Suite 500, PMB 1174",
        "addressLocality": "Miami",
        "addressRegion": "FL",
        "postalCode": "33131",
        "addressCountry": "US"
      },
      "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "email": "hello@trooth.co",
        "url": "https://trooth.co/contact"
      },
      "sameAs": [
        "https://x.com/Troothllc",
        "https://github.com/troothllc",
        "https://www.crunchbase.com/organization/trooth",
        "https://www.wikidata.org/wiki/Q141292994",
        "https://www.youtube.com/@Troothllc",
        "https://www.trustpilot.com/review/trooth.co"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://trooth.co/#website",
      "url": "https://trooth.co",
      "name": "Trooth",
      "alternateName": "Trooth Network",
      "inLanguage": "en",
      "publisher": {
        "@id": "https://trooth.co/#org"
      },
      "sameAs": [
        "https://trooth.co/network/company/trooth"
      ],
      "potentialAction": {
        "@type": "SearchAction",
        "target": {
          "@type": "EntryPoint",
          "urlTemplate": "https://trooth.co/network?q={search_term_string}"
        },
        "query-input": "required name=search_term_string"
      }
    },
    {
      "@type": "ItemList",
      "@id": "https://trooth.co/#sitelinks",
      "name": "Trooth sitelinks",
      "itemListElement": [
        {
          "@type": "SiteNavigationElement",
          "position": 1,
          "name": "Join Trooth for free",
          "url": "https://trooth.co/signup"
        },
        {
          "@type": "SiteNavigationElement",
          "position": 2,
          "name": "Company, Trooth",
          "url": "https://trooth.co/network/company/trooth"
        },
        {
          "@type": "SiteNavigationElement",
          "position": 3,
          "name": "Trooth Network",
          "url": "https://trooth.co/network"
        }
      ]
    }
  ]
}
```