Security & Trust

The scope of this security statement is the Thotara production platform: the web application, its portals, server-side functions, public webhook and scheduled-job endpoints, the managed database, object storage for documents, and the supporting authentication, email and AI services. Security is designed in three layers — isolation at the database, authorisation at every server entry point, and accountability through an immutable audit trail — so that a mistake in one layer does not by itself expose data.

Thotara is not a clinical system and does not store patient medical records, so HIPAA is not in scope. The platform is engineered against ISO/IEC 27001:2022 Annex A and SOC 2 Type II control expectations, described in section 17.

• Every record carries an organization identifier, and database row-level security scopes reads and writes to the caller's organization membership. Isolation is enforced by the database, not by application filtering, so there is no application path that returns another tenant's rows.
• Tables are created with explicit privilege grants and row-level security enabled in the same change; a table cannot ship readable by default.
• Membership is resolved through dedicated security-definer helper functions rather than trusting any client-supplied organization value.
• Staff who legitimately belong to more than one workspace switch context explicitly, and the switch is authorised server-side each time.
• Uploaded documents live in private buckets whose object paths are themselves organization-scoped and policy-checked.

• Roles live in a dedicated role table, never on the user profile, and are organization-scoped, which removes the privilege-escalation path of a user editing their own record.
• Super administrators can compose custom roles from a fixed permission vocabulary; permissions are evaluated server-side and the interface only reflects the result.
• Portal users are structurally separated from staff: providers reach only their own linked records, and facility contacts only their own client's records, through dedicated helpers rather than shared queries.
• Staff contact profiles are not readable by portal users, and cross-organization profile reads are blocked.
• Sensitive surfaces — banking details, audit log, access review, compliance checklist, productivity data, platform console — require an explicit administrative or finance permission.
• Server-side functions re-verify the caller's session, organization membership and permission on every call; the browser never holds a privileged key, and privileged clients are loaded only after the caller has been verified.
• Signed letters, signed agreements and approved timesheets are locked by database triggers so signature and approval fields cannot be altered after the fact.

• Two-step verification is mandatory on every signed-in route. Staff and administrators must register an authenticator application; provider and facility portal users receive a one-time code by email. The applicable method is decided server-side from the user's roles.
• Passwords are checked against known-breach corpora at signup and at change, and must meet minimum length and complexity requirements.
• Sessions end automatically after 30 minutes of inactivity, with a warning before sign-out; the timer is shared across browser tabs and sign-out clears cached data so the back button cannot restore it.
• Administrators can reset a teammate's lost authenticator after out-of-band identity verification; the reset removes the enrolled factors, forces fresh enrolment and is written to the audit trail.
• Invitations are single-use, expiring tokens; an unaccepted invitation grants no access and is surfaced in the access review.
• Disabling a provider's or facility contact's portal access revokes their data access immediately at the database layer, not just in the interface.
• Anonymous sign-up is disabled; accounts exist only where an administrator has invited them.

• All traffic is served over TLS 1.2 or higher with modern cipher suites; plaintext HTTP is redirected.
• Data at rest in the managed database and in object storage is encrypted with AES-256 using provider-managed keys, including backups and replicas.
• Bank account and taxpayer identifiers are additionally protected at the application layer: they are written through restricted paths, returned to staff only in masked form, and a full reveal requires a finance permission and writes an audit entry.
• Integration credentials and job secrets are stored server-side only, are never returned to the browser, and are rotated on demand; no secret is committed to source control.
• Document downloads use short-lived signed URLs rather than public links, so a copied URL expires quickly.

Sensitive actions are recorded by database triggers rather than application code, so they cannot be skipped by a new code path: role grants and revocations, custom role changes, invitations and activations, organization and branding settings, credential status changes, document uploads and downloads, banking submissions and reveals (with account numbers masked), data imports, assignment edits, letter and agreement lifecycle events, two-step-verification resets, retention purges, and every view or export of recruiter productivity or access-review data.

Entries capture the actor, organization, action, target record, timestamp and a structured detail payload. The log is append-only for application roles — it cannot be edited or deleted from the interface — and administrators can filter it by category, actor or date and export it as audit evidence.

Administrators have an access review report listing every user in the workspace, their roles and custom roles, whether they are staff or a portal user, their access grant date, when they were last active, and which invitations are still outstanding. Users inactive for 60 days or more are flagged for removal. The report is exportable as evidence for a periodic review, and both viewing and exporting it are themselves recorded in the audit trail. Removing a user or disabling portal access takes effect immediately at the database layer, and the in-app compliance checklist tracks the cadence of these reviews with a recorded reviewer and evidence note.

