Security and compliance

# 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.

[Request security documentation ](https://salus.cloud/contact/?topic=Security%20documentation#contact-form)[Book a demo](https://salus.cloud/talk-to-sales/)

Compliance

## Where Salus compliance stands

Salus is SOC 2 Type II compliant and ISO 27001:2022 certified, following independent audits.

### SOC 2 Type II

Compliant

Our team shares the SOC 2 Type II report under NDA.

### ISO 27001

Certified

The ISO 27001 certificate is available on request.

### Penetration testing

Ongoing

Independent third-party penetration testing is ongoing.

Request the report and the certificate from our team. Salus monitors compliance continuously in Vanta.

[Request security documentation](https://salus.cloud/contact/?topic=Security%20documentation#contact-form)

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.
    

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](mailto: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](https://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.

[Request security documentation ](https://salus.cloud/contact/?topic=Security%20documentation#contact-form)[Book a demo](https://salus.cloud/talk-to-sales/)
