Security & Trust Overview

Status: DRAFT — pending licensed-attorney review. Not yet published; not yet in force. Version 1.0-draft · Grounded in docs/legal/FACT_REGISTER.md (code facts verified 2026-07-23; owner decisions D1–D14 updated 2026-08-04) Intended effective date: 2026-08-04 · Last updated: 2026-08-04 — takes effect when published, which happens only after attorney sign-off.

Publisher: Single Case Informatics, PBC — a Delaware public benefit corporation ("Single Case Informatics," "SCI," "we," "us," "our"). Service: SingleCase.ai. Security contact: [email protected] — put "Security" in the subject line (see §10).

1. What this page covers

SingleCase.ai is a research platform for designing, running, and publishing single-case experimental design (SCED) research. It stores account and identity data, research protocols, research-participant data, IRB records, behavioral observation data, and AI-assisted analysis outputs, and it sends portions of that data to third-party AI providers to deliver its AI features (see our AI Use / Transparency Notice and Privacy Policy for exactly what is sent).

This overview describes how that data is hosted, encrypted, isolated, access-controlled, logged, backed up, and defended, and where our current posture has known limits. It reflects verified facts in docs/legal/FACT_REGISTER.md (§B infrastructure, §D architecture/isolation/ encryption, §E authentication/roles, §F honesty-blockers).

2. Posture at a glance

Read this table as an honest snapshot, not a certification. Details follow in the sections cited.

3. Hosting infrastructure

SingleCase.ai runs entirely on three third-party cloud providers, all processing data in the United States (Fact Register §B.1):

• Vercel (Vercel Inc.) — application hosting, serverless functions, scheduled jobs, and the document-parsing runtime. Effectively all application request/response traffic passes through Vercel.
• Supabase (Supabase, Inc.) — authentication, the primary application database (PostgreSQL), file storage, and realtime messaging.
• MongoDB Atlas (MongoDB, Inc.) — the document database that holds the large research bodies (protocols, observations, graph configurations, APA tables, and version history).

Two additional providers receive data to deliver specific features and are documented in our public Subprocessor List: Google (Gemini) for AI inference and LlamaCloud / LlamaParse for parsing uploaded research documents (Fact Register §B.1). Development-only and disabled integrations do not receive production data and are excluded (Fact Register §B.2).

Vendor security attestations (attributed to the vendor). Our infrastructure vendors publish their own independent security attestations. As reported by each vendor: MongoDB Atlas — SOC 2 Type 2, ISO 27001, HIPAA-ready; Supabase — SOC 2 Type 2, HIPAA (paid add-on); Vercel — SOC 2 Type 2, HIPAA (with BAA). These attestations belong to those vendors, not to SCI. SCI has not independently audited any vendor, does not itself hold SOC 2, ISO 27001, HIPAA, or any comparable certification, and does not currently hold a BAA with any vendor (see §11, §12). A vendor's attestation does not make SCI or SingleCase.ai certified or compliant (Fact Register §B.1 "Certifications").

4. Encryption

In transit. Traffic between your browser and the Service, and between the Service and its infrastructure providers, is encrypted using TLS, provided at the infrastructure layer by Vercel, Supabase, and MongoDB Atlas under their platform defaults (Fact Register §D).

At rest. Data stored in Postgres, MongoDB Atlas, and Supabase Storage is encrypted at rest at the infrastructure layer by those providers, under their platform defaults (Fact Register §D).

What we do NOT do — stated plainly. SCI does not perform its own application-level or field-level encryption on top of the infrastructure encryption, and the platform does not implement any data-classification or data-sensitivity tiering (Fact Register §D). All encryption at rest is whatever the underlying platform provides by default; individual sensitive fields (for example, participant names or IRB details) are not separately encrypted by the application. pgcrypto is available in the database but is not used for column encryption (Fact Register §D). We disclose this so that reviewers and researchers can make an informed decision about what data to enter — particularly identifiable participant data (see also our AI Use / Transparency Notice and Privacy Policy).

5. Tenant isolation & data architecture

Separation between users, organizations, and workspaces is logical, not physical (Fact Register §D). It is enforced by two layers working together:

1. PostgreSQL Row-Level Security (RLS) — approximately 240 active policies across the database restrict each row to the users entitled to it (Fact Register §D). RLS is the backstop that applies even if application code has a gap.
2. Application-layer access checks — server routes resolve the caller's identity and membership before acting (Fact Register §E).

