Skip to content

Trust

Diligence, in one page

Last reviewed Sep 15, 2026 · Ferrier Industries LLC

If you run a studio, putting PaloWorks in front of your clients means handing it your client list, your signed agreements, and your billing history — and doing it on behalf of people who did not choose us. This page answers the questions that decision actually turns on, including the four a procurement review will find on its own.

The eight questions a security review asks

Short answers, each with the limit of the answer attached and a link to the long version.

  1. Who am I actually contracting with?

    Ferrier Industries LLC, a US limited liability company. PaloWorks is built and operated by one person. There is no support tier, no account management layer, and no separate engineering team — which means the person who answers your security questionnaire is the person who wrote the code it asks about.

    Who builds this

  2. How do accounts and sign-in work?

    Email and password, a one-time link by email, a passkey (Face ID, Touch ID, Windows Hello or a security key), or Google where it is configured. Two-step verification with an authenticator app is available to every account, with single-use backup codes, and a workspace owner can require it for everyone in the workspace. Passwords are hashed with scrypt under a per-user salt, so we cannot read them. Sessions are database rows rather than self-contained tokens, which means signing out or resetting a password ends access immediately instead of waiting for a token to expire. Sign-in, signup, and password-reset requests are rate limited per client against a shared Postgres counter, so the limit holds across serverless instances.

    The limit of this: There is no SAML or OIDC single sign-on and no SCIM provisioning.

    Full detail on accounts and sessions

  3. How is my data kept apart from other customers'?

    One database, with every query that touches customer data filtered by workspace id. An id arriving in a form is re-resolved through its verified parent before anything is written, so posting someone else's invoice id does not reach someone else's invoice. Where a write could span tenants, the tenant filter is part of the same statement as the write rather than a separate check beforehand.

    The limit of this: This is enforced by code convention, review, and tests — not by database row-level security. It is a real control and a real discipline, but it is not a wall. Cross-tenant defects have been found by adversarial review before release and fixed; they are named in the changelog rather than folded into “various improvements”.

    Full detail on tenant isolation

  4. What happens to card data?

    It never reaches us. Card entry happens in Stripe's own hosted interface. Client invoice payments are direct charges on your connected Stripe account, with no PaloWorks fee taken, so the money settles into your account and never sits in a PaloWorks balance. What our database stores is a Stripe customer id, a subscription id, and a connected account id — references, not instruments. There is no schema field that could hold a card number.

    The limit of this: Stripe is a PCI DSS Level 1 service provider. Because cardholder data never reaches our systems, PaloWorks is outside PCI scope rather than certified within it. Those are different claims and we make only the first.

    Full detail on payments

  5. How safe are the links I send my clients?

    Invoices, scopes, intake forms, and contracts are shared by URL so your client never needs an account. Each token is 20 bytes from the operating system's cryptographic random source — 160 bits, not guessable at any request rate. Those pages are served noindex, nofollow, noarchive, so a link forwarded into a crawlable inbox or wiki stays out of search results. You can rotate a link, which breaks the old URL, or revoke it outright, and both are written to your workspace audit log.

    The limit of this: A share link is a bearer credential: anyone holding the URL can open the document, with no password. That is deliberate, and it means a forwarded link is a shared document until you revoke it. Client statement links are the one exception to the token scheme — they are addressed by an HMAC signature over the client id, so they cannot be revoked individually.

    Full detail on share links

  6. Can I get my data out, and can I get it deleted?

    Yes to both, without asking us. A workspace owner can export the entire workspace as one JSON file — clients, projects, intake responses, scopes, contracts, time entries, invoices, and line items — plus CSV exports for invoices, clients, time, and reports. Deleting a workspace cascades through every related record immediately and irreversibly. What survives is a single tombstone row recording that the deletion happened, the counts involved, and who confirmed it; it holds no client names, contract text, or financial detail, and we remove it on request.

    The limit of this: There is no recycle bin and no undo on deletion, so export first. Deleting your PaloWorks workspace does not delete anything held by Stripe — close that account through Stripe.

    What we keep, and for how long

  7. Who else can touch the data?

    The subprocessors listed below, and no one else. We notify workspace owners by email at least 30 days before adding one, and the DPA gives you a right to object.

    Subprocessor terms in the DPA

  8. How do I report a vulnerability?

    Email security@paloworks.com. A person who works on the code reads every report and tells you how serious it is and what we intend to do about it. We will not pursue good-faith research that stays inside the published scope, and we will credit you when the fix ships if you want the credit.

    The limit of this: We do not pay bounties. We read every report and fix what is real, but there is no money attached.

    Scope and ground rules

