Trust & security

Security at AcuityRFP

You trust us with your security policies, audit reports, and past questionnaires. This page explains the technical and organizational controls we use to protect them.

Last updated: November 6, 2026

Our commitments

  • Your data never trains AI models

    Our AI providers process your data strictly to fulfill your requests. We use them only under paid tiers, terms or account settings that exclude training, and search embeddings run with zero data retention. No customer data, prompts, or uploaded documents are used to train or improve AI models. Production refuses to process documents until those settings are confirmed.

  • Your data stays in your organization

    Every record is scoped to its organization, and the database itself enforces access boundaries across organizations. This isolation is tested automatically with every database change.

  • Answers you can verify

    Every drafted answer cites the exact passages it came from. When your sources don't support an answer, the question is designed to be marked Needs input rather than guessed, and expired documents are automatically excluded from retrieval.

  • You stay in control

    Only answers a person approved go into a customer-facing export. Deleting a document removes its file, its extracted text, and its search embeddings from active storage.

How we protect your data

Tenant isolation

Customers share application infrastructure but never each other's data. Every table carries an organization ID, and PostgreSQL Row-Level Security (RLS) enforces membership checks on every read and write directly inside the database, not just in application code. Vector and keyword searches over your documents are filtered by organization inside the database query.

An automated isolation test suite signs in as users of different organizations and attempts cross-organization reads and writes across every data type on every database change. We also run deliberately broken copies of each new security rule to verify that our test suite catches regressions.

Encryption and storage

  • In transit and at rest: All network traffic is encrypted with TLS (1.2/1.3). All database records and stored files are encrypted at rest using AES-256.
  • Private file storage: Uploaded files live in private storage buckets and are accessed only through short-lived, cryptographically signed URLs.
  • Integration token encryption: OAuth tokens for connected tools (Slack, Google Drive, SharePoint, and OneDrive) are encrypted at the application layer using AES-256-GCM with keys held outside the database. Only isolated background workers can decrypt them; they are never exposed to the browser.
  • Secret management: Administrative keys and secrets live strictly in server-side environment variables and never reach client browsers.

How AI is used

Answers are drafted by large language models using only your organization's knowledge base, prioritizing your approved answer library first, followed by your uploaded documents. Text a person on your team types when regenerating or re-drafting answers is also used, and is cited as its own source. Questionnaires in a different language than your knowledge base are translated to search your records and answered in the questionnaire's native language. Each drafted response includes source citations and a confidence score, and automated checks take out details no source contains.

Low-confidence answers are flagged for human review, and only approved answers go into a customer-facing export. The internal review draft can include unapproved drafts, and says that it's internal. The Slack and Microsoft Teams bots write an answer from your approved library and current documents when a member asks, with citations, visible only to that person.

Document processing and drafting run in asynchronous background jobs rather than in your browser session. We do not log document contents or raw prompt payloads in production application logs. Error reports are automatically stripped of request data, email addresses, tokens and quoted text before they reach our error monitoring provider, though an error message may still contain a short fragment of text.

Access control and audit

  • Role-based access control (RBAC): Four distinct roles (Owner, Admin, Editor, Viewer) are enforced at the database layer.
  • Single sign-on (SSO): SAML SSO is supported for Okta, Microsoft Entra ID, Google Workspace, and other identity providers. Organizations can enforce SSO-only sign-in while retaining a secure break-glass owner login.
  • Two-factor sign-in: People can protect their accounts with an authenticator app and single-use recovery codes. Owners can require it for admins or for all members; SSO sign-ins meet the requirement through the identity provider.
  • Sign-in protection: An email address must be verified before an account can be used. New passwords have at least 15 characters and are checked against known breached passwords; only the first five characters of a hash leave our servers. Repeated failed sign-ins trigger lockouts, and sign-up includes a bot check.
  • Sessions: Sessions end after 24 hours without use and at most 14 days after sign-in. People can see their signed-in devices, sign out any of them, and get an email about a sign-in from a new browser or a change to their password or two-factor settings.
  • Audit logging: An append-only audit log records answer approvals, exports, file downloads, deletions, membership and role changes, integration connections, and security setting updates. Owners and Admins can review audit logs at any time.
  • Browser extension security: Our browser extension operates strictly with the signed-in user's own session and permissions, inserts only approved answers, and maintains no standing read access to the websites you visit. Accounts with two-factor sign-in can't sign in to it yet.

Web pages you add

When you add a public web page to your knowledge base, a background worker fetches it once (and weekly thereafter, if enabled). It identifies itself with the AcuityRFP-Importer user agent and respects robots.txt directives.

  • SSRF protection: The fetcher connects strictly to public IP addresses. Private, loopback, link-local, and cloud metadata addresses are blocked before connection and re-verified after any HTTP redirects. No cookies or credentials are sent.
  • Prompt injection defense: Text extracted from external web pages is isolated and delimited as untrusted data to defend against indirect prompt injection.

Data retention and deletion

  • Document deletion: Deleting a document immediately removes its original file, extracted text, and vector embeddings from active databases and storage buckets.
  • Organization deletion: Owners can delete their entire organization in Settings. Following a 7-day grace period (during which any Owner can cancel), all active organization records and stored files are permanently deleted. Error reports held by our error monitoring provider expire automatically within 90 days.
  • Backups: Any database backups expire automatically on our database provider's schedule, and deleted data leaves them when they do.
  • Accounts: Deleting an organization removes people from it. Their accounts are deleted on request.
  • Data residency: Customer data is stored in the primary region specified in your agreement. Regional hosting (such as EU-only residency) or dedicated database instances are available on request. Error reports are processed in the United States unless we agree otherwise.

Subprocessors

We use a small set of subprocessors for hosting, background processing, AI, error monitoring, email, bot protection, and payments. Optional integrations (Slack, Microsoft Teams, Google Drive, SharePoint, and OneDrive) receive data only if your organization connects them. See the full subprocessor list for each provider, its purpose, and the data involved, and for how we announce changes.

Compliance

We are preparing for a SOC 2 Type I audit, to be followed by SOC 2 Type II. No audit has started yet. Our internal security controls are mapped to the AICPA Trust Services Criteria, and our attestation report will be shared under NDA once available. Customers can request our security documentation, Data Processing Agreement (DPA), and completed security questionnaires from our security contact.

Reporting a vulnerability