Most contractors don't think about security when evaluating FSM software -- until something goes wrong. A data breach that exposes customer payment information, a ransomware attack on customer records, or a compliance violation can be far more costly than any software subscription.
You don't need to be a security expert to evaluate FSM software security. You need to ask the right questions and understand what acceptable answers look like.
TL;DR
- FSM software stores sensitive data: customer PII, payment information, business financials, and employee records
- The three most important security certifications: SOC 2 Type II, PCI DSS compliance, and data encryption standards
- For most contractors, GDPR compliance matters if you serve any customers in the EU/UK; CCPA applies if you serve California residents
- Security questions belong in the initial vendor conversation, not as an afterthought before signing
- On-premise software is not inherently more secure than cloud -- modern cloud platforms routinely exceed what most contractor IT environments can provide
Why FSM Security Matters for Contractors
Your FSM platform stores:
- Customer personal information: Names, addresses, phone numbers, email addresses
- Payment data: Card information (even tokenized), payment history
- Business financials: Revenue figures, invoice data, outstanding balances
- Employee data: Names, contact information, schedules, location history
- Property access information: Gate codes, lock box combinations, access instructions
A breach that exposes this data creates customer harm, regulatory liability, and reputational damage. In states with breach notification laws (all 50 US states as of 2026), you may be legally required to notify affected customers -- which creates real operational and cost impact.
Key Security Standards to Understand
SOC 2 Type II
SOC 2 (System and Organization Controls 2) is an audit framework developed by the AICPA that evaluates how a software company protects customer data across five trust service criteria: security, availability, processing integrity, confidentiality, and privacy.
Type I is a point-in-time assessment. Type II covers a period (typically 6-12 months) and provides much stronger assurance that security controls are sustained over time -- not just documented.
What to ask: "Do you have a SOC 2 Type II report? When was it last issued? Can I see the executive summary or attestation letter?"
Red flag: A vendor who cannot provide SOC 2 documentation and isn't in the process of obtaining it is not taking security seriously.
PCI DSS Compliance
The Payment Card Industry Data Security Standard applies to any system that stores, processes, or transmits credit card data. If your FSM software processes card payments (which it should, if you're collecting field payments), it must be PCI compliant.
What this means in practice: Card data should be tokenized immediately -- your FSM system should never store raw card numbers. Payment processing should run through a PCI-certified processor (Stripe, Square, Braintree, etc.).
What to ask: "Are you PCI DSS compliant? What level of compliance? Does my business take on any PCI compliance obligations by using your platform?"
Data Encryption
All data should be encrypted at rest (stored data) and in transit (data moving between systems).
At rest: AES-256 encryption is the current standard.
In transit: TLS 1.2 or 1.3 for all data transmission. Look for HTTPS everywhere, including the mobile app.
What to ask: "How is customer data encrypted at rest? What encryption standard? Is all data transmission over TLS?"
Multi-Factor Authentication (MFA)
MFA requires a second factor (typically an authentication app or SMS code) in addition to a password. Without MFA, a stolen password grants full access to your business data.
What to ask: "Does your platform support MFA? Is it required or optional? Do you offer SSO integration with Google Workspace or Microsoft 365?"
Privacy Compliance Basics
GDPR (General Data Protection Regulation)
GDPR applies when you store or process personal data of EU or UK residents. If you serve any customers in Europe -- even a small number -- GDPR obligations apply.
Core obligations:
- Customer right to request their data and have it deleted
- Processing data only for legitimate purposes
- Breach notification within 72 hours of discovering a breach
What to ask: "Is your platform GDPR compliant? Can customers request data deletion, and how is that processed in your system?"
CCPA (California Consumer Privacy Act)
CCPA gives California residents rights over their personal data similar to GDPR. If you serve California residents, CCPA applies regardless of where your business is located.
Data Residency
Some industries and jurisdictions require data to be stored within specific geographic regions. If this applies to your business, confirm where the vendor stores data.
What to ask: "Where is our data stored geographically? Do you offer data residency options?"
Access Controls and Employee Security
Your FSM platform should allow you to control what each user can see and do:
- Role-based access: Technicians should see their own jobs, not company financials. Dispatchers should manage scheduling without accessing payment settings.
- User activity logging: Who created, modified, or deleted which records -- with timestamps.
- Remote account disable: If an employee leaves, you should be able to immediately revoke their access without waiting for vendor support.
What to ask: "What are the permission levels? Can I set custom permissions? What access logs are available? How quickly can I disable an account?"
Cloud vs. On-Premise Security
A common misconception: on-premise software is more secure because "your data is in your building."
In reality, most contractor IT environments are less secure than major cloud providers:
- AWS, Azure, and Google Cloud data centers have physical security, redundant power, and security teams that no contractor office can match
- Cloud providers maintain patch cycles and security updates automatically; on-premise software requires internal IT management
- Cloud platforms are audited against SOC 2 and other frameworks; on-premise environments typically are not
On-premise software can be appropriate for specific regulatory environments, but the assumption that it's inherently more secure is generally not true.
For the complete picture of what to look for when evaluating FSM software, see the FSM complete guide and the FSM buyer's checklist.
FAQ
What is the vendor's responsibility vs. my responsibility if there's a breach? This is a shared responsibility model. The vendor is responsible for the security of their platform infrastructure. You are responsible for: choosing strong passwords, enabling MFA, managing user access (removing employees who leave), and ensuring your users follow basic security practices. The vendor's responsibility and your responsibility should be clearly defined in their Terms of Service and Data Processing Agreement.
What should I do if a vendor can't answer my security questions? It's a significant red flag. Security questions are not unusual -- any legitimate SaaS vendor has answered them before. An inability to produce SOC 2 documentation or answer basic encryption questions suggests either inadequate security practices or a very early-stage operation. Consider whether this vendor is appropriate for storing your customer and financial data.
Do I need a formal security review before signing with an FSM vendor? For most small to mid-size contractors, the questions above are sufficient. If you handle particularly sensitive data (healthcare equipment service, government contract work, financial institutions) or have contractual security obligations with customers, a more formal vendor security assessment may be appropriate. Many enterprise customers require vendors to complete a security questionnaire (VSA or similar) before approval.
Ready to streamline your operations? Start your 14-day free trial — no credit card required.