Who processes data alongside us

The third parties that can touch what you put into PaloWorks. The ones marked below process nothing at all unless the corresponding key is configured; the rest are load-bearing and always in the path. Each entry’s data scope and processing location are on the security page.

  • Vercel Inc.Application hosting, serverless execution, and CDN delivery.
  • Neon Inc. (managed PostgreSQL)Primary database.
  • Stripe, Inc.Subscription billing, and Stripe Connect payment processing and payouts for your client invoices.
  • Resend (Plus Five Five, Inc.)Only when enabledTransactional email: invoice and scope share links, reminders, team invitations, password resets, and verification emails.
  • PostHog, Inc.Only when enabledProduct analytics — which features get used, and where people get stuck.
  • Google LLCOnly when enabledOptional "Sign in with Google" authentication.
  • Anthropic PBCOnly when enabledAI-assisted drafting — suggesting scope deliverables, pricing anchored on your own past work, and draft client messages.

Full subprocessor table — data handled, processing region, and status for each.

What we don’t have, and what we do instead

A vendor page that lists only strengths tells you nothing, because every vendor page lists only strengths. These four are the ones a studio’s review process finds, so here they are first.

No SOC 2 or ISO 27001
There is no audit in progress and no report to send you. Instead of a certificate, every control we claim is published with the file it lives in, so your reviewer can check the claim rather than the badge. If your process requires a report to proceed, we are not yet the right vendor and we would rather say so before you invest a week in us.
No third-party penetration test
No external test has been performed. What we do instead is adversarial review of each release by a reader who did not write it, with the findings published in the changelog — including the cross-tenant write and the public endpoint that review caught. That is weaker than an independent test. It is not nothing, and we would rather show you the bugs than the absence of them.
No SSO
Sign-in is each person's own: password, a one-time email link, a passkey, or Google. If your studio's policy is that every tool must sit behind your identity provider, PaloWorks does not meet it today. What is in place: two-step verification a workspace owner can require for every member, passkeys, scrypt password hashing, an eight-character server-enforced minimum, database-backed sessions you can end instantly, and rate limits tight enough to make credential stuffing impractical.
No tested disaster recovery
Backups are the automatic ones our database provider takes. We have not run a documented restore drill, so we will not quote you a recovery time or recovery point objective we have never measured. What we give you instead is a full export you control, available at any moment, which is the recovery path that does not depend on us being available.

The complete list, including the less flattering entries, is under what we don’t claim on the security page.

What we can send your reviewer today

Available now

  • A signable Data Processing Addendum.
  • The security posture above, with source files named for each control.
  • A written subprocessor list with 30 days’ notice before it changes.
  • A full export of your workspace data, at any time, without asking us.
  • Written answers to a security questionnaire, from the person who wrote the code.

Not available

  • A SOC 2 Type I or Type II report.
  • A third-party penetration test report.
  • A tested recovery time or recovery point objective.
  • SSO, SCIM provisioning, or enforced multi-factor authentication.
  • A contractual uptime commitment with service credits.

Ask us something this page didn’t answer

Security questions, vulnerability reports, and anything about how a control actually works: security@paloworks.com. Data requests, DPA signature, and privacy questions: privacy@paloworks.com.

See also the Terms of Service, the refund policy, and the changelog, where security fixes are listed rather than folded into “various improvements”.