Security Practices

1. Overview

Our security program is built on the principles of defense in depth, least privilege, and zero trust. We implement multiple layers of security controls to protect against unauthorized access, data breaches, and service disruptions. Our security practices are continuously evaluated and improved to address emerging threats.

2. Encryption

2.1 Data in Transit

• All data transmitted between your device and the Platform is encrypted using TLS 1.3, the latest version of the Transport Layer Security protocol.
• 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, file uploads, and backups, is encrypted at rest using AES-256 encryption.
• Encryption keys are managed through the cloud provider's key management service with automatic key rotation.
• Database backups are encrypted with separate keys from production data.

3. Authentication and Access Control

• Password Authentication: User accounts are secured with email and password authentication. Passwords are hashed using bcrypt with a high cost factor and are never stored in plain text.
• Multi-Factor Authentication (MFA): Time-based one-time password (TOTP) MFA is available to every account and is recommended for administrators. It is not currently enforced.
• Session Management: Authentication sessions use secure, HttpOnly, SameSite cookies with automatic expiration. Sessions are invalidated on logout and after a configurable inactivity period.
• Role-Based Access Control (RBAC): The Platform implements granular role-based access control with distinct permission sets for SUPER_ADMIN, ADMIN, SUPERVISOR and WORKER roles. Access is enforced in the database by row-level security, not only in 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.
• Every database query is automatically scoped to the authenticated user's organization.
• File storage (photos, documents) is organized by tenant with access policies ensuring files are only accessible to authorized users within the same organization.
• RLS policies are reviewed and tested with each database schema change.

5. Infrastructure Security

• Database: Our database is hosted on Supabase, which runs on Amazon Web Services (AWS) infrastructure. The database is deployed in a Virtual Private Cloud (VPC) with no direct public internet access.
• 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 infrastructure providers maintain SOC 2 Type II, ISO 27001, and other certifications.
• Network Security: Firewalls, intrusion detection systems, and network segmentation are employed to protect infrastructure components.
• Serverless Functions: Backend logic runs on serverless infrastructure, eliminating server management risks and providing automatic scaling and isolation.

6. Application Security

• Input Validation: All user inputs are validated and sanitized on both client and server side to prevent injection attacks (SQL injection, XSS, CSRF).
• 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 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: API endpoints are authenticated, rate-limited, and input-validated. API keys are scoped to minimum required permissions.
• Secure Development Lifecycle: Security is integrated into our development process through code reviews, automated security scanning, and security-focused testing.

7. Employee Access Controls

• Least Privilege: VeriField Pro employees are granted access to systems and data on a need-to-know basis, with the minimum permissions required for their role.
• Access Reviews: Employee access permissions are reviewed quarterly and adjusted as roles change.
• Production Data Access: Access to production customer data is restricted to authorized personnel and requires documented justification. All production access is logged.
• Offboarding: When an employee departs, all access credentials are revoked immediately.
• Security Training: All employees complete security awareness training upon hire and on an annual basis thereafter.

8. Compliance and Certifications

• SOC 2 Readiness: VeriField Pro is actively pursuing SOC 2 Type II certification and has implemented controls aligned with the Trust Services Criteria (Security, Availability, and Confidentiality).
• Infrastructure Certifications: Our infrastructure providers (AWS, Supabase, Vercel) maintain SOC 2 Type II, ISO 27001, and other industry certifications.
• 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 programme we do not yet run.

• Continuous Integration: Every change runs type-checking, linting and an automated test suite of more than 2,000 tests before it can be merged or deployed.
• 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: Automated checks in CI fail the build if a query is written in a way that could read across customer boundaries.
• 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 organisation, tell us and we will give you a date rather than a claim.

10. Incident Response

VeriField Pro maintains a documented security incident response plan that includes:

• Detection: Automated monitoring and alerting systems for anomalous activity.
• 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: