Security & sub-processors
Quorum is deployed into infrastructure you or your vendor controls, and reads only what the connections you create allow. This page lists every third party that can receive data, and the controls that are actually implemented in the software.
Sub-processors
Every entry below is conditional: Quorum contacts a provider only when you have connected it. A workspace that connects only Microsoft never sends a byte to Google, Zoom, Slack, or any model vendor.
| Sub-processor | Purpose | Data it receives | When |
|---|---|---|---|
| Microsoft (Graph API) | Reads Outlook calendars and Teams attendance for the tenant you connect | Meeting metadata, invitee lists, join/leave records | Only if you connect Microsoft |
| Google (Calendar & Meet APIs) | Reads Google Calendar invites and Meet attendance via a service account you create | Meeting metadata, invitee lists, join/leave records | Only if you connect Google |
| Zoom | Reads attendance for meetings hosted on Zoom | Participant join/leave records | Only if you connect Zoom |
| Slack | Delivers verdict DMs, pulse surveys, and the weekly digest | Employee work emails (to match accounts), message content Quorum sends | Only if you install the Slack app |
| Google (Gemini API) and/or OpenAI | Classifies who needs to attend a meeting live, and drafts series recommendations | Meeting title, agenda, invitee roles — never sensitive-meeting content, never names of people being evaluated | Only if your operator sets an AI key. Without one, series recommendations and the weekly audit fall back to deterministic rules and nothing is sent to any model — the per-invitee live/async classification does not run at all, because there is no rule that decides who has to be in a room |
| GitHub (signed webhooks and count-only API queries) | Counts comments on pull requests and issues so a thread that has outgrown async can be spotted | Webhook payloads arrive from GitHub. Quorum uses participant logins, titles, timestamps and state, then requests current comment totals through GraphQL. API queries exclude comment bodies and code; comment text is not stored or sent to AI | Only if you configure a repository connection and add its webhook |
| Resend | Delivers sign-in links and verification emails | Recipient email address and the link | Only if your operator configures email delivery |
Implemented controls
- Provider credentials are encrypted at rest with AES-256-GCM before they touch the database. Plaintext tokens are never stored and never logged. The encryption key lives in the server environment, not in the database.
- Tenant isolation is a query-level invariant. Every read is scoped to the signed-in admin’s workspace; a route without that scoping is treated as a blocking defect in review.
- Sign-in links are hashed (SHA-256), single-use, and expire in 15 minutes. Passwords, when set, are stored with scrypt and only become usable after email verification.
- Company SSO is an OIDC preview for test-provider evaluation. Signatures, issuer, audience, expiration, nonce and browser-bound PKCE are checked. Live acceptance with each identity provider remains open. Choosing SSO routes sign-in to the configured identity provider. Deactivate the person in Quorum to revoke local sessions and access. IdP offboarding alone does not revoke existing local sessions or disable other sign-in methods.
- Every Slack request is signature-verified, and every interaction is scoped to the acting Slack user’s own employee record and workspace.
- Admin actions are recorded in an audit trail — who changed a policy, a cost band, a person’s access, or ran a job, and when. Visible to you in Settings.
- State-changing requests must come from this origin. The session cookie is SameSite=Lax and every mutating request is refused if the browser reports a different origin — including the sign-in routes, which create a session rather than requiring one and so are not protected by the cookie policy alone. Webhooks are exempt and authenticated by signature instead.
- Outbound URLs a workspace supplies are validated. An OIDC issuer or webhook URL must be https, must not embed credentials, and must not resolve to a private, loopback, or link-local address — including the cloud metadata endpoint. The discovery document is checked the same way, since it names three further endpoints.
- Retention is enforced by a daily job that deletes data past your configured windows. See the Privacy notice.
Compliance status
Quorum does not currently hold a SOC 2 or ISO 27001 certification. We would rather tell you that than imply otherwise on a page your security team is reading. What is available today is this document, the control list above, and the source-level behaviour it describes — all of which are verifiable against a deployment.
If your procurement process requires an attested report, a completed security questionnaire, a signed DPA, or a penetration-test summary, raise it during evaluation so expectations are set before a contract rather than after.
Data residency
Quorum stores everything in a single PostgreSQL database. Its region is determined by where your deployment runs, so residency is a decision you make at install time rather than a setting you request from a vendor. The sub-processors above process data in their own regions under their own terms.
Reporting a vulnerability
Report suspected vulnerabilities to your workspace administrator or the team that operates your deployment. Please include reproduction steps and avoid accessing data belonging to other workspaces while testing.