• Authentication events, server-function errors and database activity are logged centrally with retention sufficient for investigation.
• Automated security and database linting runs against the schema to catch a table shipped without row-level security, a permissive policy or an over-exposed function.
• Application errors are captured with request context so a failure can be traced without exposing customer data in the message.
• Confirmed incidents follow a documented procedure: triage and severity assignment, containment, eradication, recovery, customer notification, and a written post-incident review with corrective actions.
• Affected organization administrators are notified without undue delay and in any event within 72 hours of confirming an incident involving personal data, with what happened, what data was involved, the likely impact and the steps taken.
• Incident response is exercised periodically as a tabletop drill, recorded in the compliance checklist.

• Changes are reviewed before release, tracked to a versioned history, and deployed through an automated pipeline; database changes ship as versioned migrations rather than manual edits.
• Schema changes must create the table, grant explicitly, enable row-level security and define policies in the same migration, so a new table cannot reach production unprotected.
• Server functions validate their input against typed schemas before touching the database, which blocks malformed and injected payloads.
• Parameterised queries and a typed data-access layer are used throughout; no user input is concatenated into SQL.
• Dependencies are scanned for known vulnerabilities and updated on a regular cadence, with critical fixes expedited.
• Production data is not copied into development environments; test data is synthetic.
• Environment separation keeps preview and production credentials distinct.

• The application runs on managed edge compute with no long-lived servers to patch, and the database, authentication and object storage are operated by a cloud provider holding SOC 2 and ISO 27001 certifications.
• The database is not exposed to the public internet for application traffic; all access goes through authenticated APIs that enforce row-level security.
• The platform is fronted by a provider that terminates TLS and absorbs volumetric denial-of-service traffic.
• Administrative access to production infrastructure is limited to named personnel, protected by two-step verification, and reviewed periodically.
• Operating-system and platform patching is the managed provider's responsibility under its own certified programme.

• Endpoints that must be reachable without a session — inbound webhooks and scheduled jobs — verify a signature or a private job secret in constant time before doing any work, and reject oversized or malformed payloads.
• Job secrets are stored in a private table readable only by the privileged server role; the publishable key is never used for job authentication.
• Webhook payloads are validated against a schema and processed idempotently, so a replayed delivery cannot duplicate records.
• Outbound integrations (telephony, sourcing, email, prior-CRM import) run server-side under credentials the organization supplies; those credentials are never sent to the browser.
• Connector failures are surfaced to administrators rather than silently retried indefinitely.

A sub-processor register records each service, what it processes, its processing region and its certifications. New sub-processors are assessed before use and organization administrators are notified before one begins processing their data, with an opportunity to object. Optional connectors are engaged by the customer under its own vendor agreement. The register is reviewed on a recurring schedule tracked in the compliance checklist, and the current list is summarised in the privacy policy.

Retention is enforced by a nightly scheduled purge job, not by manual clean-up, and each run writes an audit entry recording per-table deletion counts. Data under a legal hold, tax obligation or unresolved dispute is retained until that obligation ends. A written certificate of deletion is available on request after a workspace is closed.

• Thotara personnel do not access customer records in the ordinary course of business; support and incident access is limited to named staff, requires a business justification, and is time-bound and logged.
• Personnel are bound by written confidentiality obligations and receive security awareness training covering phishing, credential hygiene and data handling.
• Access to production systems follows least privilege, is granted on role change and revoked on departure as part of a documented offboarding step.
• Company devices use disk encryption, screen lock and endpoint protection; customer data is not stored locally.
• Password managers and two-step verification are required for all internal accounts, including cloud and code-hosting providers.

Certification covers a management system, not a code base, so the honest position is this: the platform implements the Annex A technical and organizational controls below, and the remaining certification work — scope statement, risk assessment and treatment plan, statement of applicability, internal audit and management review — is customer-side ISMS documentation that we support with exportable access-review, audit-trail and compliance evidence. SOC 2 Type II additionally requires an observation window and an accredited auditor.

The platform also aligns with the SOC 2 trust services criteria for security, availability and confidentiality: logical access controls (CC6), change management (CC8), monitoring and incident response (CC7), risk assessment (CC3) and vendor oversight (CC9). Because no patient medical records are stored, HIPAA is out of scope; where an organization processes UK or EU personal data, transfers rely on Standard Contractual Clauses and the UK Addendum.

Security is shared. Thotara secures the platform; each organization is responsible for how it is configured and used:

• Assign the least privilege each user needs, and review role and custom-role assignments on a regular cadence using the access review report.
• Remove leavers promptly and disable portal access when a provider or facility relationship ends.
• Decide which records portal users can see, and verify identity out-of-band before resetting anyone's two-step verification.
• Keep connector credentials current, scope them narrowly, and rotate them when personnel change.
• Obtain and evidence consent for SMS and email outreach, and honour opt-outs.
• Do not upload patient medical records or data the organization has no right to process.
• Report suspected account compromise immediately so sessions can be revoked.

Email security@thotara.com with steps to reproduce, affected URLs and any proof-of-concept. We acknowledge reports within two business days, provide a triage assessment within five business days, keep you updated while we investigate, and credit reporters who wish to be named once a fix ships.