Security Practices

1. Overview

Access to your data is controlled in layers: sign-in, access rules enforced in the database, and the network protections our hosting providers operate. The sections below describe each control as it stands today and say plainly where one is not yet in place.

2. Encryption

2.1 Data in Transit

• All data transmitted between your device and the Platform is encrypted with TLS (Transport Layer Security), version 1.2 or higher.
• We enforce HTTPS on all connections. HTTP requests are automatically redirected to HTTPS.
• We support only strong cipher suites and disable deprecated protocols (SSLv3, TLS 1.0, TLS 1.1).
• HTTP Strict Transport Security (HSTS) headers are enforced to prevent downgrade attacks.

2.2 Data at Rest

• All stored data, including database records and file uploads, is encrypted at rest using AES-256 encryption by our database and storage provider, which manages the encryption keys.

3. Authentication and Access Control

• Password Authentication: Where an account uses a password, our authentication provider (Supabase Auth) stores only a salted bcrypt hash of it, never the password itself.
• Multi-Factor Authentication (MFA): Time-based one-time password (TOTP) MFA is for supervisor and administrator accounts; worker accounts do not use it. Administrator accounts must set up an authenticator app before they can use the web dashboard (the emergency and safety pages stay open to them without it), and supervisors may turn it on. Once an account has one, the web dashboard asks for its code at sign-in. For now, the code prompt offers a skip for that browser session (for a lost phone), the mobile app does not ask for the code, and the database does not yet require it.
• Session Management: Sign-in sessions are held in SameSite cookies and use access tokens that expire and renew automatically. Signing out revokes your sign-in sessions on the server and clears the session cookies in that browser; an access token that was already issued stays valid until it expires.
• Role-Based Access Control (RBAC): The Platform has four roles — SUPER_ADMIN, ADMIN, SUPERVISOR and WORKER — with different permissions. For some records the database's row-level security checks the role itself (for example, a company's audit trail can be read only by its administrators and by VeriField Pro's platform administrators); for others, the role is checked by the application.
• Brute-Force Protection: Our authentication provider rate-limits repeated failed sign-in attempts per account and per source.
• Password Policies: We enforce a minimum password length. Passwords are hashed by our authentication provider and are never visible to us.

4. Data Isolation

• RLS policies are enforced at the PostgreSQL database level, below the application layer, providing defense in depth.
• Queries made with a user's sign-in are filtered by these policies. Some server-side functions, such as scheduled weather alerts and the walk-up check-in pages, run with elevated database access that these policies do not apply to.
• Uploaded files (photos and documents) are kept in private storage, with access rules that tie each file to the company it belongs to. Where a feature needs it, our server issues a short-lived link instead: for example, a site's active safety briefing is shown to visitors who check in with that site's QR code.
• Changes to RLS policies are tested against a local copy of the database before they are applied.

5. Infrastructure Security

• Database: Our database is hosted on Supabase, which runs on Amazon Web Services (AWS) infrastructure.
• Edge Network: The web application is served via Vercel's global edge network, providing DDoS protection, automated SSL, and geographic distribution for fast load times.
• Data Centers: All data is stored in AWS data centers located within the United States. Our database and hosting providers (Supabase and Vercel) hold SOC 2 Type II reports.
• Network Security: Network protections, including firewalls and DDoS mitigation, are operated by our hosting providers (Vercel, Supabase and AWS). We do not run our own intrusion-detection system.
• Serverless Functions: Backend logic runs on serverless infrastructure, eliminating server management risks and providing automatic scaling and isolation.

6. Application Security

