CAIQ v4 domains and a SIG Lite-style short set. 96 answers, each Yes, No, Partial or Not applicable, with the mechanism behind it and the gap where the answer is no. Paste the CSV into your tool.
Last reviewed 3 September 2026. Answers are generated from one record set; the CSV carries the same rows.
The questions a security or legal reviewer works from, answered in the shape of the two questionnaires they most often send: the Cloud Security Alliance CAIQ v4, grouped by its seventeen domains, and a SIG Lite-style short set of the forty most-asked questions. Every answer is Yes, No, Partial or Not applicable, followed by the mechanism that makes it true and, where it is No, what exists instead. Nothing here is behind a request form, including the No rows.
The full pack (this set on your own template, the internal security review with its 53 tests, the data processing agreement countersigned, and written answers to anything not covered) comes from hello@feerasta.ai. Security reports go to security@feerasta.ai.
The seventeen CAIQ v4 domains, then the AI-specific block. Each row names its source in the source of truth so it can be checked.
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| AA-1 | Do you hold an independent audit report or certification (SOC 2, ISO 27001, ISO 42001)? | No | None held. What exists instead: an internal security review of 14 attack classes with 53 automated tests, published in full, and a regression suite of 1,160 tests on SQLite and 1,167 on Postgres that runs on every push and in the deploy gate. Ask and we will say so in writing. | F §1 fact 5; F §10 W15; SR result table |
| AA-2 | Are security controls tested on a defined cadence? | Yes | The full test suite runs on every push (GitHub Actions, SQLite and Postgres) and a read-only smoke suite runs on every deploy; a deploy that fails it rolls back automatically. The safety battery re-runs on every channel save and activation. | F §3; F §9 fixed 2026-08-07; PG CI section; code .github/workflows/test-pg.yml |
| AA-3 | Are tests proven to detect the failures they guard? | Yes | Suites were mutation tested: each guard was checked against the broken code it protects (reverting a fix fails the named tests). We publish that we break our own safeguards on purpose. | MEM os-platform-hardening; F §7 verification.html |
| AA-4 | Will you complete a customer's own questionnaire or allow an audit? | Yes | This pack, the CSV and written answers to anything not covered, including where the answer is no. The DPA grants the information needed to demonstrate compliance and allows audit. | site dpa.html §4; site security.html questionnaire |
| AA-5 | Has an external penetration test been performed? | No | No external penetration test. The internal adversarial review (cross-tenant ids, body-id injection, CSRF, role escalation, SSRF, secrets in exports, public hook keys, WhatsApp approver replay, HTML injection, input limits, deletion) is published with its results. | SR method and result table; GAP §2 gap 7 |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| AIS-1 | Do you follow a secure development practice for application code? | Partial | Practices are enforced in code and tests rather than in a written SDLC document: user-supplied values reach the DOM through textContent only, HTML-injection canaries are tested on every portal page, CSRF is required on every cookie write, and regexes a client supplies are refused if they match a catastrophic-backtracking shape. No formal SDLC policy document exists. | CLAUDE.md site conventions; SR 12, 3, 13c; F §3a workflow engine |
| AIS-2 | Are inputs validated and bounded on the public and tenant APIs? | Yes | Body size is capped server-side (413), condition and action counts cap at evaluation, deep nesting and catastrophic regex are refused, E.164 and IANA timezone values are validated, and unknown fields such as plan or draft_only are dropped, never written. | SR 13a to 13d |
| AIS-3 | Is server-side request forgery prevented on any URL the application fetches? | Yes | The onboarding importer and outbound webhooks refuse private, loopback, link-local, metadata, mapped-IPv6 and non-https targets, follow no redirects, and re-check after DNS resolution (29 hostile hosts and DNS rebinding tested). | SR 5a to 5e; F §10 W11, W12 |
| AIS-4 | Are APIs rate limited? | Yes | Public API routes: 40 requests per minute per IP. Public hooks: 60 per minute per key on top of that. Login: 10 attempts per address per 15 minutes. Signup: 50 per day platform-wide and 5 per company email domain per day. | SR 7c; F §9 fixed 2026-08-07; F §10 W13, W16 |
| AIS-5 | Are webhooks and inbound integrations authenticated? | Yes | All Twilio webhooks verify the Twilio signature and fail closed; WhatsApp approvals need the Meta signature and a sender phone registered on that tenant, with replay refused; outbound webhooks are HMAC-SHA256 signed with a per-tenant secret that is stored encrypted and shown once. | F §9 fixed 2026-08-07; F §10 W1, W12, 4e1d67d; SR 10a to 10d |
| AIS-6 | Is cross-tenant access prevented at the application layer? | Yes | 26 id-bearing routes and 14 write routes were probed across two tenants: every foreign id returns 404, every write lands on the caller's tenant, lists never include another tenant. A static scan plus a two-tenant runtime sweep runs in the suite. | SR 1, 2; F §10 W2 test/portal-tenant-isolation.test.mjs |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| BCR-1 | Are backups taken, and how often? | Yes | A nightly pg_dump of the production database, gzipped, kept 14 days locally and copied to an encrypted offsite target (rclone crypt remote on Google Drive). File attachments are backed up alongside. The dump is content-verified before it counts: size floor, schema present, data present, else the run fails loudly. | code deploy/backup.sh; GAP scorecard row 29; site subprocessors.html Google row |
| BCR-2 | Have you proven a backup can be restored? | Yes | deploy/restore-drill.sh restores the newest dump into a throwaway Postgres container, checks a structural floor of at least 40 tables with plausible row counts, and destroys the container on every exit path. First run 2026-08-01. It runs after any change to the backup script. | MEM os-platform-hardening; code deploy/restore-drill.sh, deploy/restore.sh |
| BCR-3 | Is the platform redundant across servers or regions? | No | One application server and one Postgres instance in Germany (Hetzner, Falkenstein). No second server, no second region; Canadian and US regions are on the roadmap, not available. Recovery from loss of the server is a restore from the nightly backup, so up to one day of data can be lost. | F §3; site security.html Where it runs |
| BCR-4 | Do you publish recovery time and recovery point objectives? | No | No RTO is published. The recovery point follows from the nightly backup (up to 24 hours). We do not print figures we cannot yet show history for. | code deploy/backup.sh; site status.html |
| BCR-5 | Is availability monitored and an uptime commitment offered? | Partial | The website, the platform and Relate are checked every five minutes by an independent monitor with a public status page. No contractual uptime percentage is published; Business tier SLA terms are provided on request until ninety days of measured history exist. | F §7 security.html; site status.html |
| BCR-6 | Does a failed deploy leave the service down? | No | The deploy script runs the smoke suite after restart and rolls back to the previous commit if it fails, reporting whether the rollback fixed it. Proven by forcing a failure. | F §3 Deploy; MEM os-platform-hardening |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| CCC-1 | Is all code under version control with a reviewable history? | Yes | Git. Every deploy is a pushed commit; the server snapshots any uncommitted edit before resetting to the commit, so nothing runs in production that is not in history. | F §3 Deploy; MEM server-edits note |
| CCC-2 | Are changes tested before release? | Yes | 1,160 tests on SQLite and 1,167 on Postgres run on every push in CI; the deploy gate runs a read-only smoke suite and a Postgres dashboard render, and rolls back on failure. | F §10 heading; PG results table; PG deploy smoke |
| CCC-3 | Is production configuration documented and reproducible? | Yes | .env.example is regenerated with a two-way test (every environment variable the code reads is documented, no ghosts). Production refuses to boot on an unset or default admin key. | F §10 W1 |
| CCC-4 | Is there a formal change advisory or approval board? | No | A single founder-operator approves and deploys changes. The controls are automated: CI, the deploy gate and rollback. There is no separate change board. | F §1; F §7 escalation |
| CCC-5 | Is a client-facing agent change gated by safety checks? | Yes | A channel is re-checked on every save, not only at activation; a live channel that fails a critical safety standard is switched off rather than left in front of customers, and a confirmed production failure blocks go-live whatever its severity. | F §9 fixed 2026-08-07; F §3a |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| CEK-1 | Is data encrypted in transit? | Yes | TLS on every public endpoint: Let's Encrypt on app.feerasta.ai, Cloudflare on feerasta.ai. Outbound webhooks are https only. | F §3; SR 5e |
| CEK-2 | Is data encrypted at rest? | Partial | Stored secrets (customer model keys, webhook secrets, Relate tokens) are encrypted server-side with AES-256-GCM, and backups are encrypted before they leave the server. The application server's disk and the Postgres data files are not full-disk encrypted today. We state this rather than round it up. | site security.html In transit and at rest; F §10 W24; GAP scorecard row 28; code deploy/backup.sh |
| CEK-3 | How are passwords stored? | Yes | PBKDF2-SHA256, 120,000 iterations, per-user salt, constant-time comparison. Session tokens are stored hashed, never in plain text. | code server.mjs:501 to 514; F §3b |
| CEK-4 | How are cryptographic keys managed and rotated? | Partial | Application secrets live in the server environment file, readable only by the service account; there is no HSM or external KMS. A tenant's webhook secret can be rotated by its owner (rotation replaces, audited). No fixed rotation schedule is published for platform keys. | F §10 4e1d67d; code deploy/backup.sh env handling |
| CEK-5 | Can customers bring their own model key, and how is it protected? | Yes | Yes. A model key a customer brings is encrypted on the client record and is never returned by any GET, export, audit export, trust view, preview or admin list (plaintext and ciphertext canaries tested). Shown once at entry. | F §10 W1 model-auth; SR 6a, 6c |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| DCS-1 | Where is customer data physically processed and stored? | Yes | One server at Hetzner, Falkenstein, Germany, running the application and its PostgreSQL database. The public website is delivered by Cloudflare's edge. Encrypted backups are copied to Google Drive. The full provider list with locations is published. | F §3; site subprocessors.html |
| DCS-2 | Do you control physical access to the datacenter? | Not applicable | Physical security is Hetzner's. We hold no datacenter and no staff visit it. Hetzner's own attestations are theirs to provide; we will forward what they publish on request rather than restate it. | site subprocessors.html Infrastructure |
| DCS-3 | Is there an inventory of systems holding customer data? | Yes | One application server, one Postgres instance (55 tables), one encrypted backup target, and the named subprocessors, each with purpose and location. The list is reconciled to what the code calls, not to a roadmap. | F §3 Database; site subprocessors.html |
| DCS-4 | Can data stay in a specific country? | Partial | Today, Germany only. Where residency rules out a shared platform, Feerasta Sovereign runs the same workflows on infrastructure the customer controls (private cloud, on-premise or air-gapped). | F §2a Sovereign; site security.html Where it runs |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| DSP-1 | Is customer data used to train models, yours or a provider's? | No | Never, and it is never sold or pooled. Customer-facing conversations make no model call at all. Model-backed drafting runs on the customer's own key, so the customer's provider terms govern those calls; where the platform supplies the model and a provider's default would permit training, the setting that disables it is used. | F §1 fact 1; site dpa.html §5; site security.html rules |
| DSP-2 | Can a customer export all of their data? | Yes | The whole workspace as JSON from inside the product at any time, secrets redacted by column pattern (tested with a canary column). The audit log exports separately. | F §10 W11 /api/portal/export, /api/portal/audit-export; SR 6b |
| DSP-3 | How is deletion handled? | Yes | Deletion is scheduled from inside the product after a recent export and runs after a 30-day window in which it can be cancelled; a workspace that is still billing is refused until cancelled. Three records survive because they are the proof a STOP was honoured and what was approved: consent records, the opt-out list and the audit trail. | F §10 W11, W15 7a9bb83; site trust.html How deletion works |
| DSP-4 | Is there a retention policy the customer controls? | Yes | Each workspace sets its own retention period (30 to 3,650 days) and a nightly job purges what is past it. | F §10 W13 settings; site trust.html Retention |
| DSP-5 | Is consent recorded and honoured on outbound messaging? | Yes | Consent is recorded per person, per channel, with its source. STOP as the first word on any channel revokes every channel and is enforced at the single send choke point; HELP is answered. A message with no consent record is refused and the refusal is logged. Every outbound channel starts switched off. | F §10 W11, W13; SR 8b |
| DSP-6 | Are special categories of data (health, biometric, financial identity) processed? | No | Out of scope on the shared platform unless separately agreed in writing. Where they are needed, the private deployment and the right agreement (for example a HIPAA Business Associate Agreement) come first. | site dpa.html §3 |
| DSP-7 | Do you offer a data processing agreement and honour data subject requests? | Yes | A DPA on the customer's paper or ours, countersigned on request; the processor is Feerasta Industries LLC (Delaware). It commits to documented instructions, confidentiality, assistance with data subject requests, and breach notice within 72 hours. | F §1 legal entity; site dpa.html |
| DSP-8 | Is website visitor data minimised? | Yes | Company-level only, no person-level identification or data-broker enrichment, salt rotated daily, Global Privacy Control and Do Not Track honoured, nobody in the EEA, UK or Switzerland recorded, rows deleted after 90 days. The capture is inert today because its storage binding is not deployed. | F §9 Visitor tracking |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| GRC-1 | Is there an information security policy set and a named owner? | Partial | The operating rules are published rather than held as internal policy documents: the six controls on the verification page, the security page, the Sovereignty Pledge, acceptable use, privacy, DPA and subprocessor pages. The owner is the founder, Meer Feerasta. There is no formal ISMS or policy manual. | F §7; site verification.html, pledge.html, acceptable-use.html |
| GRC-2 | Is there a risk assessment process? | Partial | Risk is managed through a written and dated gap audit (docs/enterprise-trust-gap-2026-09.md) and the security review, both with owners and effort estimates, revisited each release. It is not a formal risk register under a named framework. | GAP §1 scorecard, §2 |
| GRC-3 | What is the legal entity and governing law? | Yes | Feerasta Industries LLC, a Delaware limited liability company; contracts are governed by the laws of the State of Delaware. Registration number and registered address are provided on request and written into the countersigned DPA. | F §1; site dpa.html Parties |
| GRC-4 | Which privacy regimes are you aligned to? | Yes | GDPR, PIPEDA and CCPA aligned in the product and the DPA; consent is captured to CASL windows; TCPA and 10DLC consent, calling windows and per-state recording-consent rules are defaults. Aligned, not certified. | site security.html Compliance posture; F §10 W3, W13 |
| GRC-5 | Do you publish what you do not have? | Yes | Yes: this pack answers no plainly (no SOC 2 report, no ISO 27001 or 42001 certificate, no external penetration test, no MFA yet, no uptime percentage, no second region). We do not volunteer missing certifications on marketing pages; we answer when asked. | F §1 fact 5; GAP §4 last paragraph |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| HRS-1 | Who has access to production, and are they bound by confidentiality? | Yes | The founder holds production access. The DPA commits that everyone with access is bound by confidentiality. There are no other employees with production access today. | F §1; site dpa.html §4 |
| HRS-2 | Are background checks performed on staff with access? | No | No background-check programme; the only person with production access is the founder and owner of the company. | F §1 |
| HRS-3 | Is security awareness training delivered? | Not applicable | No staff to train beyond the founder. The rule set applied in the build (never publish a claim the source of truth does not support, never bypass the approval gate, textContent not innerHTML) is written down in the repository and enforced by tests. | CLAUDE.md; F §1 |
| HRS-4 | Is access removed when a person leaves? | Yes | Inside the product: removing a teammate kills their sessions immediately; the last owner cannot be removed, so a tenant is never left without an administrator. Internally: console test accounts were deleted and a single named console account remains. | SR 4e; MEM console accounts |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| IAM-1 | What roles exist and how is least privilege enforced? | Yes | Workspace roles: owner, approver, member. Only an owner manages the team, keys and onboarding; a draft is approved by an owner or approver; a member can read. 26 owner-only writes were probed by approver and member sessions and all refused. Console roles: fd, accounts, compliance, viewer behind per-page capabilities. | F §10 W2; SR 4a to 4c; F §3b |
| IAM-2 | Is multi-factor authentication available? | Yes | Yes. Time-based one-time codes (RFC 6238) with any authenticator app, eight single-use recovery codes, a five-attempt limit per sign-in challenge, and a per-workspace setting that requires it for owners and approvers. Passwords are PBKDF2-SHA256 hashed, login is throttled to 10 attempts per address per 15 minutes, and sessions are HttpOnly, SameSite=Lax, Secure in production. | FEERASTA.md §10 W28; automation/mfa.mjs, automation/sessions.mjs |
| IAM-3 | Is single sign-on (SAML or OIDC) supported? | No | Not on the shared platform; it is listed on the Business tier as coming, not sold as shipped. On a Sovereign deployment the customer's own identity provider fronts the deployment they host. | F §10 W24 Business tier; site sovereign.html |
| IAM-4 | What is the session policy? | Yes | Portal sessions: cookie, HttpOnly, SameSite=Lax, Secure in production, 14-day expiry, token stored hashed. Console sessions: 12-hour expiry, SHA-256 hashed token, CSRF token injected into every POST form. Fetch-header CSRF is required on every cookie write (30 writes tested). | code server.mjs:31, 1156; F §3b; SR 3 |
| IAM-5 | Can a user list and revoke their active sessions? | Yes | Yes. Every user can list their active sessions with device and last-seen, revoke one, or sign out everywhere else; a password change or enabling two-factor authentication revokes every other session; removing a teammate kills that person's sessions. | FEERASTA.md §10 W28; automation/sessions.mjs |
| IAM-6 | How are API keys and admin credentials protected? | Yes | Tenant API keys are stored as hashes only, issued and revoked by owners, tenant-scoped, and dead immediately on revoke. The admin key is a header credential, never accepted in a query string in production, and the server refuses to boot on an unset or default admin key. | F §10 W1 client-keys, admin-key-guard; SR 7a, 9a to 9c; MEM URL key retired |
| IAM-7 | Is privileged access reviewed? | Partial | The admin key cannot act on an active tenant (403), only on demo tenants; every admin route was probed with five credential variants. There is no periodic access-review ceremony because there is one privileged person. | SR 4f, 9a |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| IPY-1 | Can customers get their data out in a standard format? | Yes | Full workspace export as JSON and an audit-log export from inside the product; CSV import for contacts and history. No ticket, no wait. | F §10 W11; site trust.html |
| IPY-2 | Are there documented APIs and integration points? | Yes | Tenant-scoped API keys, a public hooks endpoint per key, signed outbound webhooks, and a first-party MCP server (start_trial and tenant tools). Public description files: /agents.json, /openapi.json, /.well-known/mcp.json, /llms.txt. | F §10 W1, W12, W13; site agents.json |
| IPY-3 | Is there lock-in or an exit fee? | No | No lock-in clause and no exit fee; month to month. Cancel from the account (cancel at period end, resume before it ends), export, then schedule deletion. | F §2c sitewide terms; F §10 W24 billing cancel |
| IPY-4 | Do you rely on proprietary formats? | No | Postgres, JSON, CSV, HTTPS webhooks with HMAC-SHA256, MCP. Four npm dependencies and no build step in the platform. | F §3; PG |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| IVS-1 | Describe the production environment. | Yes | Node 22 ESM application under systemd on one Hetzner server in Germany, nginx with Let's Encrypt in front, PostgreSQL local to the box. Per-tenant agent containers run in Docker, one isolated container per workspace. | F §3; F §3c Docker; F §10 live proof |
| IVS-2 | Are tenants isolated at runtime as well as in the database? | Yes | Each workspace's agent runs in its own container with a per-tenant model credential; the database layer scopes every route by the session tenant, proven by a two-tenant adversarial sweep. | F §10 W1, W2; SR 1, 2 |
| IVS-3 | Is there network segmentation or a firewall policy you can document? | Partial | Only the web endpoints are exposed through the reverse proxy; the database is local and not published. A written firewall standard is not published; ask and we will describe the host configuration in writing. | F §3 |
| IVS-4 | Are production and test data separated? | Yes | Tests run against fresh schemas on scratch databases, with two independent guards that refuse any database not named like a test one, so the production database cannot be targeted by a stray variable. Demo tenants are never billed or emailed. | PG Safety; F §6 demo tenants |
| IVS-5 | Does the health endpoint leak information? | No | It used to publish row counts for every table to anonymous callers; that was removed on 2026-08-06 and is recorded so it is not reintroduced. | F §9 fixed 2026-08-06 |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| LOG-1 | Is there an audit trail of user and system actions? | Yes | Every approval, rejection, refused send, settings change, key mint or revoke, consent grant and deletion request lands on the tenant's audit ledger with attribution; there is no update or delete route on it. Checked daily for tampering. | F §7 verification.html; SR 11a, 11b; F §10 W11 |
| LOG-2 | Can the customer access the logs that concern them? | Yes | The audit log exports from inside the product at any time. Every workflow run produces a trace that includes the rules that did not match. | F §10 W11 audit-export; F §3a workflow engine |
| LOG-3 | How long are audit logs retained? | Yes | Three years, and the audit, consent and opt-out ledgers survive both the nightly retention purge and a tenant purge, because they are the proof a STOP was honoured. | SR 14c NEVER_PURGED; F §10 W15 7a9bb83 |
| LOG-4 | Is the platform monitored, and does an alert reach a person? | Partial | An independent monitor checks every five minutes with a public status page; a watchdog runs 150 assertions over cron health, ingest watermark and scheduler uniqueness and shows its verdict on the health page. The watchdog's email alert switch is off by default today, so a failing check is seen on the health page and the deploy gate rather than paged. | MEM watchdog; F §8 ALERT_SEND; site status.html |
| LOG-5 | Are refused actions logged as well as performed ones? | Yes | A message refused for missing consent, a blocked send, and a refused deletion each write an audit line, so there is a trace of what did not happen. | F §10 W11; SR 8b, 14a |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| SEF-1 | Is there a documented incident response process? | Yes | Published at /incident-response: detection, classification, containment, customer communication, post-incident review and the backup and restore facts. It is the plan, written for the customer to read. | site incident-response.html |
| SEF-2 | Within what time are customers notified of a personal data breach? | Yes | Without undue delay and in any event within 72 hours of becoming aware, to the affected customer, as the DPA states. Platform-wide incidents are emailed to every workspace owner and written on the status page while they last. | site dpa.html §4; site status.html |
| SEF-3 | How can a security vulnerability be reported? | Yes | security@feerasta.ai, with expectations at /.well-known/security.txt. Acknowledged within two business days. No paid bug bounty. | F §7 security.txt; site security.html Security reports |
| SEF-4 | Is evidence preserved for forensics? | Partial | The audit ledger is append-only in the application and retained three years; nightly database dumps give daily snapshots for 14 days locally and offsite. Server log retention beyond the application ledger is not published. | SR 11b; code deploy/backup.sh |
| SEF-5 | Are past incidents disclosed? | Yes | The verification page discloses that a component of our own system failed silently for six weeks; the security review and the source of truth record every security defect found and fixed with dates. The status page lists incidents as they occur. | F §7; F §9; site status.html |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| STA-1 | Do you publish your subprocessors? | Yes | Yes, with purpose and processing location, reconciled to what the code calls: Hetzner, Cloudflare, Hostinger, Twilio, ElevenLabs, Meta, Resend, Stripe, Google, Anthropic and OpenAI (only where the platform supplies the model), NVIDIA (demo only). Zapier and similar are explicitly not subprocessors. | F §3c; site subprocessors.html |
| STA-2 | Are customers notified before a new subprocessor processes data? | Yes | The page is updated before a new provider processes customer data, and anyone who asks is written to before a new subprocessor that handles personal data starts. | site subprocessors.html Being told |
| STA-3 | Do subprocessor contracts flow down your commitments? | Partial | Standard provider terms apply; where a provider's default would permit training we use the setting that disables it, and the subprocessor list records which. We do not hold negotiated flow-down contracts with these providers. | site dpa.html §5 |
| STA-4 | Is the software supply chain small and known? | Yes | The platform has four npm dependencies and no build step. The marketing site is hand-written HTML with no framework. | F §3; CLAUDE.md site conventions |
| STA-5 | Do you disclose which providers a specific customer's workspace uses? | Yes | Inside the product, a per-tenant provider disclosure shows exactly which subprocessors that workspace touches, driven by its own configuration and whether it brought a model key. | F §3c trust-floor.mjs; site security.html Sub-processors |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| TVM-1 | Is there a vulnerability management programme? | Partial | Security review with 53 adversarial tests and every finding fixed or documented as open with a repro; a public security.txt for external reports; four runtime dependencies to track. No scheduled third-party scanning and no external penetration test. | SR; F §7 |
| TVM-2 | What vulnerabilities are currently open? | Yes | Published: WhatsApp approver matches the last ten digits of a phone number (low, pre-existing); a draft automation accepts 10,000 conditions (low, storage only). Everything else in the review passed or was fixed the same day. | F §10 W15; SR Open list |
| TVM-3 | Are security fixes deployed promptly? | Yes | The two findings of the 2026-09-02 review were fixed and deployed the same day; the 2026-08-06 and 2026-08-07 fixes (webhook signatures, fail-closed webhooks, login throttle, admin gate) are dated in the source of truth. | F §9; F §10 W15 |
| TVM-4 | Is anti-malware or endpoint protection deployed on servers? | No | No anti-malware agent on the application server. The attack surface is the web endpoints and the per-tenant containers; the platform ships four dependencies. | F §3 |
| TVM-5 | Do you run a bug bounty? | No | No paid bounty. Reports to security@feerasta.ai are acknowledged within two business days and the fix is credited if the reporter wishes. | F §7 security.txt |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| UEM-1 | Are staff endpoints managed (MDM), encrypted and patched? | No | No mobile device management. Production is administered from the founder's own machine over SSH with key authentication; no laptop policy document exists to publish. | F §3 Deploy; F §10 Where things live |
| UEM-2 | Is customer data stored on endpoints? | Partial | Customer data lives on the server. Local restore drills use a throwaway container on the operator's machine and destroy it on exit; no standing local copy of production data is kept. | code deploy/restore-drill.sh |
| UEM-3 | Are customer-facing agents or devices you supply managed? | Yes | Feerasta Edge devices, where deployed, are scoped per device in the statement of work. The web widget is keyed to the page origin and CORS is scoped to the matched registered domain. | F §2a Edge; F §3a Widget |
| # | Question | Answer | Evidence, and the gap where the answer is no | Source |
|---|---|---|---|---|
| AI-1 | Which model providers process customer data? | Yes | Customer-facing conversations on the web widget, SMS, WhatsApp and voice are answered from the customer's approved rules through one resolver and make no model call. Model-backed drafting that waits for approval runs on a key the customer brings (their provider, their terms) or, where the platform supplies the model, on Anthropic or OpenAI, disclosed per tenant. With no key, drafting stays off and the product says so. | F §1 fact 1; F §3c; F §10 W1 model-auth |
| AI-2 | Is customer data used to train or fine-tune any model? | No | No, ours or a provider's. Because drafting runs on the customer's own key, the customer's provider retention and training terms apply to those calls and a zero-retention plan can be chosen with that provider; we do not claim zero retention as our own control. | site dpa.html §5; GAP §4 Training-data use |
| AI-3 | Does a human approve AI actions? | Yes | Agents propose; they do not execute. Anything that sends, pays, posts, transfers or replies is a draft until an owner or approver enables it. Draft-only is enforced in the server and in the agent container, not only in the prompt. Money is approved per item and closed accounting periods are refused regardless of who approves. | F §1 fact 3; F §10 W1 DRAFT_ONLY; SR 8a, 8d |
| AI-4 | Does the AI disclose that it is AI? | Yes | On the first turn of a call or text the agent says it is AI and names the business; on text the line repeats on the first reply to a sender every 30 days. The customer can switch it off and the switch is audited. The public ElevenLabs demo lines are separate and model-driven. | F §10 W11, W13; site trust.html Disclosure |
| AI-5 | How is the AI tested before and after go-live? | Yes | Before: sixteen fixed hostile probes plus up to twelve generated from the customer's own FAQ, and a backtest replay of uploaded history; a critical failure blocks activation. After: 100% of eligible production exchanges are scored, not a sample, and only a person can confirm a finding, which then becomes a permanent probe. Internal testing; no external red team. | F §3a; F §10 W1 backtest harness |
| AI-6 | What is your EU AI Act posture? | Yes | We are a deployer's tool. Our customer-facing agents are transparency-obligated systems under Article 50 (applied from 2 August 2026) and are designed to disclose. We do not build or sell systems for the Annex III high-risk uses (employment, credit, insurance, essential services). Posture, not certification. | GAP §4 Regulatory posture; site security.html AI disclosure |
| AI-7 | What is your Colorado and Quebec automated-decision posture? | Partial | The Colorado Automated Decision-Making Technology Act takes effect 1 January 2027. Where an automated outcome is a decline, a quote or a screening result, the message template carries a plain-language automated-decision notice and a route to a person; the notice is built into the templates and is not yet wired on every path. Quebec Law 25 disclosure is on by default. | F §10 W20 withAdmtNotice; F §10 Still not wired; GAP §4 Automated decisions |
| AI-8 | Are you aligned to the NIST AI Risk Management Framework or ISO 42001? | Partial | Informal alignment to NIST AI RMF (Govern, Map, Measure, Manage), mapped by us and not audited by anyone. No ISO 42001 certificate. Safety outranks configuration: a caller who asks for a human, complains or asks for regulated advice is handed to a person on every channel ahead of anything configured. | F §1 fact 4; GAP §4 Regulatory posture |
| AI-9 | Can the AI answer a question nobody configured? | No | No. It takes a contact instead of guessing. The same question gets the same answer every time, and an owner can read exactly what their agent will say. This is a real limitation and we state it. | F §1 fact 1 |
The forty questions that appear on almost every screening questionnaire, each pointing at the record above that answers it, so the short set and the long set cannot disagree.
| # | Question | Answer | Record |
|---|---|---|---|
| 1 | Do you have an independent third-party audit report (SOC 2 or ISO 27001)? | No | AA-1: Do you hold an independent audit report or certification (SOC 2, ISO 27001, ISO 42001)? |
| 2 | Has a penetration test been performed in the last 12 months? | No | AA-5: Has an external penetration test been performed? |
| 3 | Is there a documented information security policy? | Partial | GRC-1: Is there an information security policy set and a named owner? |
| 4 | Is there a named individual responsible for security? | Partial | GRC-1: Is there an information security policy set and a named owner? |
| 5 | Is a formal risk assessment performed? | Partial | GRC-2: Is there a risk assessment process? |
| 6 | Are background checks performed on personnel with access to client data? | No | HRS-2: Are background checks performed on staff with access? |
| 7 | Is security awareness training provided? | Not applicable | HRS-3: Is security awareness training delivered? |
| 8 | Are personnel bound by confidentiality agreements? | Yes | HRS-1: Who has access to production, and are they bound by confidentiality? |
| 9 | Is access revoked upon termination? | Yes | HRS-4: Is access removed when a person leaves? |
| 10 | Is role-based access control implemented? | Yes | IAM-1: What roles exist and how is least privilege enforced? |
| 11 | Is multi-factor authentication required for access to client data? | Partial | IAM-2: available to every user; each workspace owner decides whether to require it for owners and approvers |
| 12 | Is single sign-on supported? | No | IAM-3: Is single sign-on (SAML or OIDC) supported? |
| 13 | What are the password and session requirements? | Yes | IAM-4: What is the session policy? |
| 14 | Are privileged accounts reviewed? | Partial | IAM-7: Is privileged access reviewed? |
| 15 | Is data encrypted in transit? | Yes | CEK-1: Is data encrypted in transit? |
| 16 | Is data encrypted at rest? | Partial | CEK-2: Is data encrypted at rest? |
| 17 | How are encryption keys managed? | Partial | CEK-4: How are cryptographic keys managed and rotated? |
| 18 | Where is client data stored and processed? | Yes | DCS-1: Where is customer data physically processed and stored? |
| 19 | Can data residency be guaranteed in a specific country? | Partial | DCS-4: Can data stay in a specific country? |
| 20 | Is client data logically segregated from other clients? | Yes | AIS-6: Is cross-tenant access prevented at the application layer? |
| 21 | Is client data used for any purpose other than providing the service? | No | DSP-1: Is customer data used to train models, yours or a provider's? |
| 22 | Can client data be returned or destroyed on termination? | Yes | DSP-3: How is deletion handled? |
| 23 | Is there a data retention schedule? | Yes | DSP-4: Is there a retention policy the customer controls? |
| 24 | Is a data processing agreement available? | Yes | DSP-7: Do you offer a data processing agreement and honour data subject requests? |
| 25 | Are backups performed and tested? | Yes | BCR-2: Have you proven a backup can be restored? |
| 26 | Is there a business continuity and disaster recovery plan with RTO and RPO? | No | BCR-4: Do you publish recovery time and recovery point objectives? |
| 27 | Is the environment redundant? | No | BCR-3: Is the platform redundant across servers or regions? |
| 28 | Is there a documented incident response plan? | Yes | SEF-1: Is there a documented incident response process? |
| 29 | Within what timeframe are clients notified of a breach? | Yes | SEF-2: Within what time are customers notified of a personal data breach? |
| 30 | Are security events logged and monitored? | Partial | LOG-4: Is the platform monitored, and does an alert reach a person? |
| 31 | Are audit logs retained and protected from modification? | Yes | LOG-3: How long are audit logs retained? |
| 32 | Is there a vulnerability management programme? | Partial | TVM-1: Is there a vulnerability management programme? |
| 33 | Are systems patched within defined timeframes? | Yes | TVM-3: Are security fixes deployed promptly? |
| 34 | Is anti-malware deployed? | No | TVM-4: Is anti-malware or endpoint protection deployed on servers? |
| 35 | Is there a formal change management process? | No | CCC-4: Is there a formal change advisory or approval board? |
| 36 | Are changes tested before production? | Yes | CCC-2: Are changes tested before release? |
| 37 | Are secure coding practices followed? | Partial | AIS-1: Do you follow a secure development practice for application code? |
| 38 | Are fourth parties (subprocessors) identified and managed? | Yes | STA-1: Do you publish your subprocessors? |
| 39 | Are endpoints managed and encrypted? | No | UEM-1: Are staff endpoints managed (MDM), encrypted and patched? |
| 40 | Does the service use AI, and is client data used to train models? | No | AI-2: Is customer data used to train or fine-tune any model? |
Domains follow the Cloud Security Alliance Cloud Controls Matrix v4 (197 control objectives in 17 domains; the CAIQ v4 is the yes/no questionnaire built on it). The short set follows the shape of the Shared Assessments SIG Lite, the roughly 125-question screening set. The answer shape, a one-line verdict followed by the evidence, follows the trust pages we think read best: Postmark, Linear and Vercel. Unlike those, the No rows are published here rather than behind a request.
Last reviewed 3 September 2026. Related: security, incident response and backups, trust, subprocessors, DPA, status. Questions: hello@feerasta.ai.