Security whitepaper

1. Security overview

re.fer is an organizational intelligence platform. We read collaboration metadata from the customer’s connected tools (Slack, GitHub, Jira, Google Calendar, Google Drive, Notion, Linear, GitLab) and turn it into a calm read on how work flows. Rehoboam, our in-product engine, narrates the result for the customer.

What we read: who collaborates with whom, in which channel or repo, at what cadence, with what response latency. What we do not read: message content, document content, calendar event content, file content, or direct-message metadata. That line is part of the architecture, not a setting an admin can flip.

This whitepaper documents the control posture behind that promise. It is current as of June 2026 and is reviewed each quarter.

2. Access control

Database isolation: every customer-scoped table in Supabase has row-level security policies that key off the requester’s org_id. A continuous integration test, org_isolation, fails the build if a query path can return rows from another org. There is no internal way around row-level security at the application layer.

Application roles: re.fer ships three workspace roles. Owner has full administrative scope inside the workspace. Admin can manage members, connectors, and settings. Viewer can read network shape and aggregate metrics but cannot see person-scoped insights. The boundary is enforced at the database and the API.

Platform admin: a small set of re.fer staff hold the platform_admin scope, used for support and incident response. It is a separate allowlist, decoupled from your workspace roles, and every cross-org access is recorded in your activity log.

3. Authentication

Identity is handled by Supabase Auth. Passwords are hashed with bcrypt. New passwords are checked against the HaveIBeenPwned breach corpus, and known-leaked passwords are rejected at the sign-up form. A real-email gate blocks disposable and role-based addresses on registration.

Sign in with Google is available to every user. SAML and OIDC single sign-on against your own identity provider, and SCIM user provisioning, are Enterprise features that we configure with your team.

Session tokens are short-lived and refresh tokens rotate. Logout invalidates the refresh family.

4. Encryption

In transit: every connection to re.fer uses TLS 1.2 or higher. HTTP Strict Transport Security is enabled with a 1-year max-age. Internal service-to-service hops are also TLS terminated.

At rest: Supabase-managed AES-256 protects the primary database and storage buckets. Backups carry the same encryption.

On the roadmap: customer-managed keys (CMK) for Enterprise customers, scoped per workspace. We will publish the key management design before we open the feature.

5. Data segregation

Every customer workspace is isolated by org_id at the row level. Row-level security policies live next to the schema, are version-controlled, and ship as part of every migration.

A regression test, org_isolation, runs in CI on every pull request. It seeds two synthetic orgs, exercises every public read path as each org’s user, and asserts zero cross-org rows leak. A failure blocks merge.

There is no shared cache that holds personal data across orgs. Rate-limit counters in Upstash are keyed by org_id and IP and contain no personal data.

6. Audit logging

A customer-facing audit log is retained for 90 days. It records sensitive actions (member added, role changed, connector connected or revoked, export requested, deletion requested, AI key changed) with actor, target, and timestamp.

A separate ai_call_log table records each LLM call with model, provider, token count, and cost. It exists for usage analytics and budget alerts and never stores the prompt or completion body.

Both logs are read-only from the application. Owners can export the customer-facing audit log at any time.

7. Backups

Backups are provided by Supabase point-in-time recovery. The default window is 7 days for the production project, extended to 14 days for Enterprise customers on request.

Restores are tested on a quarterly cadence against a staging project to confirm recovery time objective and recovery point objective remain in scope.

8. Subprocessors

The current list of third-party subprocessors, with purpose, location, and link to each provider’s DPA, is published at /legal/subprocessors.

Customers are notified by email at least 30 days before any addition and may object during that window.

9. Compliance status

re.fer is pre-audit. We have no certifications to claim yet. We do not list logos we have not earned.

SOC 2 Type I is the first formal milestone we are building toward. We are aligning controls to the AICPA Trust Services Criteria for security, availability, and confidentiality. Once we sign the auditor engagement letter, we will publish the auditor name and target completion window on this page.

GDPR alignment is handled through the DPA at /legal/dpa, the international transfer clauses in section 10 of that document, and the Standard Contractual Clauses with each EU subprocessor.

CCPA: re.fer does not sell personal information and does not share it for cross-context behavioral advertising. California residents can exercise access, deletion, and correction rights through privacy@userefer.app.

10. Vulnerability management

Responsible disclosure: security researchers can report a finding to security@userefer.app. The /.well-known/security.txt file points to the same address.

There is no formal bug bounty yet. We respond to confirmed reports with acknowledgement, a fix timeline, and credit on a public disclosures page once a fix ships, where the reporter consents.

Dependencies are scanned in CI. Critical and high CVEs block deploy and are patched on a 7-day SLA. Medium findings are patched on the next regular release.

11. Incident response

Detection draws on Supabase database alerts, Vercel runtime monitoring, Upstash rate-limit anomalies, and customer reports.

On detection, a responder is paged, triage begins inside 30 minutes during business hours and 60 minutes off-hours, and a contained event is moved to remediation.

For confirmed personal data breaches under GDPR Article 33, affected customers are notified by email within 72 hours of confirmation. The notice includes the nature of the breach, categories of data subjects affected, likely consequences, and the steps re.fer is taking. A public version of the policy lives at /legal/incident-response.

A post-mortem is published to affected customers within 14 days of resolution.

12. Business continuity

re.fer runs single-region today, on AWS us-east-1 through Supabase, with Vercel’s edge network in front of the application. The realistic recovery time objective for a single-region event is 4 hours.

Multi-region active-passive failover is on the roadmap and is gated on Enterprise customer demand and the customer-managed key work.