MongoDB Atlas does not enforce tenant isolation of its own (Fact Register §D). The research bodies stored there are protected because every request must first pass an RLS check against the Postgres index rows (external_documents / studies); only then are the corresponding MongoDB records retrieved by id. In other words, MongoDB is reached only through RLS-checked index rows, never directly by an untrusted caller.

This isolation model is enforced consistently across tenants.

6. Access controls (RBAC)

Access to data within the Service is governed by a role-based access-control (RBAC) model with roles at four levels (Fact Register §E):

• Platform role — individual, student, professor, or admin. Only admin carries elevated privilege today.
• Organization role — owner, admin, or member.
• Workspace role — admin, editor, or viewer.
• Resolved study access — owner, workspace-admin, collaborator, read-only, or none, computed from the above.

These roles are enforced server-side and are backed by the ~240 RLS policies described in §5, so a user cannot read or modify data outside their granted access even by calling the API directly (Fact Register §E).

Administrative "view as user" (impersonation). SCI support/administration includes an impersonation capability (via an X-Impersonate-User-Id header). It is admin-gated and mints a scoped, short-lived token for the impersonated user, so Row-Level Security still applies to the impersonated session — impersonation does not bypass isolation (Fact Register §E). Use of this capability by internal staff is discussed in §14.

7. Authentication — and the SSO / MFA gap

Supported sign-in methods (the only two). SingleCase.ai authenticates users with:

1. Email address + password, and
2. A 6-digit one-time code (OTP) sent to the user's email address.

Authentication is provided through Supabase Auth. Enforcement is server-side: each request carries a bearer token that the server validates before any data access, and Postgres RLS applies on top (Fact Register §E). Application middleware handles CORS and public-path routing only; it does not itself gate authentication — the routes do (Fact Register §E).

What we do NOT support today — stated plainly, because you will ask. SingleCase.ai does not currently offer (Fact Register §E):

• Single sign-on (SSO) / SAML / OAuth — there is no institutional identity-provider integration. Users authenticate with their own email and password.
• Multi-factor authentication (MFA) — neither TOTP-authenticator nor SMS second factors are available or enforced; MFA and external identity providers are disabled at the platform level.

We recognize that SSO (for example, Shibboleth/SAML or institutional Google/Microsoft) and MFA are common — often mandatory — requirements for university procurement. Both are on our Roadmap. We are not able to commit to a delivery date on this page.

8. Audit & activity logging — and its honest limits

SingleCase.ai records an in-app activity feed (activity_events) of workspace events such as study and membership changes (Fact Register §F, A6). It is designed so that ordinary users cannot alter or delete it — RLS makes it user-immutable.

It is important to be precise about what this is and is not (Fact Register §F, A6):

• It is a convenience/history feed of certain workspace activity, immutable to regular users.
• It is not append-only and not tamper-evident. The service-role backend can and does modify it: it performs coalescing UPDATEs to consolidate events and backfill DELETEs. A privileged backend actor is therefore not cryptographically prevented from altering history.
• It records the fact of an event but does not record old-value / new-value pairs (no before/after field diffs).
• It does not cover authentication events, data-access (read) events, or data-export events, and it does not capture activity on personal (non-workspace) studies.

For these reasons, the activity feed must not be relied upon as an immutable, 21 CFR Part 11-grade audit trail. Where FDA-regulated research requires a Part 11 audit trail, this feature does not meet that bar, and researchers should not represent that it does (see our IRB Data Management Policy). We disclose this rather than mislabel the feature.

9. Backup & disaster recovery

Data durability and backups are provided at the infrastructure layer by our platform vendors (Vercel, Supabase / Postgres, MongoDB Atlas), under their managed-service defaults (Fact Register §B, §D). These are managed, replicated cloud databases that provide vendor-operated backup and point-in-time-recovery capabilities as part of their platform.

Honest limits. SCI has not yet formally defined or published its own recovery-time objective (RTO), recovery-point objective (RPO), backup-frequency commitment, geographic- redundancy configuration, or a tested disaster-recovery runbook at the application level. The specifics of the backup schedule and retention on each vendor tier are governed by the vendor plan we are on and have not been independently verified for this page.

10. Vulnerability management & penetration testing

