Security at Scannect

Scannect is a multi-tenant field-sales CRM. Every account is provisioned into its own workspace, and access to data is enforced by database row-level security policies and by server-side authorization checks in application code — not by the user interface alone.

Users sign in through our identity provider. Supported sign-in methods may include email and password and configured OAuth providers such as Google. Passwords are stored hashed by the identity provider; we never store plaintext passwords. Session tokens are managed by the identity provider and used to authorize requests server-side.

Every record (contacts, offices, visits, tasks, pipeline templates and stages, email templates, scans, settings, connected-account records, audit entries) is scoped to a workspace. Server code resolves the caller's active workspace on each request and applies that scope to every query.

Row-level security (RLS) is enabled on the tables that hold Customer Data. Membership and role checks are implemented as security-definer database functions with pinned search paths, and policies call those helpers to decide whether a row is readable or writable. Application server functions additionally validate the caller's identity, workspace, and role before performing sensitive operations, and requests use the caller's own token so RLS applies.

A limited set of isolated server-only workflows use elevated database credentials when a user-scoped session cannot perform the required infrastructure operation. Each such path either authenticates and authorizes the caller server-side before proceeding, or validates a trusted external signal such as a signed webhook. Elevated credentials are held on the server and are never shipped to the browser.

Business-card images and workspace logos are kept in private storage buckets. Access to those files goes through time-limited signed URLs generated server-side after an authorization check. Uploads require an authenticated workspace member.

Audit entries are recorded server-side for sensitive events across core CRM tables and connected-account activity, and — when billing is activated — for plan changes written by the payment webhook. Audit rows are append-only at the policy level and are not user-editable.

Internal administrative pages and operations are gated by a server-side role check. UI visibility is not the control — the server verifies the caller's role on every admin action.

Traffic between your browser and Scannect is encrypted in transit over HTTPS/TLS. Sensitive connected-account credentials are additionally encrypted at rest using authenticated symmetric encryption. Scannect does not offer end‑to‑end encryption and does not claim that all data at rest is customer-key encrypted.

Card scans and AI email drafts are metered per workspace and per plan. Server-side checks enforce those plan usage limits before any outbound AI call is made, and Scannect relies on its upstream AI and email providers for request throttling. Free-plan email sending is blocked server-side even if a connection is somehow established.

When you connect a third-party account such as Gmail or Outlook, the access token and related credentials are stored encrypted server-side and are readable only by the isolated server module that performs the send. There are no client-side policies that let a browser read those credentials.

Scannect is a sales relationship tool, not a clinical system. Do not upload patient records, protected health information (PHI), diagnoses, treatment or prescription data, laboratory results, medical images, or insurance/claims data. See our Terms for the full restriction.

Scannect has not completed a SOC 2 audit and does not claim HIPAA compliance. We do not offer certification logos or attestation badges. If your organization requires a formal audit report or a HIPAA Business Associate Agreement, please contact us before storing regulated data in the Service.

If you believe you have found a security vulnerability, please email support@myscannect.com with a description, reproduction steps, and any relevant artifacts. Please give us reasonable time to investigate and remediate before public disclosure, and avoid actions that could impact other users or their data (no automated scanning, credential stuffing, denial of service, or access to accounts that are not yours). We will acknowledge legitimate reports and keep you informed of progress.