Security

Last updated: April 27, 2026

SmartTakeoffs handles two things foodservice equipment dealers care about most: their bid documents and their rep relationships. This page explains, in plain language, how we keep that data safe — the controls we have in place around storage, encryption, access, and incident response. For the full subprocessor list and legal terms, see our Privacy Policy.

At a glance

Where your data lives

Different types of data live in different storage systems, all hosted in the United States by established cloud providers:

• Uploaded bid documents and generated deliverables (PDFs, spreadsheets, quote emails) are stored in U.S.-hosted object storage using tenant-isolated paths and short-lived signed URLs scoped to the requesting user.
• Account and project metadata (project records, rep group mappings, MFR lookups, takeoff line items) are stored in a managed PostgreSQL database with tenant-level access controls.
• User identities and sessionsare managed by a dedicated identity provider. Passwords (when used) are hashed and managed by that provider — we never see them.
• Application code runs on managed U.S.-hosted application platforms with branch-protected deploys and environment-isolated secrets.

The specific providers we use as subprocessors are listed in our Privacy Policy § 6.

Encryption

All traffic between your browser, our application, and our backend services uses TLS 1.2 or newer. Object storage and database storage are encrypted at rest using AES-256 by the underlying provider.

On top of that, sensitive fields in our database (such as outbound email credentials and third-party API keys configured per tenant) are additionally encrypted at the application layer using production-only keys.

Tenant isolation

SmartTakeoffs is multi-tenant: many dealers use the same application, but each dealer's data is logically isolated. Isolation is enforced at three layers:

• Authentication— every request is scoped to the signed-in user's tenant. Tenant identity is derived from the authenticated session, not from request bodies or query parameters that could be spoofed.
• Database— tenant-scoped database access is enforced through application-level checks and database access controls so a query can only return rows belonging to the requesting tenant.
• Object storage— uploaded files and generated deliverables are stored under tenant-prefixed paths and accessed via short-lived signed URLs scoped to the requesting user.

Access controls

Within a dealer account, users are assigned roles (estimator or admin). Admins manage the team; estimators run takeoffs and edit their own projects. All edits are captured with version history so you can see who changed what.

Production access at SmartTakeoffs is limited to a small operations team using individually-scoped credentials. Production access is granted on a least-privilege basis and is logged. We never use shared admin accounts. Direct database access in production is reserved for incident response and is audited.

Customer data and AI

We use third-party AI APIs to process uploaded bid documents for the requested takeoff — reading specs, identifying equipment items, and matching manufacturers to rep groups. Based on our provider agreements and account settings, customer inputs and outputs are not used to train general-purpose models, and the bid documents are not retained for any purpose other than running your takeoff.

We may use anonymized, aggregated metrics from extraction runs (for example, how often a particular MFR/model combination shows up across the platform) to improve the product. We do not share or sell identifiable customer content.

Backups and recovery

Our database is backed up automatically with point-in-time recovery enabled. Object storage is durably stored across multiple disks and validated against checksums. We periodically rehearse restore-from-backup and disaster-recovery procedures.

Secure development

• All production environment variables (API keys, database URLs, encryption keys) are flagged as sensitive in our hosting platforms and are never displayed in build logs.
• Source code is hosted in a private repository with branch protection. Production deploys are tied to specific commits and are observable.
• Dependencies are kept current. Automated alerts surface vulnerabilities so we can patch them quickly.
• Form endpoints exposed to the public (such as the early-access request form) are protected by third-party bot mitigation to deter automated abuse.

Subprocessors

We rely on a small set of established providers to operate the Service. The current list lives in our Privacy Policy § 6 and is kept current. We notify customers when a material subprocessor change happens.

Compliance and certifications

SmartTakeoffs is an early-stage product and does not currently hold SOC 2, ISO 27001, or HIPAA certifications. We follow the controls described above as a matter of practice, and we're happy to discuss our security posture in detail with prospective customers whose procurement process requires it. Reach out at hello@smarttakeoffs.com.

Reporting a security issue

If you believe you've found a vulnerability or security concern, email hello@smarttakeoffs.com with the details. We'll respond promptly, work with you to verify and reproduce the issue, and remediate as quickly as we can. We ask that researchers act in good faith, avoid degrading the service, and give us a reasonable window to respond before public disclosure.

Incidents

If we become aware of a security incident that affects customer data, we will notify affected dealers without undue delay, share what we know about scope and impact, and describe remediation steps. We maintain an internal runbook for incident response and update it after every event we exercise it on.