Vulnerability Disclosure Policy (VDP). We maintain a Vulnerability Disclosure Policy inviting security researchers to report issues responsibly, with a safe-harbor commitment, defined scope, and response timelines. See our Vulnerability Disclosure Policy (companion page in this package). Send reports to [email protected] with "Security" in the subject line. We do not operate a dedicated security@ alias; a /.well-known/security.txt file is published alongside the VDP.

Third-party penetration testing. SCI has not yet commissioned an independent third-party penetration test of the application. This is on our Roadmap. We do not claim to have one.

Vulnerability handling. When we identify an access-control or isolation issue we scope it, build a fix with a regression test on a branch, and verify deployment before treating it as resolved. We do not describe specific unremediated issues on this public page.

Roadmap — vulnerability management: commission an independent penetration test; publish security.txt (and stand up a security@ alias if report volume justifies it); formalize a vulnerability-triage SLA.

11. SOC 2 status

SCI is not SOC 2 certified. We do not hold a SOC 2 Type 1 or Type 2 report. Pursuing SOC 2 is on our Roadmap; we cannot commit to a certification date on this page.

Our infrastructure vendors publish their own SOC 2 attestations, which we may cite attributed to them (see §3). Those attestations cover the vendors' platforms, not SCI's application, policies, or controls. Do not read a vendor's SOC 2 as SCI's SOC 2.

12. HIPAA & Protected Health Information

SingleCase.ai is not a HIPAA-compliant service and does not support HIPAA workloads.

• SCI is not a Business Associate and does not offer or hold a Business Associate Agreement (BAA) with any customer, and holds no BAA with its subprocessors (Fact Register §B.1, §G).
• Do not upload or enter Protected Health Information (PHI) into SingleCase.ai. PHI submission is prohibited by our Acceptable Use Policy and Terms. Research-participant data entered into the platform must not be PHI governed by HIPAA.

The fact that certain infrastructure vendors offer HIPAA-eligible configurations to their customers does not extend HIPAA coverage to SingleCase.ai — SCI has not entered those configurations and holds no BAAs (Fact Register §B.1, §G).

13. Incident response & security contact

Security contact. Report a suspected security incident or vulnerability to [email protected], with "Security" in the subject line. That is our single monitored contact; we do not operate a separate security@ alias (§10).

Honest maturity statement. SCI is an early-stage organization (a newly formed Delaware PBC). We have a defined intake contact and a developing incident-handling process, and the recent AI-log access-control remediation described in §10 reflects how we detect, scope, and fix issues. We do not yet have a fully formalized, independently reviewed incident-response program with published detection, containment, and breach-notification SLAs. Building that out — including breach-notification procedures aligned to applicable US state and (where relevant) institutional requirements — is on our Roadmap. Breach-notification obligations to users and institutions are also addressed in the Privacy Policy and any institutional agreement.

14. Internal / employee access to data

Access to production data is constrained by the same RBAC + Row-Level-Security model that governs all users (§5, §6); there is no separate unrestricted "god mode" that bypasses RLS. The administrative "view as user" capability (§6) is admin-gated and operates within RLS via a scoped token, so even administrative access is bounded by the isolation model (Fact Register §E).

Honest limits. SCI has not yet formalized and cannot yet attest on this page to written internal-access policies such as least-privilege access reviews, mandatory background checks, security-awareness training, confidentiality/NDA coverage for all personnel, or logging and review of administrative impersonation events. As a small, early-stage organization, these controls are on our Roadmap.

15. Compliance context (pointers, not claims)

This page does not itself make regulatory conformance claims. For the relevant regimes and how we handle them, see (Fact Register §G):

• FERPA (school-official / DUA path) and Common Rule / IRB (45 CFR 46) — the Privacy Policy and IRB Data Management Policy. Institutional use is governed by a separate agreement.
• CCPA and newer US state privacy laws — the Privacy Policy (US-primary; a brief international-transfer note is included, with the full GDPR apparatus deferred).
• Accessibility (Section 508 / ADA procurement). We publish an honest partial-conformance self-assessment, with known gaps and alternate-access workarounds disclosed — see the Accessibility Statement. We do not claim WCAG conformance, "accessibility," or ADA/Section 508 compliance on this page or on the basis of automated testing.
• 21 CFR Part 11 — the activity feed is not a Part 11 audit trail (§8).
• HIPAA — out of scope / prohibited (§12).