• Input Handling: The web application and our server functions do not assemble SQL from user input; they reach the database through Supabase's client library and database functions. Pages are rendered with React, which escapes text by default, and the web application does not insert raw HTML.
• Content Security Policy: A Content Security Policy is deployed in report-only mode while we measure it against real traffic. It reports violations today and is not yet enforcing.
• Dependency Management: Third-party dependencies are reviewed and updated as part of ongoing maintenance.
• Audit Logging: A database trigger records every insert, update, and delete — with before-and-after row snapshots and the acting user — on a defined set of tables, including personnel and employee records, employee documents, site training forms, completions and bypasses, weather alerts, emergency acknowledgments, and feature flags. Audit records are readable only by a Client's own administrators and by VeriField Pro's platform administrators, and cannot be written or altered through the application. Record reads are not logged, and authentication events are recorded by our identity provider rather than in this audit trail.
• API Security: Endpoints used inside the signed-in application act on the user's sign-in, checked in the endpoint or by the database's access rules. Scheduled jobs and server-to-server calls require a secret. Some endpoints are public by design, because people use them without an account, such as walk-up check-in and check-out, visitor lookup, links sent by text message, weather and lightning data for the check-in pages, and the website contact form. Several of these, including walk-up check-in and visitor lookup, are rate-limited; the count is kept separately on each server instance, so it is not a platform-wide limit. We do not issue API keys to customers.
• Development Process: Changes go through the automated checks described in Section 9. We do not currently run automated security scanning or SAST (see Section 9).

7. Production Access

• Who has access: Access to production systems (the database, hosting and file storage) is restricted to named company personnel.
• Not yet in place: We do not run scheduled access reviews or a security-awareness training program, and we do not keep our own log of production access.

8. Compliance and Certifications

• SOC 2: VeriField Pro does not hold a SOC 2 report and has not engaged a SOC 2 auditor. If your organization requires a SOC 2 report, please raise it with us before you sign.
• Infrastructure Providers: Our database and hosting providers (Supabase and Vercel) hold SOC 2 Type II reports.
• MSHA Recordkeeping: Our security controls are designed to support clients' MSHA recordkeeping requirements, including the integrity, availability, and retention of safety records.

9. Security Testing

We would rather tell you what we actually do than describe a program we do not yet run.

• Continuous Integration: Every change pushed to our main branch runs type-checking, linting and an automated test suite of more than 2,000 tests in continuous integration, and a local check that builds the production application runs before each push. CI does not block a deploy, and the local check can be overridden in an emergency.
• Database Security Linting: We run our database provider's security advisor against production and keep a written disposition for every finding, including the ones we have deliberately accepted and why.
• Tenant-Isolation Checks: An automated check in CI fails when a page lists sites without scoping them to the viewer's company.
• Not yet in place: We do not currently engage a third-party penetration testing firm, and we do not run scheduled automated vulnerability scanning or SAST. Both are planned. If either is a requirement for your organization, tell us and we will give you a date rather than a claim.

10. Incident Response

VeriField Pro handles a security incident in these steps:

• Detection: Application errors are recorded by our error monitoring, and an automated check on the check-in pipeline sends us a text when it finds a problem. We do not run dedicated security-event or intrusion monitoring.
• Containment: Immediate steps to limit the scope and impact of an incident.
• Investigation: Thorough analysis to determine root cause, scope, and affected data.
• Notification: Affected clients will be notified within 72 hours of confirming a data breach, consistent with applicable law and our Data Processing Agreement.
• Remediation: Implementation of fixes and preventive measures to address the root cause.
• Post-Incident Review: Documentation of lessons learned and improvements to security controls.

11. Vulnerability Disclosure

We appreciate the security research community's efforts to improve the security of our Platform. If you discover a security vulnerability, please report it responsibly:

When reporting a vulnerability, please include:

• A description of the vulnerability and its potential impact.
• Detailed steps to reproduce the issue.
• Any proof-of-concept code or screenshots.

We commit to acknowledging receipt of vulnerability reports within 48 hours and providing an initial assessment within 5 business days. We will not pursue legal action against researchers who report vulnerabilities in good faith and in compliance with responsible disclosure principles.

12. Contact Us

For security-related questions or concerns: