SOC 2 Type II
CompliantOur team shares the SOC 2 Type II report under NDA.
Approve team apps with less risk
Salus is SOC 2 Type II and ISO 27001 compliant. Team-built apps and agents run on managed hosting apart from your core systems.
Compliance
Where Salus compliance stands
Salus is SOC 2 Type II compliant and ISO 27001:2022 certified, following independent audits.
ISO 27001
CertifiedThe ISO 27001 certificate is available on request.
Penetration testing
OngoingIndependent third-party penetration testing is ongoing.
Request the report and the certificate from our team. Salus monitors compliance continuously in Vanta.
Risk
Lower risk to core systems
Hosting apart from core systems
Team-built apps and agents run on managed hosting separate from the infrastructure your core business systems use. That lowers exposure for existing systems. Each app’s own security still depends on how it’s built.
Scans in each pipeline
Before the build, Salus checks the app’s packages for known vulnerabilities, whether a person or agent started the deploy. Findings show in the pipeline and vulnerability dashboard. Enforce the scan to stop deploys with findings.
Offline controls in the console
You can take any deployment offline from the console, bring it back, or roll it back. It all happens in one place, so you skip hunting for the hosting setup or someone with access.
Access and oversight
IT control over each deploy
Roles and login tokens
Owner, Maintainer, Developer, Viewer, and Guest roles at organization, space, and project level decide who can view, change, and deploy. Viewers can’t deploy. Sign-in uses short-lived, refreshable tokens.
Inherited release rules
Set release rules once for the organization. New projects inherit them, and you can override them per project.
Organization audit log
See each deploy and who started it, filtered by space or project. Entries are append-only and isolated per organization. An agent deploy shows as “Salus MCP acting as [builder],” naming the person.
Agent deploys under builder access
A builder’s agent is a delegate. It uses the builder’s own access and has no account or permissions of its own. Your release rules and scans apply to its deploys the same as a person’s.
Your rules, applied
Roles · who can deploy
ada@yourco.com developer deploylogsenv vars
sam@yourco.com viewer logsmetrics
Agent actions stay within the access of the person who invokes them.
Release rules
Organization release rules inherited by new projects passed
Project override hr · leave-planner · own rules passed
Vulnerability scan before build · enforced · critical package found blocked
Monitoring
Requests 42/s
Errors 0.2%
Response 210 ms
When you need it
Take offline any deployment · bring it back or roll back armed
Audit log · filter by space or project · deploys shown under the builder whose access was used
- human ada@yourco.com deploy finance · expense-app 14:02 UTC audited
- human lee@yourco.com deploy hr · leave-planner 13:47 UTC audited
- human ada@yourco.com deploy finance · budget-agent 11:20 UTC audited
Where apps and data run
Choose where each environment runs
You choose the cloud and region for each environment when you create it. Apps, databases, and other resources run in that environment.
Salus Cloud regions
Managed hosting in the United States (South Carolina) on GCP and South Africa (Cape Town) on AWS.
Your own infrastructure
With Enterprise, BYOC adds a dedicated, isolated environment in infrastructure you own. That can be an AWS, GCP, or Huawei Cloud account, a private cloud, or on premise.
Control plane without your code
With BYOC, Salus runs the control plane by default and your infrastructure runs the apps. The control plane is SOC 2 Type II and ISO 27001 compliant and stores no code, workloads or resources such as databases.
Who owns what
Who owns what with Salus
Use this split for the shared responsibility part of your security questionnaire.
You own
- Your cloud account and access, with BYOC
- Your data and databases
- Your apps’ code and dependencies, since scanning flags known package issues and each app’s security depends on how it’s built
- Your rules for who can deploy and what a release must pass
Salus operates
- The platform, with builds, pipelines, runtime, and upgrades
- The controls, with roles, release rules, scanning, and the audit log
- The console control that takes a workload offline
- Monitoring, patching, and vulnerability management
You both see
- The audit log
- Logs and metrics by app
- Usage by app
- The compliance documentation
FAQ
Security questions, answered
Is Salus SOC 2 and ISO 27001 compliant?
Yes. Salus is SOC 2 Type II compliant and ISO 27001:2022 certified, following independent audits. We monitor compliance continuously in Vanta.
How do we get the SOC 2 report?
Our team shares the SOC 2 Type II report under NDA. Request it on the contact form with the Security documentation topic. The ISO 27001 certificate is available on request too.
Do team apps run alongside our core systems?
No. Team-built apps and agents run on managed hosting separate from the infrastructure your core business systems use. That lowers exposure for existing systems, though each app’s own security still depends on how it’s built.
Where do our apps and data run?
Your apps, databases, and other resources run in the cloud and region you choose for each environment. Salus Cloud runs in the United States (South Carolina) on GCP and South Africa (Cape Town) on AWS. With Enterprise, you can add a dedicated, isolated environment in your own AWS, GCP, or Huawei Cloud account, a private cloud, or on premise. Where it’s a hard requirement, we deploy the whole platform into your infrastructure, with the control plane and all its associated apps.
What happens when someone deploys a vulnerable package?
The scan flags it in the pipeline and on the vulnerability dashboard. If your organization enforces the scan, the deploy stops before it runs. The scan checks the app’s packages for known vulnerabilities before the build.
Can an agent do more than its builder?
No. A builder’s agent is a delegate that acts with the builder’s own access and has no account or permissions of its own. It reaches only the projects its builder can reach, and your release rules and scans apply to its deploys exactly as they do to a person’s.
How do we stop an app quickly?
Take it offline from the console. You can bring it back or roll it back from the same place when you’re ready.
Who operates what with BYOC?
By default, Salus runs the control plane and your infrastructure runs the apps. The control plane is SOC 2 Type II and ISO 27001 compliant and stores no code, workloads or resources such as databases.
Report a vulnerability
Report a vulnerability in Salus
Email suspected vulnerabilities in the Salus website, the console at app.salus.cloud, the platform, the CLI, or the MCP server to security@salus.cloud.
Tell us what’s affected, the steps to reproduce it, and the impact. Test only against your own account and apps, never another customer’s, and never access or keep anyone else’s data.
You can find the same address in salus.cloud/.well-known/security.txt, the standard place researchers and scanners look.
Bring Salus to your security review
Ask our team for the SOC 2 Type II report and the ISO 27001 certificate. You can also book a demo to see these controls in Salus.