Security built for MSP operations
Squash is designed to keep access scoped, put sensitive actions behind policy and approval, and maintain an auditable record of what happened.
Last updated August 30, 2026
Client boundaries
Product policy scopes work by MSP, client, ticket, tool, and action.
Approval controls
Sensitive work can pause for a technician before anything runs.
Encryption
Customer data is encrypted in transit and at rest.
AI data use
Customer data, prompts, and outputs are not used to train foundation models.
Product controls
Keep access scoped and actions reviewable
MSPs control the systems Squash can reach and decide which actions can run, require approval, or must be blocked.
See how these controls work together on the AI governance page.
Scoped access
Customers choose which systems Squash can connect to. Product policy can further limit access by MSP, client, workflow, tool, and action.
Approval before sensitive work
An MSP can allow routine work, require a technician to approve sensitive work, or block an action. Squash checks that policy before execution.
Evidence behind each action
Audit records capture policy checks, approval decisions, tool activity, and results so work can be reviewed later.
Data and infrastructure
Protect customer data
Squash applies encryption, environment separation, access controls, and monitoring to the data used by customer-authorized workflows.
Hosting
Primary production data, application logs, and encrypted backups are hosted in U.S. AWS regions.
Encryption
Managed production storage uses encryption at rest. Product traffic uses HTTPS/TLS in transit.
Environment separation
Production and non-production environments are separated, and administrative access is limited by role and need.
Monitoring
Centralized logging, cloud threat detection, and security monitoring support investigation and response.
The privacy policy explains what product data Squash processes and why it is needed.
Security program
Controls need evidence behind them
Squash maintains a documented security program and is currently undergoing a SOC 2 Type 2 audit. Current controls and available security documentation can be reviewed in the Trust Center.
- Infrastructure and production changes are version-controlled and reviewed before deployment.
- Administrative access is limited by role and need, protected with strong authentication, and removed during offboarding.
- Security findings are prioritized by risk and product impact, then tracked through remediation.
- Incident response covers investigation, containment, communication, recovery, and follow-up review.
- Relevant third-party providers are reviewed for data handling and operational risk.