Security matters because Subtriva handles sensitive business compliance records. This page explains the current security model and important limitations without overstating protections.
Important notice
This document describes Subtriva's current service practices. It is not a substitute for legal advice. Have qualified counsel review it before relying on it as a binding legal document.
1. Security Scope and Shared Responsibility
Subtriva is designed to help general contractors manage subcontractor compliance records. Security is a shared responsibility: Subtriva protects the service and its infrastructure, while customers manage account access, team permissions, devices, and the lawful handling of documents they upload.
This page describes security intentions and known product behavior, not a certification or guarantee. Do not treat Subtriva as SOC 2, ISO 27001, HIPAA, or FedRAMP certified unless a current independent report or certification is expressly provided.
2. Encryption and End-to-End Encryption
Connections to the service should use HTTPS/TLS. Storage and encryption-at-rest depend on the hosting and storage provider configuration. The service may need to access document contents for previews, AI extraction, reminders, document review, and sharing.
Subtriva does not currently provide end-to-end encryption for all data or uploaded documents. In end-to-end encryption, only the customer holds the decryption keys and the service cannot read content; this is incompatible with some current server-side processing unless a separate client-side encryption workflow is designed. We do not claim that uploaded files are end-to-end encrypted.
Do not upload credentials, payment card numbers, Social Security numbers, or other highly sensitive information unless necessary and authorized. Customers should use the minimum information needed for compliance.
3. Identity, Access, and Tenant Isolation
Authentication is provided through Supabase Auth. Database access should be protected by row-level security policies and user-scoped ownership checks. Administrators should grant only the permissions needed for each team member, remove access promptly when personnel leave, and use strong unique passwords and multi-factor authentication where available.
Bearer upload links grant access to a limited document workflow to whoever possesses the link. Treat them as secrets: send only to the intended recipient, avoid posting them publicly, and expire or revoke them when supported.
4. File Uploads and Malware Risks
Customers and subcontractors should upload only expected file types and avoid files from untrusted sources. A file extension or browser MIME type alone does not prove that a file is safe. Production deployments should enforce file size and content-type limits, use private storage, scan or quarantine uploaded files where feasible, and serve downloads with safe content-disposition and short-lived signed URLs.
Public bucket URLs can expose documents to anyone who obtains or guesses the URL and are not suitable for confidential compliance documents. Use private buckets, strict storage policies, and signed URLs for protected files. If a document has been exposed, revoke access and contact support.
5. Application and API Safeguards
Production security depends on server-side authorization for every data operation, input validation, rate limiting, CSRF and origin protections where applicable, safe error handling, secure headers, dependency patching, secret management, and audit logging. API routes must not trust a user ID, plan tier, filename, MIME type, or document ownership supplied by the browser.
Service-role keys and webhook signing secrets must remain server-side in protected deployment secrets and must never be shipped to browser code or committed to the repository. Report suspected credential exposure immediately and rotate affected secrets.
6. AI-Assisted Document Review
AI extraction and anomaly indicators are suggestions, not verification. OCR can misread dates, names, policy numbers, limits, or authenticity signals. A qualified human should inspect the source document and make the final compliance decision. AI flags must not automatically reject a document or be treated as proof of fraud.
7. Security Incidents and Reporting
If you believe an account or document has been accessed improperly, change account credentials, revoke shared links where possible, and contact security@subtriva.com with the account, approximate time, and affected resource. Do not include secrets or full documents in an initial email. We will assess the report and take appropriate steps consistent with applicable law.
8. Customer Security Checklist
Use unique passwords and MFA where available; keep devices and browsers updated; review team access periodically; share upload links privately; verify recipient email addresses; avoid public Wi-Fi for sensitive administrative work; and report suspicious messages that imitate Subtriva.
For general contractors, confirm that subcontractors are authorized to provide the uploaded documents and tell them how their information will be used.
9. Security Reviews and Availability
We review reported issues and update the service as needed. No system can be guaranteed immune to attack, and absolute security cannot be promised. Scheduled maintenance, provider outages, or external events may affect availability.
10. Contact
Security reports: security@subtriva.com. Privacy matters: privacy@subtriva.com. Do not send exploit details publicly before we have had a reasonable opportunity to investigate.