Every field service app you use stores your customers' names, home addresses, phone numbers, and payment information. If that data is mishandled, you are the one your customers hold responsible—not the software company.
When you manage jobs in a field service app, you are trusting that software with personally identifiable information (PII)—your customers' full names, home and business addresses, phone numbers, email addresses, and in many cases their payment details.
Under data protection laws and common-law negligence standards, businesses that collect customer PII have a duty of care to protect it. If a software tool you chose suffers a breach or mishandles data, your customers will look to your company—not a faceless SaaS vendor—for answers.
Before you trust any web application with your customers' personal information, demand to know exactly how they protect it. If they can't answer clearly, that is your answer.
These are not premium features. These are baseline requirements for handling your customers' data responsibly.
Passwords must be cryptographically hashed—never stored in readable form. If a database is compromised, properly hashed passwords are designed to be irreversible.
Any third-party tokens (QuickBooks, payment processors, etc.) stored in their database must be encrypted at rest using strong, authenticated encryption.
Every page, every API call, every data transfer must be encrypted in transit. No exceptions. If any part of the app loads over plain HTTP, walk away.
HTTP security headers (HSTS, Content-Type protection, XSS filters, referrer policies) prevent common web attacks. Ask if they enforce them on every response.
Weak passwords are the #1 way accounts get compromised. The software should enforce minimum length, complexity, and reject common patterns.
Not every user needs access to everything. Technicians, admins, and owners should each see only what they need—enforced at the server level, not just the UI.
Your data must be completely walled off from other companies using the same software. Every database query should be scoped to your organization only.
Login pages and APIs must be protected against automated attacks. Without rate limiting, attackers can guess passwords thousands of times per minute.
Access control must be enforced on the server, not just hidden in the interface. Every API route must verify who is making the request and whether they are allowed.
Any public-facing form (signup, contact, demo requests) should be protected by CAPTCHA or equivalent to prevent automated abuse and spam.
Ask where your data physically lives. A SOC 2 Type 2 certified data center is the industry standard for SaaS—it means the hosting environment has been independently audited for security, availability, and confidentiality. If your vendor can't tell you, that's a red flag.
We don't make vague promises. Here is exactly what we do and how we do it.
Every user password is processed through a one-way cryptographic hashing algorithm with an adaptive cost factor before it is stored. Hashed passwords are designed to be irreversible—they cannot be decrypted or read back in plain text, even by our team.
Third-party API tokens (such as QuickBooks OAuth credentials) are encrypted at rest using authenticated encryption. This means stored credentials are protected against both unauthorized reading and tampering.
All traffic between your browser and our servers is encrypted using TLS (Transport Layer Security). We enforce HSTS so browsers are instructed to always connect securely—plain HTTP connections are not permitted.
Every response from our servers includes a full suite of security headers that protect against common web attacks—including MIME-type sniffing, cross-site scripting, information leakage, and unauthorized access to device features like cameras and microphones.
We enforce strong password requirements at signup and password change, including minimum length and a mix of character types. Passwords that do not meet our complexity standards are rejected before they are ever stored.
Users are assigned roles with distinct permissions. Access control is enforced on every API route at the server level—not just in the interface. A technician cannot reach admin reports, billing, or team management endpoints regardless of how the request is constructed.
Every database query is scoped to your organization's unique identifier. The system is designed so that one company's users cannot access another company's customers, jobs, or financial data—this isolation is enforced at the data layer, not just the interface.
We enforce strict request-rate limits across the entire application—including authentication, standard API routes, data exports, and payment endpoints. Automated attacks and brute-force attempts are throttled well before they can do damage.
Every API endpoint verifies the caller's session token and confirms their identity, role, and organization membership before processing any request. Unauthenticated or unauthorized requests are rejected immediately.
Public-facing forms such as demo requests are protected by Google reCAPTCHA to prevent automated bots from abusing our systems or spamming our users.
Crew Forge runs on infrastructure that has been independently audited and certified to SOC 2 Type 2 standards—covering security, availability, processing integrity, and confidentiality. Your data is not sitting on a home server or an unvetted VPS. It is hosted in a professionally managed, compliance-audited environment with enterprise-grade physical and network security controls.
We built this page not just to show you what Crew Forge does—but to give you a checklist to hold every software vendor accountable. Your customers trust you with their personal information. That trust is not something to gamble with a tool that can't explain how it protects their data.