Security
Tenant isolation the application cannot accidentally bypass
Swift Grow and Swift Social
Four layers, and the innermost one is not code we wrote
Layer 1
Request
Organization context comes from the session, never the request
There is no organization identifier in a URL or form field that could be swapped for someone else's. The active organization is resolved from the signed-in session and re-validated against that user's memberships on every request.
Layer 2
Query
Application queries filter by organization
Every read and write is scoped explicitly. This is the layer that would be doing the work in most applications — here it is the second line, not the only one.
Layer 3
Database
Row-level security policies decide what is visible
Requests run against the database as a restricted role carrying the caller's identity, so policies actually apply. A query that forgot its filter returns nothing it should not see, because the database refuses rather than trusting the application.
Layer 4
Schema
Isolation ships with the table, not after it
Every tenant table carries a non-null organization column and its access policy in the same database migration that creates it. A table without a policy does not reach production.
Swift Onboard
Caregiver files, kept to the agency they belong to
No query without an agency
Every read and write must name the agency it belongs to, or it is refused before it reaches the database. A lookup that forgot fails loudly instead of returning another agency's caregivers.
Documents under the agency's own path
Uploaded files are stored under the agency they belong to and opened through short-lived signed links, never a public address.
Access from your Swift Pivot account
Who in your office can open Onboard, and which parts, is set on your account's Members page; Onboard checks it on every request.
Caregivers in their own session
Caregivers sign in to their agency's portal only, with a session that cannot open the office's side or another agency's portal.
Practices
The specifics, without the buzzwords
Credentials encrypted at rest
The social account logins an agency sends us are sealed with authenticated encryption before they touch the database. Our staff open one only to connect or reconnect that account, every opening is logged, and it is deleted once the account is removed.
Invitations cannot be replayed
Invite links carry a high-entropy token, and only its hash is stored. Each is bound to the invited email address, expires in seven days, and works exactly once.
Webhooks verify their sender
Inbound webhooks are rejected unless the payload signature checks out. An endpoint that writes contacts without verifying its caller is an open door into your database.
Background jobs fail closed
Scheduled work authenticates with a shared secret. With no secret configured, the endpoint rejects everyone — including its own scheduler. Broken and loud beats open and quiet.
Consent evidence is append-only
The permission to update or delete a consent record does not exist for anyone in the application. Not disabled in the interface — absent from the database.
Roles enforced on the server
Owner, admin and member checks run server-side on every action. Hiding a button is a courtesy; the check behind it is the control.
Authentication we did not invent
Sign-in, password hashing, session tokens and optional Google sign-in are handled by a managed authentication provider. Rolling our own would be the riskiest code in the product.
Encrypted in transit
All traffic to the application and between the application and its providers runs over TLS. Uploaded media is stored under unguessable paths scoped to your organization.
Deletion actually cascades
Deleting a contact removes its events and consent records with it, so a right-to-erasure request does not leave orphaned evidence behind.
Not yet
What we do not claim
Security pages usually list only strengths, which makes them useless for deciding anything. Here is the other half, so you can weigh it properly.
SOC 2 or ISO 27001 certification
Not held. The controls described above are real; the third-party audit attesting to them is not something we have paid for yet.
HIPAA business associate agreement
Not offered for this product. It is a marketing system and our terms ask you to keep clinical data out of it.
Independent penetration test report
Not commissioned yet.
Contractual uptime guarantee
Not included by default. It can be negotiated as part of your agreement.
Customer-managed encryption keys
Not supported.
Data processors
Who else touches your data
Vercel Inc.
Application hosting and content delivery
The Swift Pivot account and every product · United States
Supabase, Inc.
Sign-in, and the database for Swift Grow and Swift Social
The Swift Pivot account, Swift Grow, Swift Social · United States
MongoDB, Inc. (MongoDB Atlas)
Swift Onboard's database: caregiver applications, forms and review records
Swift Onboard · United States
Cloudflare, Inc. (R2)
File storage: Swift Onboard's documents (files caregivers upload, and exports), and the logos, post images and videos, and email images of the account, Swift Grow and Swift Social
The Swift Pivot account, Swift Grow, Swift Social, Swift Onboard · United States
Blotato
Social media publishing to connected accounts
Swift Social · United States
cron-job.org
Scheduled task trigger (carries no customer data)
Swift Grow, Swift Social · Germany
Amazon Web Services (SES)
Email delivery: campaigns, caregiver notices and account emails
Swift Grow, Swift Onboard, the Swift Pivot account · United States
Twilio Inc.
SMS delivery and carrier registration (A2P 10DLC and toll-free verification)
Swift Grow, Swift Onboard · United States
Report something, or ask something
Questions first? contact@swift-pivot.com