Security
Security & data practices
Everything on this page is true of the product as it runs today. We publish practices when they are verifiable, not in advance — specificity over badges.
Tenancy isolation and access control
Every workspace is isolated at the database row level. Postgres Row-Level Security is enabled across the application schema — 125 active policies layering organization → project → row — so a query in one workspace cannot read another workspace's records, independent of application code.
Inside a workspace, role-based permissions control what each person can see and do. Owners, reps, accountants, and external partners are invited with roles that fit their job, and financial approvals route through sequential sign-off that matches how the owner delegates.
Encryption
Data is encrypted in transit (TLS) and at rest on managed infrastructure. Application traffic is HTTPS-only.
Audit trail
Approvals, budget changes, contracts, and invoices keep who did what, when, and the backup documents behind the decision. Contracts and change orders are signed with built-in e-signatures, and the executed document, its signers, and its timestamps stay attached to the project record.
Your data stays yours
Financials and reports export cleanly, documents remain downloadable, and the record — including its audit history — stays exportable after a project closes out. There is no lock-in mechanism between you and your own paper.
Infrastructure and subprocessors
These vendors process data on our behalf:
Security reviews and questionnaires
Running a security review, vendor questionnaire, or procurement process? Email michael.eads@siteops360.com — a founder answers directly.
Not yet published here: formal backup and recovery documentation, an incident-response policy, an accessibility conformance statement, and third-party certifications. Sections are added to this page as each becomes verifiable.